@keldyn on a pull request to run an on-demand review.
This is not an evidence integration. Verdicts are flags for people to act on. They never change a control’s status or evidence in Keldyn. For read-only source-control evidence (access, branch protection, PR approvals, CI history), use the separate GitHub integration.
Integrations are typically managed by workspace admins. The Review Bot GitHub
App is a different app from the GitHub evidence integration. This one
posts checks and comments on pull requests; the evidence app only reads.
What it’s used for
The bot answers one question for every code-relevant control: would merging this pull request cause the control to fail? It is not a generic code review. It does not judge whether the repository already satisfies a control, and it raises no bug, style, or performance findings unless a listed control requires them. A pre-existing gap in code the pull request does not touch is not a finding. The same review rules as the MCPreview-changes prompt apply, so an IDE review and a pull-request review judge the same way. Adding a control in Keldyn, or assigning a framework to a use case, changes the next review with no extra setup.
Controls you have marked not applicable in Keldyn are left out of the review.
Before you begin
1
Decide which platforms to connect
One integration covers GitHub, GitLab, and Bitbucket. Connect only the
platforms you host code on. You can add another later without disconnecting
the first.
2
Choose the repositories to include
On GitHub, pick the organization and repositories during App installation.
On GitLab and Bitbucket, the access token’s scope is what the bot can
review — use a project, group, workspace, or repository token that covers
only those repos.
3
The bot never commits
The bot reads the pull request and proposes fixes as comments. It never
commits, pushes, or edits the branch.
Set up the integration
In the Keldyn web app, go to Integrations and select Keldyn Review Bot. Connect each provider you need.GitHub
1
Install the Review Bot GitHub App
Select Install GitHub App. GitHub opens the Keldyn Review Bot
installation flow. Choose the organization and repositories to review,
review the requested permissions, and approve the installation.
2
Authorize your GitHub account
Complete the GitHub authorization request. Keldyn uses it to verify that
your account can access the installation.
3
Confirm the check appears
Open a pull request on an included repository (or comment
@keldyn on an
existing one). The Keldyn Controls Review check should appear on the
head commit, with a summary comment on the pull request.GitLab
1
Create an access token
Create a project or group access token with the Developer role and the
api scope (read the repository, write merge-request notes and commit
statuses). For a self-managed instance, note the base URL (for example
https://gitlab.example.com).2
Connect in Keldyn
On the GitLab card, select Connect GitLab. Paste the token and, for
self-managed GitLab, the base URL. Keldyn generates a webhook secret —
leave it as-is.
3
Add the webhook
After connecting, copy the Webhook URL and the webhook secret
(shown once). In GitLab, add a project or group webhook with that URL and
secret token, subscribed to Merge request events and Comments.
Bitbucket
1
Create an access token
Create a Bitbucket Cloud workspace or repository access token with
Repositories: Read and Pull requests: Write.
2
Connect in Keldyn
On the Bitbucket card, select Connect Bitbucket. Paste the token.
Keldyn generates a webhook secret — leave it as-is.
3
Add the webhook
After connecting, copy the Webhook URL and the webhook secret
(shown once). In Bitbucket, add a repository webhook with that URL and
secret, subscribed to Pull request created, updated, and
comment created.
Review settings
Settings apply to every connected provider on the next review. Open the Review settings card on the integration page.How a review works
1
A pull request opens or updates
The bot starts on open, push, reopen, and ready-for-review. Comment
@keldyn (optionally with instructions, for example
@keldyn focus on the auth changes) to re-run at any time.2
Controls are loaded from Keldyn
The bot reviews every code-relevant control on the organization, plus
code-relevant controls from every framework assigned to a use case —
excluding controls marked not applicable.
3
The pull request is reviewed
Keldyn reads the diff and records one verdict per control, with file and
line evidence for anything that would fail or is at risk.
4
Results are posted on the pull request
One summary comment is created or updated in place (per-control table,
evidence, suggested fixes). Inline comments land on changed lines, with
suggested edits where a concrete fix exists. The
Keldyn Controls Review check completes on the head commit.
- Any Would fail → the check fails
- Only warnings or unevaluated controls → the check is neutral (or fails when Treat warnings as failures is on)
- Every applicable control Unaffected → the check succeeds
- The review itself cannot finish → the check fails
For controls already marked Implemented, the bot treats a change that weakens
or removes the previously recorded evidence as a regression. That is the same
rule
review-changes uses in your IDE.Review history
The Review history card on the integration page lists every run: repository, pull request, overall result, per-control tally, whether it ran automatically or from@keldyn, and time. Expand a row for each control’s verdict and evidence.
Verdicts in this history do not change a control’s status in Keldyn. Use them to see what merging would have done, then update controls yourself — or through the controls-to-code workflow — when a finding is real.
What data Keldyn collects and why
The bot requests only the access needed to read the pull request, post results, and record the run.The bot never commits, pushes, or edits the pull-request branch. Access
tokens and webhook secrets for GitLab and Bitbucket are stored encrypted.
The webhook secret cannot be read back after the page that first showed it.
GitHub uses short-lived installation tokens; Keldyn stores the installation
id, not a per-user token.
Permissions
GitHub App (Keldyn Review Bot — not the evidence app):
GitLab — Developer-role token with the
api scope, so the bot can read the repository and write merge-request notes and commit statuses.
Bitbucket Cloud — Repositories: Read and Pull requests: Write.
Troubleshooting
Reviews that never start, or a check that stays pending, usually mean one of the following:- Wrong GitHub App — the evidence GitHub integration is connected, but this page’s Review Bot App is not. Install Keldyn Review Bot from this integration, not from GitHub evidence.
- Repository not included — the GitHub App installation does not include the repository, or the GitLab / Bitbucket token cannot see it.
- Webhook missing or stale — GitLab and Bitbucket need the URL and secret from the provider card. After Rotate token, update the webhook secret on the provider.
- Draft pull request — drafts are skipped unless Review draft pull requests is on. Mark the pull request ready, or comment
@keldyn. - Automatic review off — with Review automatically off, nothing runs until someone comments
@keldyn. - No code-level controls — the check reports that there is nothing to review against. Assign a framework with code-relevant controls, or stop marking those controls not applicable.
- Check not required — the review ran but merges are not blocked. Add Keldyn Controls Review as a required status check (GitHub) or required commit / build status (GitLab, Bitbucket).
Next steps
Developer SDLC playbook
Run the same review rules in your IDE with
review-changes before you open
a pull request.From controls to code
Turn a Review Bot finding into updated evidence or a remediation task.
GitHub evidence
Collect read-only source-control evidence. A separate GitHub App from this
one.
Keldyn MCP server
Connect Claude Code or Cursor so local reviews use the same control set.