skills/review-code/SKILL.md
Review code for bugs, security vulnerabilities, API misuse, consistency issues, simplicity problems, or test coverage gaps by running internal reviews and a peer review in parallel and returning combined findings. Single-concern with a type argument, or full review with no argument. Use when the user asks to "review my code", "full code review", "review my changes", "check for bugs", "scan for bugs", "review correctness", "security audit", "find vulnerabilities", "review security", "check API usage", "verify against docs", "check for cross-file duplication", "review consistency", "check for code reuse", "review simplicity", "find untested code", or "review test coverage".
npx skillsauth add tobihagemann/turbo review-codeInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Review code against type-specific criteria. Runs internal reviews and /peer-review in parallel by default. Returns combined structured findings.
Types: correctness, security, api-usage, consistency, simplicity, coverage
With a type argument, runs a single-concern internal review plus the peer review. With no type argument, runs all six internal reviews plus the peer review.
Determine what to review:
git diff --cached, git diff main...HEAD), use that.gh repo view --json defaultBranchRef --jq '.defaultBranchRef.name'). If there are no changes against the default branch, stop and state that there is nothing to review.Read the reference file(s) for the active type(s):
Full review activates all six types; a single-concern argument activates one. Skip peer review when instructed (e.g., "without peer review", "no peer", "internal only").
Use the Agent tool to launch all agents below in a single assistant message so they run concurrently. Each Agent call uses model: "opus" and does not set run_in_background. For full review that is seven Agent tool calls (six internal + one peer); for single-concern it is two (one internal + one peer).
/peer-review via the Skill tool with a request describing: (a) the scope to review; (b) each active type as a separate review dimension so they are reviewed independently; (c) for each dimension, the criteria live in ~/.claude/skills/review-code/references/<type>-review.md — the reviewer should read that file directly, use its priority scale and verdict label, and include any extra metadata fields it specifies (e.g., **Category:**, **Library:**, **Docs:**) between the **Reviewer:** line and the paragraph.Aggregate findings with attribution (reviewer: "internal" or "peer"; type; file path). Present them in the output format below.
Then use the TaskList tool and proceed to any remaining task.
Return findings as a numbered list. For each finding:
### [P<N>] <title (imperative, ≤80 chars)>
**File:** `<file path>` (lines <start>-<end>)
**Reviewer:** <internal | peer> (<type>)
<one paragraph explaining the issue and its impact>
The reference file may specify additional metadata fields (e.g., **Category:**, **Library:**, **Docs:**). Include them between the **Reviewer:** line and the paragraph.
After all findings, add an overall verdict per active type using the label from each reference file. For single-concern, that is one verdict block; for full review, six. After the per-type verdicts, add a single combined ## Peer Review Verdict block summarizing what the peer review returned.
## Overall Verdict — <type>
**<Verdict Label>:** <status>
<1-3 sentence assessment>
If there are no qualifying findings for a type, state so under that type's verdict block and explain briefly.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Apply a UX lens to a user-facing change: whether it serves the user's real goal and whether the path through it holds together, using the Understanding, Bridging, and Flowing contexts. Use when scoping, planning, or assessing any change that affects what a user sees or does. Loaded as a lens during planning and assessment.
development
Assess project-wide structural technical debt: complexity hotspots, deprecated API usage, duplication clusters, and architecture rot. Ranks findings by impact and refactor effort into a report at .turbo/technical-debt.md. Use when the user asks to "assess technical debt", "find technical debt", "review technical debt", "what should we refactor", "find refactoring candidates", "where is the code rot", or "what's our worst code". Analysis-only — does not modify code.
development
Run a multi-agent review of code comments and markdown documentation for unnecessary content, then fix the issues. Covers what-restating comments, name-mirroring doc comments, status-update prose, and other documentation noise. Use when the user asks to "simplify docs", "simplify documentation", "clean up comments", "clean up docs", "review documentation", "strip unnecessary comments", "reduce doc noise", or "run simplify-docs".