Four-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 / spec?
Simplification: can the change stay correct with less complexity, duplication, or reimplementation of existing code?
Optimization: does the change introduce avoidable performance and scaling costs under realistic load: N+1 queries, serial I/O, unbounded fan-out, missing batching/caching/indexes, or overload risks?

Each axis runs as a parallel sub-agent so they don't pollute each other's context, then this skill aggregates their findings.

The originating issue or spec usually lives in GitHub Issues. Fetch it with the gh CLI, which infers the repository from the clone. When findings name domain concepts, use the vocabulary from GLOSSARY.md (or the per-context glossaries that GLOSSARY-MAP.md points at).

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.

Capture the diff command once: git diff <fixed-point>...HEAD (three-dot, so the comparison is against the merge-base). Also note the list of commits via git log <fixed-point>..HEAD --oneline.

code-review

Process

1. Pin the fixed point