code-review

Reviews a git diff against coding standards and the originating spec using parallel sub-agents.

Updated Jul 16, 2026
One-click install
npx skills add https://github.com/The-Focus-AI/walking-thoughts --skill code-review-the-focus-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/The-Focus-AI/walking-thoughts/tree/main/.agents/skills/code-review
Command: npx skills add https://github.com/The-Focus-AI/walking-thoughts --skill code-review-the-focus-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Code reviews often conflate two separate questions — whether the code follows project conventions and whether it actually implements what was asked — letting one concern mask the other. This Skill separates those axes so a change that passes standards but misses the spec (or vice versa) is never silently approved. ## Core Features & Use Cases - Two-axis review: Runs a Standards review (repo-documented conventions plus a Fowler code-smell baseline) and a Spec review (fidelity to the originating issue or spec) as parallel sub-agents, then reports them side by side. - Fixed-point diffing: Reviews changes since any commit, branch, tag, or merge-base using three-dot git diff, with upfront validation that the ref resolves and the diff is non-empty. - Spec discovery: Locates the originating spec from issue references in commit messages, a user-supplied path, or files under docs/, specs/, or .scratch/. - Use Case: Before merging a feature branch, ask for a review since main and receive separate Standards and Spec reports, each citing the violated rule or spec line, with hard violations distinguished from judgement calls. ## Quick Start Ask the assistant to review the changes on this branch since main using the code-review skill.

Frequently Asked Questions about code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review changes since a specific commit or branch?

Provide any fixed point — a commit SHA, branch name, tag, or expression like HEAD~5 — and the review compares it against HEAD using a three-dot git diff from the merge-base. The ref is validated with git rev-parse before the review starts.

How do I check if code matches the original issue or spec?

The Spec axis fetches the originating issue from references in commit messages, a path you provide, or spec files under docs/, specs/, or .scratch/. It reports missing requirements, scope creep, and incorrect implementations, quoting the spec line for each finding.

What coding standards does the review check against?

It uses any standards documented in the repo, such as CODING_STANDARDS.md or CONTRIBUTING.md, plus a built-in baseline of Fowler code smells like Duplicated Code, Feature Envy, and Shotgun Surgery. Documented repo standards always override the baseline.

What happens if there is no spec for the changes being reviewed?

If no spec is found and you confirm none exists, the Spec sub-agent is skipped and the final report notes that no spec was available. The Standards review still runs normally against the diff.

Why are standards and spec findings reported separately?

A change can follow every convention yet implement the wrong thing, or match the spec while breaking project standards. Keeping the axes separate prevents one passing axis from masking failures in the other, so findings are never merged or reranked.