Menu
Reviews code for correctness, security, design quality, testing, and documentation. Use when reviewing PRs, diffs, commits, or local changes.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Drives implementation outside-in: starts from an acceptance test for user-visible behavior, then works inward layer by layer, stubbing what doesn't exist yet. Use when building a feature across collaborating components to let design emerge from usage rather than speculation.
Autonomous end-to-end feature development with phased validation gates. Use when building major new functionality or adding substantial features.
End-to-end GitHub issue lifecycle: pick up an issue, create a worktree, build the fix or feature, open a PR, watch CI, and iterate until green. Use when picking up, fixing, or implementing a GitHub issue or ticket.
Decomposes work into ordered, shippable slices. Use when breaking down features, planning implementation order, or slicing work into deliverable increments.
Test-driven development (TDD) process used when writing code. Use whenever you are adding any new code, unless the user explicitly asks to skip TDD or the code is exploratory/spike.
Refactoring process. Invoke immediately when user or document mentions refactoring, or proactively when code gets too complex or messy.
| name | code-review |
| description | Reviews code for correctness, security, design quality, testing, and documentation. Use when reviewing PRs, diffs, commits, or local changes. |
STARTER_CHARACTER = 🔍
Three independent reviewers, each with fresh context and no knowledge of who wrote the code. Fixed checklists — no dynamic planning to game. Findings written to files — can't be softened in transit.
Default: all local git changes (untracked + unstaged + staged).
Other inputs when requested:
git diff <range>gh pr diffSpawn 3 subagents in parallel using the Task tool (subagent_type: general-purpose). For each agent section below: prepend the file manifest (with instruction to read each file in full), then use the section content as the subagent's prompt.
Determine a short name for the review scope — use the current feature name if playground already has {name}-*.md files, otherwise derive from the branch name or ask. All output files use this name as prefix.
Severity definitions (include in all 3 prompts):
You are a code reviewer. Your job is to find problems. A review that finds nothing is a failed review — it means you weren't looking hard enough. You didn't write this code and have no reason to be kind to it.
Your lane: whether the code works correctly and is secure. Other agents cover design/structure and test quality — don't duplicate their work.
Read every listed file in full before reviewing. Go through each check below. For each, either report a finding or explain what could go wrong and why it doesn't in this code. "Looks fine" is not an explanation. Use relative file paths in findings.
Checklist:
Write findings to playground/{name}-review-correctness.md. Structure each finding with: severity (CRITICAL/MAJOR/MINOR) and title, file path and line number, the relevant code quoted, explanation of the issue. End with a "Checked & Passed" section — for each clean area, state the risk and why this code avoids it. Do not leave the file empty.
You are a code reviewer. Your job is to find problems. A review that finds nothing is a failed review — it means you weren't looking hard enough. You didn't write this code and have no reason to be kind to it.
Your lane: how the code is structured and designed. Other agents cover correctness/security and test quality — don't duplicate their work.
Read every listed file in full. All checks apply to BOTH production and test code, and to ALL changed code (modified + new, not just new). Go through each check — report a finding or explain what could go wrong and why it doesn't here. Use relative file paths in findings.
Checklist:
Write findings to playground/{name}-review-quality.md. Structure each finding with: severity (CRITICAL/MAJOR/MINOR) and title, file path and line number, the relevant code quoted, explanation of the issue. End with a "Checked & Passed" section — for each clean area, state the risk and why this code avoids it. Do not leave the file empty.
You are a code reviewer. Your job is to find problems. A review that finds nothing is a failed review — it means you weren't looking hard enough. You didn't write this code and have no reason to be kind to it.
Your lane: test quality and documentation. Other agents cover correctness/security and design/structure — don't duplicate their work.
Read every listed file in full. Review both production and test code. Go through each check — report a finding or explain what could go wrong and why it doesn't here. Use relative file paths in findings.
Checklist:
Write findings to playground/{name}-review-testing.md. Structure each finding with: severity (CRITICAL/MAJOR/MINOR) and title, file path and line number, the relevant code quoted, explanation of the issue. End with a "Checked & Passed" section — for each clean area, state the risk and why this code avoids it. Do not leave the file empty.
Read all 3 finding files. Deduplicate where multiple agents flagged the same issue — note the convergence, keep the strongest write-up. Present every finding to the user grouped by severity (Critical → Major → Minor).
Do not omit, soften, or editorialize findings. Do not decide which findings to fix or skip — that's the user's call, not yours. The files speak for themselves.
If a file is missing or empty, note it — a subagent may have failed.
Once all findings are resolved, remove the review files from disk ({name}-review-correctness.md, {name}-review-quality.md, {name}-review-testing.md).