Agent skill

Two-Axis Code Review

by rengwu in rengwu/wayfinder-maps

Reviews the changes since a commit, branch or tag along two separate axes: the repo's documented coding standards and fidelity to the originating spec or PRD.

MITAuto-check passedDevelopment

Install Two-Axis Code Review

skills CLI
$ npx skills add rengwu/wayfinder-maps --skill review-code -a claude-code

Project install by default; add -g for ~/.claude/skills/.

GitHub CLI
$ gh skill install rengwu/wayfinder-maps review-code --agent claude-code

Project scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).

Manual copy
$ git clone --depth 1 https://github.com/rengwu/wayfinder-maps.git skills-src && mkdir -p .claude/skills && cp -r skills-src/skills/.optional/review-code .claude/skills/review-code && rm -rf skills-src

Use ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.

Claude Code skills documentation · loads skills from .claude/skills/

Facts

Skill name
review-code
GitHub stars
134
Token cost
~1.8k tokens
SKILL.md length
1,077 words
Files
1
Skills in repo
9
Repo updated
First seen
Licence
MIT

At a glance

Reviews the changes since a commit, branch or tag along two separate axes: the repo's documented coding standards and fidelity to the originating spec or PRD.

  • Works in 5 steps: Pin the fixed point → Identify the spec source → Identify the standards sources → …
  • Reviewing a feature branch against its spec before merge
  • SKILL.md covers Process and Why two axes
  • Calls git

What it does

The skill reviews the diff between HEAD and a fixed point you supply, such as a commit SHA, branch, tag, main or HEAD~5. It pins the point first, confirms that the ref resolves and that the three-dot diff against the merge-base is not empty, and notes the commit list, so a bad ref fails early. It then reviews two axes in isolation so neither pollutes the other: Standards, meaning conformance to the repo's documented coding rules, and Spec, meaning whether the code implements the originating spec or PRD. The results are aggregated side by side.

The spec is looked for in a fixed order: a path you pass, a spec under .plan/, a PRD or spec elsewhere in the repo such as docs/ or specs/, and issue references in commit messages. If none exists, the Spec axis is skipped and reports that no spec is available. Standards come from files like CODING_STANDARDS.md or CONTRIBUTING.md plus a baseline of Fowler code smells. The repo's own standards override the baseline, the language's paradigm decides which smells apply, and each smell is labeled as a judgment call, skipping anything tooling already enforces.

When your agent uses it

  • Reviewing a feature branch against its spec before merge
  • Checking work-in-progress changes against the repo's coding standards
  • Reviewing everything that changed since a given tag or commit

Example prompts

  • “Review my branch since the merge-base with main against our coding standards and the PRD in docs/specs.”
  • “Review since the last release tag and tell me where the code drifts from the spec.”
  • “Do a standards-only review of the uncommitted work since HEAD~5.”

Requirements

  • A Git repository with a commit, branch or tag to compare against

Workflow steps

5 steps, taken from the step headings in SKILL.md.

  1. Pin the fixed point
  2. Identify the spec source
  3. Identify the standards sources
  4. Run both reviews in isolation
  5. Aggregate

What it can do on your machine

Read from SKILL.md and the folder at commit c252110. It shows what the files ask for, not the result of running them.

  • Tool permissions

    Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.

    From allowed-tools in the SKILL.md frontmatter.

  • Runs code

    Shell commands in SKILL.md call:

    • git

    From the folder's file list and the shell code blocks in SKILL.md.

  • Network

    No URLs in SKILL.md. Its commands use git, which can reach the network depending on how they are called.

    From URLs in SKILL.md, links to its own repository left out.

  • Credentials

    Names no API keys, tokens, secrets or passwords.

    From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.

Context cost

Two-Axis Code Review loads about 1.8k tokens when it runs. Until then it costs about 88 tokens; SKILL.md has 1,077 words of instructions outside code blocks.

Always · name and description, kept in context so the agent knows when to use it
~88
When it runs · the whole SKILL.md, loaded when a task matches
~1.8k

Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.

Safety

Auto-check passed

The automated check found no risky patterns in SKILL.md.

Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.

SKILL.md

The full file from rengwu/wayfinder-maps at commit c252110, republished under its MIT licence (© rengwu). 1,077 words, ~1,821 tokens.

