code-review

Reviews a finished code change against its plan and reports a ship or rework verdict.

4|Updated Aug 8, 2026
One-click install
npx skills add https://github.com/alexeyshishin/as-skill --skill code-review-alexeyshishin
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: code-review
Source: https://github.com/alexeyshishin/as-skill/tree/main/domains/code/skills/code-review
Command: npx skills add https://github.com/alexeyshishin/as-skill --skill code-review-alexeyshishin

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? After building a code change, you need an objective check that the implementation actually matches the plan before shipping. This Skill automates that review by spawning a dedicated reviewer subagent that compares the plan, build report, and git diff, then returns a clear ship/rework verdict with severity-tagged findings. ## Core Features & Use Cases - Plan-vs-diff verification: Gathers the plan file, build report, and the full git diff (staged, unstaged, or against the branch point) and passes them directly to the reviewer. - Read-only reviewer subagent: Spawns one reviewer that only finds and severity-tags issues without modifying any code. - Rework feedback loop: When the verdict is rework, the findings become the input for a follow-up /code-build run instead of being auto-fixed. - Use Case: After running /code-build on a feature, invoke /code-review my-feature to get a verdict and a list of findings before deciding whether to ship or iterate. ## Quick Start Run /code-review with the slug of a previously built change to get a ship or rework verdict with severity-tagged findings.

Frequently Asked Questions about code-review

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

FAQPage Schema
How do I review a code change against its original plan?

Run /code-review with the slug of the change after building it. The skill gathers the plan, build report, and git diff, then spawns one reviewer subagent that returns a ship or rework verdict with severity-tagged findings.

When should I run code-review in a build workflow?

Run it after /code-build completes for a given slug. It acts as the verification gate between building a change and shipping it, and its rework findings feed directly into the next /code-build iteration.

Does the reviewer subagent fix the issues it finds?

No, the reviewer is strictly read-only. It only identifies and severity-tags findings; when the verdict is rework, those findings are handed back as input for a repeated /code-build run, and the user decides what to fix.

What inputs does the code review need to work?

It needs the plan file swarm-report/<slug>-plan.md, the build report swarm-report/<slug>-build.md, and a git diff of staged plus unstaged changes or a diff against the branch point. The diff is pasted directly into the reviewer prompt.

Why does the reviewer not re-read the whole repository?

The diff is pasted directly into the reviewer prompt along with the plan reference, so the reviewer evaluates only the relevant change context. This keeps the review focused and avoids redundant repository scanning.