菜单
Reviews code for correctness, security, design quality, testing, and documentation. Use when reviewing PRs, diffs, commits, or local changes.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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).