Download SKILL.mdSave it as .claude/skills/review-code/SKILL.md (or your agent's skills folder).
name
review-code
description
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating spec/PRD asked for?). Use when the user wants to review a branch, work-in-progress changes, or asks to "review since X".

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 spec / PRD?

The two axes are reviewed in isolation so they don't pollute each other, then aggregated side by side.

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.

Before going further, confirm the fixed point resolves (git rev-parse <fixed-point>) and the diff is non-empty. A bad ref or empty diff should fail here — not inside the two reviews.

2. Identify the spec source

Look for the originating spec, in this order:

  1. A path the user passed as an argument.
  2. A spec under .plan/ — typically .plan/<slug>/spec.md, matching the branch name or feature.
  3. A PRD/spec file elsewhere in the repo (docs/, specs/, or similar) matching the branch name or feature.
  4. Issue references in the commit messages (#123, Closes #45, etc.) — if the environment has a way to fetch them (e.g. the repo host's CLI), fetch the referenced issue.
  5. If nothing is found, ask the user where the spec is. If they say there isn't one, the Spec axis will skip and report "no spec available".
3. Identify the standards sources

Anything in the repo that documents how code should be written, such as CODING_STANDARDS.md or CONTRIBUTING.md.

On top of whatever the repo documents, the Standards axis always carries the smell baseline below — a fixed set of Fowler code smells (Refactoring, ch.3) that applies even when a repo documents nothing. Three rules bind it:

  • The repo overrides. A documented repo standard always wins; where it endorses something the baseline would flag, suppress the smell.
  • The language's paradigm applies. Skip smells that don't fit the language being reviewed — e.g. Refused Bequest in a language without inheritance, Feature Envy where there are no objects to envy.
  • Always a judgement call. Each smell is a labelled heuristic ("possible Feature Envy"), never a hard violation — and, like any standard here, skip anything tooling already enforces.

Each smell reads what it is → how to fix; match it against the diff:

  • Mysterious Name — a function, variable, or type whose name doesn't reveal what it does or holds. → rename it; if no honest name comes, the design's murky.
  • Duplicated Code — the same logic shape appears in more than one hunk or file in the change. → extract the shared shape, call it from both.
  • Feature Envy — a method that reaches into another object's data more than its own. → move the method onto the data it envies.
  • Data Clumps — the same few fields or params keep travelling together (a type wanting to be born). → bundle them into one type, pass that.
  • Primitive Obsession — a primitive or string standing in for a domain concept that deserves its own type. → give the concept its own small type.
  • Repeated Switches — the same switch/if-cascade/pattern-match on the same type recurs across the change. → replace with polymorphism, a dispatch table, or one match site both callers share.
  • Shotgun Surgery — one logical change forces scattered edits across many files in the diff. → gather what changes together into one module.
  • Divergent Change — one file or module is edited for several unrelated reasons. → split so each module changes for one reason.
  • Speculative Generality — abstraction, parameters, or hooks added for needs the spec doesn't have. → delete it; inline back until a real need shows.
  • Message Chains — long a.b().c().d() navigation the caller shouldn't depend on. → hide the walk behind one method on the first object.
  • Middle Man — a class or function that mostly just delegates onward. → cut it, call the real target direct.
  • Refused Bequest — a subclass or implementer that ignores or overrides most of what it inherits. → drop the inheritance, use composition.
Show full SKILL.md (409 more words)Show less
4. Run both reviews in isolation

If your environment supports spawning subagents, send a single message with two subagent calls (use a general-purpose subagent for both) so the axes run in parallel with isolated context.

Otherwise, run the two axes as sequential, self-contained passes in this session: complete the Standards pass in full and write its findings down before starting the Spec pass, then re-read the diff fresh with only the spec in mind. Don't let one pass's findings leak into the other's brief.

Either way, each axis gets exactly the brief below and nothing else.

Standards brief — include:

  • The full diff command and commit list.
  • The list of standards-source files you found in step 3, plus the smell baseline from step 3 pasted in full — a subagent has no other access to it.
  • The instruction: "Report — per file/hunk where relevant — (a) every place the diff violates a documented standard: cite the standard (file + the rule); and (b) any baseline smell you spot: name it and quote the hunk. Distinguish hard violations from judgement calls — documented-standard breaches can be hard, but baseline smells are always judgement calls, and a documented repo standard overrides the baseline. Skip anything tooling enforces, and skip smells that don't apply to the language's paradigm. Under 400 words."

Spec brief — include:

  • The diff command and commit list.
  • The path or fetched contents of the spec.
  • The instruction: "Report: (a) requirements the spec asked for that are missing or partial; (b) behaviour in the diff that wasn't asked for (scope creep); (c) requirements that look implemented but where the implementation looks wrong. Quote the spec line for each finding. Under 400 words."

If the spec is missing, skip the Spec axis and note this in the final report.

5. Aggregate

Present the two reports under ## Standards and ## Spec headings, verbatim or lightly cleaned. Do not merge or rerank findings — the two axes are deliberately separate (see Why two axes).

End with a one-line summary: total findings per axis, and the worst issue within each axis (if any). Don't pick a single winner across axes — that's the reranking the separation exists to prevent.

Why two axes

A change can pass one axis and fail the other:

  • Code that follows every standard but implements the wrong thing → Standards pass, Spec fail.
  • Code that does exactly what the issue asked but breaks the project's conventions → Spec pass, Standards fail.

Reporting them separately stops one axis from masking the other.

© rengwu, MIT. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file

Files

Just SKILL.md in skills/.optional/review-code of rengwu/wayfinder-maps.

Open the folder on GitHubat commit c252110

Compare with similar skills

Two-Axis Code Review next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.

Two-Axis Code Review compared with similar skills
SkillStarsUsed inTokensAuto-checkLicenceRepo updated
Two-Axis Code Review this skillrengwu/wayfinder-maps134—~1.8kAutomated safety check: PassMIT
Qt C++ Code Reviewx-tools-author/x-tools1.1k2 repos~4.3kAutomated safety check: PassBSD-3-Clause
Adversarial Reviewer302ai/302-AI-Studio1321 repos~3kAutomated safety check: PassMIT
Feature-Level Code Reviewdataelement/bisheng12k—~1kAutomated safety check: PassApache-2.0
Code Revieweralirezarezvani/claude-code-tresor777—~1.8kAutomated safety check: PassMIT
Code ReviewerMageByte-Zero/spec-superflow8411 repos~1.5kAutomated safety check: PassMIT

Similar skills

  • Qt C++ Code Review

    x-tools-author/x-tools

    Read-only review of Qt6 C++ code that combines a deterministic lint script with six parallel analysis agents and reports only high-confidence issues.

    1.1k GitHub starsUsed in 2 repos~4.3k tokens
    DevelopmentAuto-check passed
  • Adversarial Reviewer

    302ai/302-AI-Studio

    Adversarial code review that breaks the self-review monoculture.

    132 GitHub starsUsed in 1 repo~3k tokens
    DevelopmentAuto-check passed
  • Feature-Level Code Review

    dataelement/bisheng

    Runs a seven-dimension code review on a finished feature, comparing the diff against a base branch and the feature's spec, design and task files.

    12k GitHub stars~1k tokensUpdated today
    DevelopmentAuto-check passed
  • Code Reviewer

    alirezarezvani/claude-code-tresor

    Automatic code quality and best practices analysis. An agent skill from alirezarezvani/claude-code-tresor.

    777 GitHub stars~1.8k tokensUpdated 3 mo ago
    DevelopmentAuto-check passed
  • Code Reviewer

    MageByte-Zero/spec-superflow

    Review completed implementation batches for spec compliance and code quality.

    841 GitHub starsUsed in 1 repo~1.5k tokens
    DevelopmentAuto-check passed
  • Code Review with Beads Tasks

    maslennikov-ig/claude-code-orchestrator-kit

    Reviews staged changes, a branch, a PR or a path for bugs, security gaps and performance issues, then writes an evidence-based report and creates Beads tasks.

    260 GitHub stars~2k tokensUpdated 7 mo ago
    DevelopmentAuto-check passed

More from rengwu/wayfinder-maps

All 9 skills in this repo
  • Verify

    rengwu/wayfinder-maps

    Build, launch and drive wayfinder-maps to verify a change end-to-end (server + headless browser).

    134 GitHub stars~738 tokensUpdated 2 days ago
    Auto-check passed
  • Wayfinder Planning Maps

    rengwu/wayfinder-maps

    Plans work too big for one agent session as a shared map of investigation tickets, resolved one at a time until the route to the destination is clear.

    134 GitHub stars~3.5k tokensUpdated 2 days ago
    Auto-check passed
  • To Spec

    rengwu/wayfinder-maps

    Turn the current conversation into a spec, saved to .plan/ — no interview, just synthesis of what you've already discussed.

    134 GitHub stars~813 tokensUpdated 2 days ago
    Auto-check passed
  • To Tickets

    rengwu/wayfinder-maps

    Break a plan, spec, or the current conversation into a set of tracer-bullet tickets, each declaring its blocking edges, saved to .plan/.

    134 GitHub stars~1.3k tokensUpdated 2 days ago
    Auto-check passed
  • Research

    rengwu/wayfinder-maps

    Investigate a question against high-trust primary sources and capture the findings as a cited Markdown file.

    134 GitHub stars~217 tokensUpdated 2 days ago
    Auto-check passed
  • Grill Me

    rengwu/wayfinder-maps

    A relentless interview to sharpen a plan or design — one question at a time until every branch of the decision tree is resolved.

    134 GitHub stars~211 tokensUpdated 2 days ago
    Auto-check passed

Works with

Categories

Questions about Two-Axis Code Review

What does Two-Axis Code Review do?

Reviews the changes since a commit, branch or tag along two separate axes: the repo's documented coding standards and fidelity to the originating spec or PRD. The skill reviews the diff between HEAD and a fixed point you supply, such as a commit SHA, branch, tag, main or HEAD~5. It pins the point first, confirms that the ref resolves and that the three-dot diff against the merge-base is not empty, and notes the commit list, so a bad ref fails early.

When should I use Two-Axis Code Review?

Two-Axis Code Review fits situations like: reviewing a feature branch against its spec before merge; checking work-in-progress changes against the repo's coding standards; reviewing everything that changed since a given tag or commit.

How do I install Two-Axis Code Review in Claude Code?

Run `npx skills add rengwu/wayfinder-maps --skill review-code -a claude-code`. Or copy the skill folder (skills/.optional/review-code in rengwu/wayfinder-maps) into .claude/skills/review-code in your project. Claude Code loads it when a task matches its description.

How do I install Two-Axis Code Review in Codex?

Run `npx skills add rengwu/wayfinder-maps --skill review-code -a codex`. Or copy the skill folder (skills/.optional/review-code in rengwu/wayfinder-maps) into .agents/skills/review-code in your project. Codex loads it when a task matches its description.

Can I use Two-Axis Code Review in Cursor, Gemini CLI or GitHub Copilot?

Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add rengwu/wayfinder-maps --skill review-code -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/review-code, .gemini/skills/review-code, .github/skills/review-code and .opencode/skills/review-code in your project.

What does Two-Axis Code Review need to run?

Going by SKILL.md and its folder, Two-Axis Code Review needs the command-line tools its instructions call (git). Our summary lists: A Git repository with a commit, branch or tag to compare against.

Does Two-Axis Code Review access the network?

SKILL.md contains no URLs. Its commands use git, which can reach the network depending on how they are called. This is read from the text; nothing was executed.

Is Two-Axis Code Review safe to install?

Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.

What licence does Two-Axis Code Review use?

Two-Axis Code Review is published under the MIT licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.

How many tokens does Two-Axis Code Review use?

About 1.8k tokens (SKILL.md is roughly 7.3k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.

What are the alternatives to Two-Axis Code Review?

Skills that share tags, products or a category with Two-Axis Code Review: Qt C++ Code Review (x-tools-author/x-tools, 1.1k stars), Adversarial Reviewer (302ai/302-AI-Studio, 132 stars), Feature-Level Code Review (dataelement/bisheng, 12k stars) and Code Reviewer (alirezarezvani/claude-code-tresor, 777 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.

Who maintains Two-Axis Code Review?

rengwu (a GitHub user) maintains it in rengwu/wayfinder-maps, which has 134 GitHub stars. The repository holds 9 skills in this directory. The repository was last updated on October 6, 2026.

Source: rengwu/wayfinder-maps on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.