review

Files (1)

• SKILL.md

SKILL.md (first lines)

# /sdlc:review — layered agentic review

Read `sdlc-loop` and the repo's `REVIEW.md` (path from `review.policy`). If `REVIEW.md` is missing, use
`${CLAUDE_PLUGIN_ROOT}/templates/REVIEW.md` and say the tech lead should add one.

## Review a change (default)

1. Determine the target: a PR number (use `gh pr diff` / GitLab MCP / `glab mr diff`), a branch (diff against
   the default branch), a path, or the working tree diff.
2. Find the change id (`Change:` line in the PR description or `SDLC-Change:` trailer). Read `spec.md` and
   `plan.md`. If none, treat the absence as an Important Compliance finding unless the PR is labelled
   `sdlc:exempt`.
3. Run the passes exactly as `REVIEW.md` defines them (default: Bugs, Security, Compliance). For Compliance,
   check each requirement and acceptance criterion in `spec.md`, each file/step/proof in `plan.md`, that any
   departure is recorded under "Departures from plan", that policy skills were honoured, and whether the change
   makes CLAUDE.md outdated.
4. Rank: **Important** only for findings that would break behaviour, leak data or breach a policy. Everything
   else is a Nit. Respect `review.nitCap` (default 5); summarise the rest as a count.
5. Skip what `REVIEW.md` says to skip (generated paths, what CI enforces).
6. Output in the `REVIEW.md` format, ending with the tally line
   `SDLC-REVIEW: important=<n> nits=<n> passes=...`. In CI, also write `sdlc-review.json`
   (`{"important":n,"nits":n,"findings":[...]}`) for the check run summary.
7. Findings do **not** approve or block. Say so. The code owner decides through branch protection.

## Feed the loop

- If a finding is the second occurrence of the same mistake in this repo (search `git log -S` or recent
  reviews), propose the one-line correction for CLAUDE.md "Things Claude gets wrong" as part of the review.
- If a finding cites a policy skill, note it: those should trend to zero once the skill is applied at build time.
  Persisting findings mean the skill is not triggering or has drifted from the policy.

## Tune the reviewer (`--tune`, tech lead, monthly)

1. Pull the last month of review comments and their reactions/resolutions.
2. Rate findings: which Important ones were accepted, which were noise, which Nits were useful.
3. Propose edits to `REVIEW.md`: tighten "What Important means", adjust the nit cap, extend "Do not report".
4. Open a PR with the `REVIEW.md` change; the tech lead owns it.

## Separation of duties

The agent that wrote the code cannot approve it. Never call `gh pr review --approve` or the GitLab equivalent.

From bibutikoley/ai-sdlc-claude, MIT.

More from bibutikoley/ai-sdlc-claude