Review
Opinionated engineering pipeline for Claude Code with 10 skills, 5 agents, 2 hooks. Replaces ad-hoc agent sprawl with brainstorm → story → plan → build → review → ship.
npx -y skills add nicodiansk/turbocharge --skill reviewAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use before merging to verify completed work meets requirements and quality standards. Dispatches code-reviewer for holistic assessment of the full git diff against the original plan.
SKILL.md
2.9 KB, as published. Nobody here has run it
Code Review
Holistic pre-merge review of completed work against the original plan.
Announce: "Using review to assess this work before merge."
The Iron Law
NO MERGE WITHOUT CODE REVIEW
Context
The plan or requirements being reviewed: $ARGUMENTS
Dispatch the code-reviewer agent with this prefix so the subagent sees the navigation index (subagents do not inherit parent history):
@ATLAS.md (navigation index — use Module Map + Key Symbols to locate touched modules)
@CLAUDE.md (conventions, rules)
Omit either reference if the file doesn't exist.
Your Review
-
Get the git diff:
BASE_SHA=$(git merge-base HEAD main 2>/dev/null || git merge-base HEAD develop 2>/dev/null || git merge-base HEAD master 2>/dev/null) git diff $BASE_SHA..HEAD -
Read the plan/requirements referenced above
-
Review for:
- Plan alignment — Does implementation match what was planned?
- Code quality — Clean, maintainable, well-tested?
- Architecture — SOLID, good separation, integrates well?
- Security — No vulnerabilities, input validated, secrets safe?
-
Report:
- Strengths — What was done well
- Issues — Critical / Important / Minor with
file:linereferences - Assessment — Ready to merge? Yes / No / With fixes
After review, offer: "Ready to ship?" → chains to /turbocharge:ship
Red Flags — Rationalizations That Mean You're Doing a Shallow Review
If you catch yourself thinking any of these, STOP — you are about to deliver exactly the kind of review that wastes everyone's time:
| Thought | Why It's Wrong |
|---|---|
| "The code looks reasonable, I'll summarize the changes" | Summarizing is not reviewing. Read every changed line. |
| "I'll focus on the important files and skim the rest" | The bug is always in the file you skimmed |
| "The tests pass, so the logic must be correct" | Tests can pass while testing the wrong thing |
| "This is a minor change, quick review is fine" | Minor changes to core logic cause major production incidents |
| "I've reviewed similar code before, I know the patterns" | This review is about THIS diff, not past patterns |
| "Let me check the main concerns and wrap up" | Checking "main concerns" is a euphemism for a partial review |
Review Completeness Checklist
Before reporting your assessment, verify:
- Read EVERY file in the diff (state count: "Reviewed X of Y changed files")
- Compared implementation against EVERY requirement in the plan
- Checked for issues that tests DON'T catch (naming, architecture, security)
- Verified no orphaned code, dead imports, or unfinished TODOs