Reviewing Changes

Two-axis review of the diff between HEAD and a fixed point the user supplies:

• Standards — does the code conform to this repo's documented coding standards?
• Spec — does the code faithfully implement the originating issue / PRD / spec?

Both axes run as parallel sub-agents so they don't pollute each other's context, then this skill aggregates their findings.

The Spec axis here is a fast pass — one sub-agent reading the diff against the spec, reporting gaps, scope creep, and wrong implementations in under 400 words. When you need a formal verdict instead — acceptance criteria with per-criterion status, evidence-domain separation (CODE vs OPERATION vs DATA), independent reviewer passes, and an aggregated PASS/FAIL/NEEDS_REVIEW — run the /rq skill on the same requirement. Reach for it when the change is high-risk (security, auth, permissions, persistence, transactions, integrations), when the user asks whether a requirement is genuinely met rather than what's missing, or when this axis surfaces findings the user wants adjudicated rather than listed. It replaces this axis; don't run both and merg…

The issue tracker should have been provided to you — run /vibe-init if docs/agents/issue-tracker.md is missing.

Process

1. Pin the fixed point

Whatever the user said is the fixed point — a commit SHA, branch name, tag, main, HEAD~5, etc. If another skill invoked this one and passed a fixed point (/vibe-implement passes the commit it recorded before starting), use that and don't ask. Only ask when neither a user nor a caller supplied one.