菜单
Use when you have finished a task, completed a major feature, fixed a complex bug, or are about to merge to main — any point where you would otherwise move on, commit, or open a PR without an independent review of the diff
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when creating, editing, reviewing, or rendering software architecture or flow diagrams — C4 diagrams (system context, container, component, deployment, dynamic), sequence diagrams, request-flow visuals, or any Mermaid authoring where the rendered output must be readable. Also use when a Mermaid diagram renders with overlapping labels, parse errors, or a single-column layout, or when the user asks to "diagram the architecture", "draw the request flow", "map the sequences", or wants LucidChart-quality output from Mermaid.
Use when about to create a feature, build a component, add functionality, modify behavior, or start any new work — or when the user asks how should we, what approach, which way, explore options, design X, or spec this out. Triggers before any code, scaffold, or implementation skill runs.
Use when one request spans multiple domains (e.g. code + tests + docs + security + diagrams), has independent workstreams that could run concurrently, or is too large for a single agent in one pass — symptoms include "do all of X, Y, and Z", a multi-part review, or a task that would obviously thrash one agent's context
Use when defining product requirements, writing or updating a PRD, spec'ing out a feature, or deciding what to build — or when the user says write requirements, create a PRD, define the product, what should we build, or hands over stakeholder/engineering feedback to fold into an existing PRD. Especially for non-technical users translating a conversation into structured requirements.
Use when you want brutal, worst-case review of code resilience -- failure modes, race conditions, blast radius, and edge cases optimistic reviewers miss.
Use when reviewing code or a PR for high-confidence, real-exploitation security vulnerabilities (>80% confidence threshold, low false positives).
| name | requesting-code-review |
| description | Use when you have finished a task, completed a major feature, fixed a complex bug, or are about to merge to main — any point where you would otherwise move on, commit, or open a PR without an independent review of the diff |
Type: rigid (discipline). Follow exactly. Do not adapt away the review gate.
This is the dispatch wrapper for constellation:code-review: it builds the reviewer's context and hands off the diff. The reviewer gets precisely constructed context — git SHAs and the requirements — never your session history. That keeps the reviewer focused on the work product instead of the reasoning that produced it, and preserves your own context to keep working.
Core principle: review early, review often.
Violating the letter of the rules is violating the spirit of the rules.
NO PROCEEDING PAST A MANDATORY TRIGGER WITHOUT AN INDEPENDENT REVIEW OF THE DIFF
A mandatory trigger fires and you have not dispatched a reviewer = stop. Self-review is not review. "It's simple" is not an exemption. Reading your own diff again is not an independent review.
Mandatory (do not proceed without it):
Optional but valuable:
BASE_SHA=$(git rev-parse HEAD~1) # or origin/main
HEAD_SHA=$(git rev-parse HEAD)
Dispatch the reviewer with the Task tool, filling the template at
references/code-reviewer-prompt.md. Placeholders:
{DESCRIPTION}, {PLAN_OR_REQUIREMENTS}, {BASE_SHA}, {HEAD_SHA}.
gh pr diff --name-only
(or git diff --name-only BASE_SHA..HEAD_SHA) and review ONLY those files.
This stops reviewers from drifting into merged worktree code or unrelated
modules.Workflow tool, use agentType Explore or omit it (never
general-purpose), and do not force model: opus.Act on feedback by severity:
| Severity | Action |
|---|---|
| Critical | Fix immediately. Do not proceed, commit, or merge until resolved. |
| Important | Fix before moving to the next task. |
| Minor | Note for later; may proceed. |
If the reviewer is wrong, push back with technical reasoning — show the code or the failing-then-passing test that proves it. Do not silently comply, and do not silently ignore.
These thoughts mean a trigger fired and you are about to skip the gate:
| Excuse | Reality |
|---|---|
| "It's too simple to review" | Simple changes break things too. Dispatch the reviewer. |
| "I reviewed it myself" | Self-review is not independent. The author is blind to their own gaps. |
| "I'll batch the review later" | Issues compound. Review each task before the next. |
| "Reviewer flagged it but it works" | Prove it: show the code/test. Then push back — don't ignore. |
| "Important issues can wait" | "Later" never comes. Fix before proceeding. |
| "I'll just give it my whole context" | Constructed context (SHAs + requirements) only. History pollutes judgment. |
| "Let the reviewer look at everything" | Pin to gh pr diff --name-only. Out-of-scope review is noise. |
Dispatch context:
✅ BASE_SHA + HEAD_SHA + requirements + "review only `gh pr diff --name-only`"
❌ "Here's my whole session; tell me what you think of the changes"
Acting on feedback:
✅ Critical found → fix now → re-verify → only then proceed
❌ "Critical noted, I'll circle back" → moves to next task
Pushing back:
✅ "This isn't a bug — test X drives the real path and fails when reverted: [output]"
❌ Silently dismiss the finding, or silently rewrite the code anyway
Make the dispatch and each resulting Critical/Important issue a TodoWrite entry. Untracked review findings get skipped — every time.
A trigger fires → build the context → dispatch the reviewer pinned to the diff → act by severity. No proceeding without it.