Code Review

Code Review Skill

Summary

Use this skill to review a code change independently of the hosting platform. The result is a concise, evidence-backed assessment for a human or another workflow to consume. This skill does not know how to fetch a pull request or publish comments.

When To Use

• Reviewing a patch, commit range, change set, or proposed implementation
• Checking regressions before a merge, release, or deployment
• Producing findings for a platform-specific review adapter

Do Not Use

• Implementing the fix while reviewing
• Approving, blocking, or otherwise replacing a human merge decision
• Treating an unavailable file, test, or instruction as evidence that no issue exists

Inputs

Use the context supplied by the caller. It may include:

• change_set: changed files, hunks, and the before/after revisions
• baseline: relevant surrounding code, configuration, interfaces, and history
• project_instructions: repository or path-specific review rules
• prior_feedback: earlier findings and their current status
• verification_budget: commands or checks that may be run

Do not assume a particular directory or file name. If a caller supplies a manifest, resolve inputs from its artifact entries and record missing or unavailable entries in the coverage summary.

Workflow

1. Establish scope and coverage

• Identify the exact change set and its baseline.
• Read applicable project instructions before judging behavior.
• List the files and hunks actually reviewed.
• Separate facts observed in the supplied context from assumptions.
• If core context is missing, continue only with an explicit limited-scope result; never infer a clean review from missing evidence.

2. Generate candidates

Perform an explicit hunk-level risk scan. For every changed file and materially changed hunk, consider each applicable category before moving on:

1. Correctness and data integrity
2. Security, authorization, trust boundaries, and secret handling
3. Lifecycle, failure handling, retries, cancellation, and cleanup
4. Concurrency, ordering, idempotency, and duplicate side effects
5. Compatibility, migrations, and public contract changes
6. Resource usage and performance
7. Tests, observability, and maintainability when they affect behavior

Do not stop at summarizing the apparent intent. Inspect changed conditions, state transitions, error paths, call sites, tests, documentation, and generated contracts as applicable. Record the causal changed hunk and the best actionable location for every candidate while the context is fresh.

Follow important control flow into surrounding code when needed to establish impact, but avoid speculative project-wide criticism.

3. Verify candidates

For every candidate finding:

• Re-read the relevant code and trace the behavior to a concrete outcome.
• Run a focused test, type check, lint, query, or other available verification when it can distinguish a real issue from a false positive.
• Confirm that the issue is introduced or materially worsened by the change.
• Confirm that the evidence and impact can be located precisely enough for the author to act. Prefer a changed-line location; when the impact appears in unchanged code, CI, generated output, or a cross-file interaction, record the best location and its causal relationship to the change.
• Lower confidence or omit the finding when evidence remains inconclusive.

Do not publish a high-severity finding based only on a pattern match, naming preference, or an unverified hypothesis. Do not lower confidence, severity, or omit an otherwise valid finding solely because a hosting platform cannot attach it to an inline changed-line range.