review-diff

name	review-diff
description	Trigger only to inspect an existing diff, commit, branch, or PR for correctness, regression, security, performance, and maintainability issues; do not use to implement changes or run acceptance verification.
requires	[]

review-diff — Evidence-Bound Diff Review Skill

1. Trigger Boundary

Use this skill only when there is an existing change set to review:

• Git diff.
• Commit or commit range.
• Branch comparison.
• Pull request.
• Wave worktree diff produced by execute-plan.

Do not use this skill to implement requested changes, debug an observed failure, create a plan, or verify acceptance criteria after implementation.

2. Non-Negotiable Constraints

• Review only. Do not edit files.
• Findings require evidence. Every issue must include file path, line or smallest location, severity, impact, and a concrete fix recommendation.
• Blockers must be real. Mark critical or high only for correctness, security, data loss, regression, build breakage, or severe maintainability risk.
• Style is non-blocking unless policy-backed. Do not block on personal preference.
• Approval requires no blocking findings. approved: true is allowed only when no critical or high issues remain.

3. Review State Machine

State A — Identify Target

Resolve the review target and changed files. If no diff target exists, return blocked.

State B — Inspect Behavior Changes

Review changed logic for:

• Incorrect control flow or data flow.
• Missing error handling.
• Edge cases and boundary conditions.
• API, schema, or contract mismatches.
• Security and privacy regressions.
• Performance problems introduced by the diff.

State C — Classify Findings

Use severity definitions:

• critical: likely data loss, security compromise, production outage, or unrecoverable broken build.
• high: likely user-visible regression, failing core path, serious correctness issue, or unsafe behavior.
• medium: plausible bug or maintainability problem with limited blast radius.
• low: cleanup, readability, minor consistency, or non-blocking improvement.

State D — Decide Approval

Approve only if blocking severities are empty. Include a short rationale either way.

4. Negative Prompts

• Never report an issue without a concrete code location.
• Never invent changed behavior not present in the diff.
• Never rewrite code during review.
• Never bury a blocker under vague wording.
• Never mark personal style preferences as blocking.
• Never return approved: true when critical or high findings exist.

5. Final Output Format

status: reviewed | blocked
approved: boolean
target: string
targetType: pr | branch | commit | diff-file | worktree | unknown
summary: string
issues:
  critical:
    - file: string
      line: number | null
      title: string
      impact: string
      recommendation: string
  high: []
  medium: []
  low: []
blockedReason: string | null