Review of the change against a fixed point the user supplies, along two axes (a third, Journey, checks a delivery slice rather than a diff; see Journey axis):

Standards — does the code conform to this repo's documented coding standards?
Contract — does the code meet the ticket's acceptance criteria, implement every signature the ticket lists, and keep those signatures as written?

Both diff 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

Whatever the user said is the fixed point — a commit SHA, branch name, tag, main, HEAD~5, etc. If they didn't specify one, ask for it.

For committed work capture git diff <fixed-point>...HEAD (three-dot, against the merge-base). For work still in progress capture git diff <fixed-point> (tracked staged and unstaged changes) and read any untracked files in scope explicitly. Note the commits via git log <fixed-point>..HEAD --oneline. Keep the worktree path in both reviewer briefs.

code-review

Process

1. Pin the fixed point