Code Review

CI code review (/review:code-review)

Org-owned review logic for the claude-review reusable workflow. The lane's workflow wrapper supplies REPO / PR NUMBER / HEAD SHA and the event-class reporting mechanics (inline-comment MCP on pull_request, gh pr review/gh pr comment on workflow_dispatch). This skill owns what to look for; the wrapper owns how to post.

Gotchas

• Command/skill frontmatter allowed-tools grants permission but does not install the inline-comment MCP server. That server only installs when named in the action's claude_args (--allowedTools mcp__github_inline_comment__create_inline_comment). Rely on the lane wrapper's grant; do not assume this frontmatter installed it.
• Scope security findings out of this lane wherever the consumer carries a claude-security-review workflow file. Leave those to /review:security-review.

Skip gate (cheap)

Before deep review, stop early when any of these hold (say so in the summary and post nothing else):

1. PR is closed or not open
2. PR is a draft
3. Change is trivial/automated with no meaningful review surface
4. This head already has a successful review from this lane that still applies

Criteria

This is the CODE-REVIEW lane. Review the pull request for correctness and alignment with the project's CLAUDE.md guidelines (and REVIEW.md criteria when present). Focus on architecture decisions, error handling, test coverage, and maintainability. Where REVIEW.md splits review scope across lanes. It scopes security review to the dedicated security lane wherever a claude-security-review workflow exists. Follow that split.

Scope the review to files changed in this PR. Use gh pr diff to identify what changed, then review those files. Do not explore unrelated parts of the codebase.

Never restate the PR author's own claimed verification (e.g. a Test plan's described commands or output) as evidence you independently confirmed. Only claim to have verified something you yourself ran with a tool available to you; label anything else as author-claimed and unverified.

High-signal bar

Report only findings a careful senior reviewer would block or flag. Exclude:

• Anything a linter, formatter, typechecker, or trivial static check catches
• Pre-existing issues on untouched lines
• Generic advice, style nits, and "consider adding tests" without a concrete gap
• Security findings that belong on the security lane (see "Gotchas" above)

Adversarial validation

When you fan out subagents for candidate findings, the producer of a finding must not be the verifier. Drop candidates the verifier rejects. Committable suggestion fences (GitHub suggestion code blocks) are allowed only when the suggestion alone fully fixes the finding on the anchored lines.

Reporting

Follow the reporting mechanics the workflow wrapper appended to the prompt (inline MCP tool vs gh). Keep the summary comment for overview and cross-file / whole-PR findings; use commit-blob permalinks with the supplied HEAD SHA for locations no changed line can carry.