code-review

Two-axis review of the diff between `HEAD` and a fixed point: - **Standards** — does the code conform to the project's documented standards? - **Spec** — does the code faithfully implement `docs/specs/<feature>.md` (or its ticket)? Both axes run as **parallel sub-agents** so they don't pollute each other's context, then this skill aggregates their findings. ## Process ### 1. Pin the fixed point Use the fixed point the user supplied — a commit SHA, branch name, tag, `HEAD~5`, etc. If they didn't supply one, default to the merge-base with the default branch. Capture the diff command once: `git diff <fixed-point>...HEAD` (three-dot, against the merge-base), and the commit list: `git log <fixed-point>..HEAD --oneline`. Confirm the fixed point resolves (`git rev-parse <fixed-point>`) and the diff is non-empty — a bad ref or empty diff fails here, not inside the sub-agents. ### 2. Identify the spec source Look for the originating spec, in this order: 1. A file under `docs/specs/` matching the branch name or feature — the spec itself, or the ticket file (e.g. under `docs/specs/<feature>/`) when the work is ticketed. 2. A path the user passed as an argument. 3. Otherwise, ask the user where the spec is. If there isn't one, the **Spec** sub-agent skips and reports "no spec available". ### 3. Identify the standards sources Anything that documents how this project's code should be written: `AGENTS.md` (or `CLAUDE.md`), project-local rules files if present, `CONTRIBUTING.m...