# Code Review

> CI code-review lane for a GitHub pull request. High-signal correctness and maintainability findings only, scoped out of security when a security lane exists. Use when: 'CI code review', 'claude-review lane', '/review:code-review', or a reusable workflow invokes the org code-review plugin command.

- Skill: `melodic-software/code-review` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add melodic-software/code-review`
- Raw SKILL.md: https://api.skillmd.com/api/skills/melodic-software/code-review/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: melodic-software (https://skillmd.com/u/melodic-software)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/melodic-software/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.