code-review_skill

Overview

This skill enforces rigorous, evidence-based code review practices for Python projects. It defines how to receive feedback, request systematic reviews, and enforce verification gates so completion claims are always backed by fresh proof. The goal is technical correctness, concise communication, and preventing premature or performative approvals.

How this skill works

When feedback arrives, follow a strict READ → UNDERSTAND → VERIFY → EVALUATE → RESPOND → IMPLEMENT flow that prioritizes verification before any change. For request-driven reviews, dispatch a code-reviewer subagent with the implemented change range and contextual details. Before any completion claim, run and record verification commands (tests, builds, or reproductions) and attach the output as evidence.

When to use it

• After receiving review comments that are unclear, conflicting, or technically consequential
• After finishing a task, feature, refactor, or subagent-driven step before merging
• Before claiming tests pass, builds succeed, or a bug is fixed
• When an external reviewer suggests changes that could break existing decisions
• When stuck or needing a fresh technical perspective

Best practices

• Avoid performative agreement; restate intent, ask precise questions, or push back with concrete technical reasons
• Never implement or merge based on suggestions without reproducing and verifying locally
• Use fresh verification evidence for every completion claim: test output, build exit code, or reproduction logs
• Request a systematic subagent review for each completed task or major change using SHA ranges and a clear description
• Prioritize fixes: address Critical immediately, Important before progressing, and log Minor items for later

Example use cases

• A reviewer suggests a large refactor: verify call sites and run tests before changing code
• A subagent completes a task: submit BASE_SHA/HEAD_SHA and requirements to the code-reviewer subagent for an independent review
• Preparing a PR to main: run full test suite, capture outputs, request an evidence-backed review, then merge
• Claiming a bug is fixed: run the original failing reproduction, attach passing logs, then mark as resolved
• Receiving conflicting external feedback: verify technical claims, prove breakage risk, and respond with evidence