Code Review Workflow

Indexed Reference Map

• @[SKILL.md#L1-L99] Frontmatter, trigger rules, SOP, output contract.
• @[references/INDEX.md#L1-L13] Reading order and coverage map.
• @[references/review-modes.md#L1-L16] Mode selection and precedence.
• @[references/review-request-template.md#L1-L14] Reviewer handoff artifact structure.
• @[references/review-findings-rubric.md#L1-L20] Findings classes, evidence, and confidence rubric.
• @[references/review-response-template.md#L1-L14] Comment-response structure and decision rules.
• @[references/examples.md#L1-L5] Example prompt-to-mode mappings.

Scope

• In-scope:
  • Preparing a reviewer-ready request after implementation.
  • Reviewing local diff, staged changes, or PR patch directly.
  • Interpreting and responding to review comments with evidence.
  • Selecting the correct review phase/mode before acting.
• Out-of-scope:
  • Blindly mixing all review phases in one vague response.
  • Auto-posting comments to external services without approval.
  • Replacing debugging or final merge/branch closeout workflows.

KB Mode Notes

• Reading order:
  1. references/INDEX.md
  2. references/review-modes.md
  3. references/review-request-template.md
  4. references/review-findings-rubric.md
  5. references/review-response-template.md
  6. references/examples.md
• Coverage Matrix:
  • Mode selection -> review-modes.md
  • Request-review packaging -> review-request-template.md
  • Performing review findings -> review-findings-rubric.md
  • Reviewer response handling -> review-response-template.md
  • Prompt examples -> examples.md
• Portability note:
  • Workflow is review-methodology-first and local-first; transport/provider specifics stay out of scope.

Trigger Rules

• Positive:
  • User wants to prepare a review request, review packet, reviewer handoff, or pre-PR summary.
  • User explicitly asks the assistant to review code, diff, patch, or PR directly.
  • User already has reviewer comments and asks how to respond, whether a comment is valid, or what should be patched.
  • Prompt contains mixed review intent and the assistant must choose the correct phase first.
• Negative:
  • Request is mainly planning, debugging, implementation, or final branch closeout with no real review-loop intent.
  • User only wants formatting/lint cleanup with no review workflow.
  • No diff/change/comment context exists and the user is not asking about review workflow itself.
  • The user only wants generic advice about code quality/process, not an actual review-phase action.
• Escalation:
  • If review comments imply a real bug, hand off to debugging/verification after classifying the review phase.
  • If user wants external posting/writing, require approval before sending.

SOP

1. Select mode first
   • Choose one primary mode: REQUEST_REVIEW, PERFORM_REVIEW, or RESPOND_TO_REVIEW.
2. State the mode briefly when useful
   • Especially if the prompt could have matched multiple old skills.
3. Run the phase-specific workflow
   • Request mode -> package scope, summary, evidence, and focus areas.
   • Perform mode -> inspect diff/context, report actionable findings with confidence.
   • Respond mode -> classify comment, verify evidence, then accept/clarify/push back/test-first.
4. Avoid phase bleed
   • Do not package a review request when the user actually wants direct review.
   • Do not review code when the user only needs help answering comments.
5. Mention next phase only if natural
   • e.g. after request packet, next likely phase is actual review.
6. Keep evidence discipline
   • Never overclaim safety, correctness, or reviewer validity without support.
7. Escalate appropriately
   • Debugging/verification can be follow-up skills when evidence demands it.

Error Handling

• Missing diff/comment/context:
  • Ask for the smallest missing input needed for the selected mode.
• Mixed review stages in one request:
  • Pick the earliest blocking stage first and name the likely next stage.
• Weak evidence:
  • Downgrade confidence or return PARTIAL instead of overstating certainty.
• User requests blind agreement or blind review posting:
  • Refuse and explain the missing verification/approval gate.

Output Contract

• Deliverable:
  • Mode: REQUEST_REVIEW | PERFORM_REVIEW | RESPOND_TO_REVIEW
  • Goal: what this review-phase output is trying to achieve.
  • Mode-specific body:
    • Request -> scope, summary, evidence, focus areas, open questions, suggested review request.
    • Perform -> summary, findings, confidence, next actions.
    • Respond -> comment, classification, assessment, evidence, recommended response, next step, confidence.
  • Possible Next Phase: only if obvious.
• Validation:
  • Must choose one primary mode.
  • Must not conflate reviewer-request packaging with direct review or comment response.
  • Must be evidence-backed and phase-appropriate.
• Compliance Verdict:
  • PASS when the chosen mode and output fit the review state; otherwise PARTIAL or FAIL with reason.