skills/review-plan/SKILL.md
Review a planning artifact (plan, shells, or spec) by running internal and peer reviews in parallel and returning combined findings. Use when the user asks to "review my plan", "review my shells", "review my spec", "check my plan", "check my shells", "check my spec", "critique my plan", "critique my shells", "critique my spec", or wants feedback on a planning artifact.
npx skillsauth add tobihagemann/turbo review-planInstall 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 a planning artifact against type-specific criteria. Runs internal review and /peer-review in parallel by default. Returns combined structured findings.
.turbo/ for existing artifacts. If multiple types exist, pick the one with the most recently modified file..turbo/plans/<slug>.md.turbo/plans/*.md. If exactly one file exists, use it.turbo/plan.md if .turbo/plans/ does not exist.turbo/shells/<slug>-*.md.turbo/specs/*.md. If exactly one, derive slug and glob for shellsFor shells, read each shell file and parse its YAML frontmatter (spec, depends_on). Read the source spec from the spec field.
.turbo/specs/<slug>.md.turbo/specs/*.md. If exactly one, use it.turbo/spec.md if .turbo/specs/ does not existIf multiple candidates exist, pick the most recently modified.
Read the reference file for the resolved type:
Skip peer review when the caller asked (e.g., "without peer review", "no peer", "internal only"). For shells, the internal review focuses on structural wiring and skips the project context read.
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. That is two Agent tool calls when peer review is active (one internal + one peer), or one Agent tool call when peer review is skipped.
/peer-review via the Skill tool with a request describing: (a) the artifact under review; (b) the criteria live in ~/.claude/skills/review-plan/references/<type>-review.md for the resolved type from Step 1 — the reviewer should read that file directly and use its priority scale; (c) the Overall Verdict should use the Readiness: <ready | needs revision> label.Aggregate findings with attribution (reviewer: "internal" or "peer"). 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)>
**Section:** <plan section, shell number(s), or spec section>
**Reviewer:** <internal | peer>
<one paragraph explaining the issue and its impact>
After all findings, add:
## Overall Verdict
**Readiness:** <ready | needs revision>
<1-3 sentence assessment>
If there are no qualifying findings, state so 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".