# Two Axis Review > Review finished work on two separate axes — craft quality and faithfulness to what was asked — and never let one axis excuse the other. Use before merging any meaningful change. - Skill: `lightarktech/two-axis-review` (Agent Skill) - Install (CLI): `npx skillmds@latest add lightarktech/two-axis-review` - Raw SKILL.md: https://api.skillmd.com/api/skills/lightarktech/two-axis-review/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: lightarktech (https://skillmd.com/u/lightarktech) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/lightarktech/two-axis-review --- A change can be beautifully built and still be the wrong thing; it can be exactly what was asked and still be built badly. One review that mixes both questions lets each failure hide behind the other's pass. Keep the axes separate. ## Axis 1 — Craft Does the change meet this project's own standards? Documented conventions first; beyond them, watch for the classics: duplicated logic, names that don't say what they mean, one edit scattered across a dozen files, abstractions nobody needed. (The canon here is Martin Fowler's catalog of code smells — flag by name, as judgment calls, never as autopilot rules.) ## Axis 2 — Faithfulness Put the original request next to the diff and check three things: - **Missing** — asked for, not there (or half there). - **Uninvited** — there, but nobody asked (scope creep hiding as initiative). - **Warped** — looks implemented, but numbers/edge behavior/wording differ from what was specified. Check the exact values: limits, thresholds, orderings, legal wording. ## The reviewer is never the author Two passes from one model are one pass with extra steps. It reviews toward the assumptions it wrote with. - **A different model, not just a different chat.** Reviewers on both axes come from another model family or another tier than the author. A fresh context on the same model clears the memory, not the blind spot — what it failed to imagine while building is what it fails to look for while judging. - **The reviewer gets the ask, the diff, and the test output — nothing else.** No author commentary, no "here's why I did it this way", no defense of the hard part. That narrative is precisely what drags a fresh model back into the author's frame. If a diff can't be judged without the author's story attached, that itself is an Axis 1 finding. - **Review at or above the difficulty of the work.** Swap family or swap tier, never drop below the job: top-tier author, flagship reviewer, or the reverse. The smallest model is for mechanical passes — wording checked against the spec line by line, links, formats, checklist coverage. Aim it at architecture or business logic and you have staged a review, not run one. - **Bake it into the default roster.** Author on one strong model, reviewer on a different one, as the standing configuration — then heterogeneity survives the day you are rushed and would otherwise have reused whatever was already open. The same rule from the testing side: `red-light-first`. Tier assignment: `model-tiering`. ## The orchestrator is an author too Everything above governs work that was dispatched, which leaves the largest hole open: what the main session writes itself. Postmortems, conclusions, readings of the data, acceptance reports, final external copy — the orchestrator drafts them, checks them, and hands them over with no second party ever in the loop. Rereading them inside the context that produced them is not a review; it is the same blind spot getting a second look at itself. **Send out for review — anything the founder will decide on, or that goes outside:** - Incident postmortems and root-cause writeups. - Readings of metrics or test data — the numbers, and what you claim they mean. - Feasibility and go/no-go conclusions. - Acceptance and sign-off reports ("this is done, here is the proof"). - External copy and public materials in final form. **Don't — or every sentence becomes a dispatch:** - Routine status updates and progress notes. - Relaying a conclusion a sub-agent already had independently verified — it has been reviewed; don't review the messenger. - Small reversible changes. **How.** Another model family or another tier, same as any reviewer. Hand it the raw material — the original ask, the raw data, the untouched command output — plus the artifact under review. Hand it none of your reasoning and none of your justification. Its one question: where does the conclusion outrun the evidence? **Escape valve.** When timing genuinely rules out reviewing first, the artifact reaches the founder stamped **not independently reviewed** — on the artifact, in plain words, before they act on it. Late is survivable. Unmarked is not. The report the founder trusts most is the one nobody checked. ## Rules - Run the two axes as **separate passes with fresh eyes** (two sub-agents, or two sittings) so they can't contaminate each other — and neither pass is run by the model that wrote the change (above). - Report per axis; don't average them into one score. "9/10 craft" never buys forgiveness for "wrong feature". - Adversarial rounds cap at 2 (see `dispatch-economics`). Findings must quote the line they're about. - Our first run of this review caught a legally sensitive one-word deviation ("we" vs "I" in a compliance sentence) that CI and human eyes had both passed. Exact-wording checks pay. ## Success criteria Two written verdicts, one per axis, each citing evidence, neither produced by the author's model. Every finding is either fixed or explicitly accepted with a reason — none silently dropped. Every artifact the founder will act on either cleared a reviewer from another family or tier, or arrived carrying the words *not independently reviewed* — there is no third option.