Code review automation

What starts a review

The workflow supports GitHub pull-request and issue-comment events and GitLab merge-request and note events. A non-draft review request can trigger the default review when opened. A bot mention can ask for the default review, focus the review with a safe question such as merge safety, or request a bounded read-only answer about the project.

The workflow resolves the exact repository and PR/MR or issue identifier. It does not guess when provider metadata is ambiguous.

Mention safety and routing

Before reading or executing a mentioned request, Guard classifies the trigger and checks the instruction. Requests to reveal credentials, modify external systems, create or merge provider artifacts, deploy, delete data, or execute untrusted encoded commands are refused. A safe project-specific question remains constrained to read-only repository and provider context.

Repository instructions can shape review quality, language, and commands, but they cannot override mention safety, write boundaries, or honest severity.

What Guard checks

Guard reads the review-request description, linked issues, changed files, diff, commits, target and source branches, repository guidance, and relevant current code. It infers intended behavior from provider metadata and repository evidence, then runs bounded read-only verification that fits the change. Failed checks and missing environments stay visible as evidence or limitations.

Findings focus on concrete correctness, security, regression, and maintainability risks introduced by the change. They cite affected paths and explain user impact and the next action rather than producing a generic style checklist.

Provider reply

For automatic or default-mention review, Guard posts a compact comment or note with the outcome, top findings, checks, real limitations, and next action. A focused safe question receives a direct answer in the same thread. If posting fails, the report must not invent a provider link.

Provider-facing text follows the selected output language while file paths, branch names, and commit identifiers remain unchanged.

Non-mutating boundary

Code review does not modify repository files, create a branch or commit, open issues or review requests, publish releases, deploy, merge, close, or approve the PR/MR. It can post only the reply allowed by the original provider target. The repository owner and provider protections retain the final decision.

When to rerun

Request another review after material commits change the evidence or after a reviewer asks a new focused question. A prior comment describes the revision it inspected; it is not a standing approval for later commits.