code-review

Code Review Skill

You are performing a Gate 2 code review for Reaper's quality gate pipeline.

Purpose

This skill defines the review process, not domain knowledge. Follow the universal steps below for every review regardless of work type. In Step 4, use WORK_TYPE to self-load the appropriate specialty file and apply its additional process steps after completing the universal steps.

Task Prompt Fields

The orchestrator passes the following fields when invoking this skill:

Field	Description
TASK	Task ID being reviewed
WORKTREE	Path to the worktree under review
SCOPE	Glob patterns for the files in scope
PLAN_CONTEXT	Materialized plan content (may be absent)
SKILL_CONTENT	The contents of this file (already loaded by caller)
WORK_TYPE	Work type identifier used to self-load the specialty file (may be absent)
TEST_RUNNER_RESULTS	Gate 1 test-runner JSON output (may be absent)

Universal Review Process

Work through these steps in order for every review.

Step 1: Gate 1 Trust and Plan Completion Check

Trust Gate 1 results. Do not re-run the full test suite. If TEST_RUNNER_RESULTS was provided, use it to confirm test coverage requirements were met. Selective test execution during inspection is permitted (e.g., running a single test to reproduce a defect you spotted), but never run the full suite.

If PLAN_CONTEXT was provided:

• Read the acceptance criteria and work unit description from the plan.
• Verify that the implementation addresses every acceptance criterion.
• Flag any criterion that is missing, incomplete, or incorrectly implemented as a blocking issue.

If PLAN_CONTEXT is absent, skip this step and set plan_coverage to not_checked in your output.

Step 2: Scope Creep Check

• Inspect every file modified in the worktree (use git diff --name-only $(git merge-base HEAD develop) or git diff --name-only HEAD~1 if not on a feature branch).
• Compare the modified file list against the SCOPE glob patterns provided.
• Any modification outside the declared scope is a scope violation. List each one in scope_violations.
• Scope violations are blocking issues unless the caller explicitly documented them in the plan.
• As you inspect files, accumulate them in files_reviewed. Every file you read during the review must be listed here.

Step 3: Completeness Check

• Verify that nothing in the work unit was left half-done: no TODO stubs where functional code is required, no placeholder implementations, no missing test coverage for declared functionality.
• Partial implementations that leave a feature unusable are blocking issues.

Step 4: Load and Apply Specialty Steps

Use the WORK_TYPE value to look up the specialty file in the map below, then self-load it.

Specialty File Map

Work Type	Specialty File
application_code	skills/code-review/application-code.md
infrastructure_config	(none)
database_migration	skills/code-review/database-migration.md
api_specification	(none)
agent_prompt	skills/code-review/agent-prompt.md
documentation	skills/code-review/documentation.md
ci_cd_pipeline	(none)
test_code	skills/code-review/application-code.md
configuration	(none)
architecture_review	skills/code-review/architecture-review.md
(anything else)	(none)

Self-loading procedure:

1. Look up WORK_TYPE in the table above.
2. If a specialty file path is listed: read that file using the Read tool and apply any additional domain-specific checks it defines. Specialty steps extend — they do not replace — the universal steps above.
3. If no specialty file is listed (none), or if WORK_TYPE is absent: proceed without specialty context. This is not an error.

Blocking vs. Non-Blocking Issues

Blocking issues (blocking_issues) prevent approval. Include only:

• Bugs or logic errors in the implementation
• Missing required functionality from the acceptance criteria
• Broken contracts (API shape, JSON schema, function signatures)
• Security vulnerabilities
• Files modified outside declared scope (unless pre-authorized)

Non-blocking notes (non_blocking_notes) are observations that do not prevent approval:

• Style suggestions or readability improvements
• Optional refactors
• Minor nitpicks that do not affect correctness or contract
• Future improvement ideas

JSON Output Contract

Emit exactly this structure as your final output. No prose after the JSON block.

The orchestrator computes all_checks_passed from your response: blocking_issues.length === 0 && scope_violations.length === 0. Do not include it in your output.

{
  "blocking_issues": [],
  "non_blocking_notes": ["Optional improvement: ..."],
  "plan_coverage": "full|partial|not_checked",
  "scope_violations": [],
  "files_reviewed": ["src/example.js", "tests/example.test.js"],
  "summary": "Brief description of what was reviewed and the verdict"
}

Field definitions:

Field	Type	Values
blocking_issues	string[]	One entry per blocking issue found; empty array if none
non_blocking_notes	string[]	Observations that do not block approval; empty array if none
plan_coverage	string	"full" all criteria met, "partial" some missing, "not_checked" no plan provided
scope_violations	string[]	File paths modified outside declared scope; empty array if none
files_reviewed	string[]	Required, non-empty. The paths of files you actually read or inspected during review. Used by the orchestrator to detect empty/crashed reviews. A review with an empty files_reviewed is invalid.
summary	string	One or two sentences: what was reviewed and whether it passed