菜单
Use when the user says 'deep review', 'thorough review', 'full review', 'triple review', or 'ultra review'.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when executing a preflight checklist. Triggers: 'fly', 'launch execution', 'run the checklist', or when given a preflight checklist file path.
Use when the user says '/learn', 'learn this', 'document this', 'capture this', 'remember this for next time', 'update the docs', asks to capture a durable project learning, or after fixes/reviews reveal reusable patterns.
Use when the user asks to merge, land, rebase before landing, resolve landing conflicts, or advance an integration branch such as main, master, or m3.
Use when the user asks to close, end, clean up, tear down, or finish a worktree/session after work is landed.
Use when starting an interactive parent task session, when the user gives feedback about agent behavior, or when the user asks about observations, skill improvements, or observation logs. Skip delegated/non-interactive subagents, review-only workers, verify-only workers, Codex/Claude print-mode reviewers, and sessions that only report back to a parent agent.
Use when the user says 'new session', 'start a session', 'new worktree', 'start fresh', or 'spin up a workspace'.
| name | deep-review |
| description | Use when the user says 'deep review', 'thorough review', 'full review', 'triple review', or 'ultra review'. |
| user-invocable | true |
Run multiple independent review passes in parallel, consolidate findings, auto-fix what's safe, verify the fixes, and present the rest for user decision.
The value of multi-agent review is that each reviewer has a different perspective and catches different things. An independent reviewer from the other agent family doesn't share the blind spots of the agent that wrote the code. A UI reviewer catches usability issues that a code-focused review misses. Running them in parallel costs no extra wall-clock time.
This skill orchestrates a comprehensive review by combining up to six perspectives:
After all reviews complete, findings are consolidated, deduplicated, and categorized for action.
Figure out what to review based on the current state:
# Check for uncommitted changes
UNCOMMITTED=$(git status --porcelain | wc -l | tr -d ' ')
# Check how many commits ahead of local main
AHEAD=$(git log main..HEAD --oneline 2>/dev/null | wc -l | tr -d ' ')
Also check whether frontend files are in the diff (.tsx, .jsx, .css, .scss, component files, layout files). This determines whether the UI review runs.
Run these simultaneously. Do NOT wait for one to finish before starting the next.
Examine every changed file in the diff and ask: "Is this change strictly required for the feature being reviewed, or does it modify existing working behavior?"
For each hunk in pre-existing files, check:
Flag each collateral change with the file path and a brief explanation of what it changes and why it's unrelated to the feature. These go into a dedicated Collateral Changes section in the consolidated review (not auto-fixed - always presented for user decision on whether to keep or revert).
Analyze the diff yourself. Focus on:
Use git diff (for uncommitted) or git diff main...HEAD (for branch) to read the actual changes.
Adversarial self-review prompt: before accepting the diff, ask exactly: "you are now a senior dev and you think the code you just wrote sucks hard. why?" Treat the answer as review evidence, not as self-deprecation.
Why this exists: The agent that wrote the code and the agent reviewing it share the same context window. Rules read at session start fade as context fills. This review step re-reads project rules with fresh eyes and systematically checks the diff against them.
Step 1: Re-read the project rules. Read CLAUDE.md (or AGENTS.md) and any docs it references that are relevant to the changed files. Don't rely on what you "remember" from earlier in the session - actually re-read them now. If the project has a reference table mapping topics to docs (e.g. "forms -> docs/ai/form-guidelines.md"), read the docs that match the changed file types.
Step 2: For each rule, grep the diff for violations. Common patterns to check (adapt to the project's specific rules):
# Hardcoded values that should come from config or data
git diff main...HEAD -- ':!*.test.*' | grep -n '= ""' | grep -v 'class\|placeholder\|useState'
git diff main...HEAD -- ':!*.test.*' | grep -n 'fetch(' | grep -v 'test\|spec\|mock'
# Duplication - new files that mirror existing ones
git diff main...HEAD --name-only --diff-filter=A # newly added files
# For each new file: does an existing file already handle this?
# Data fields added to types but not wired through the full chain
git diff main...HEAD | grep -A2 'interface\|type.*=' # new fields in types
# For each new field: is it in the DB select? In all callers?
Step 3: Check architectural rules. For each changed file, verify:
Rule violations found here are Must Fix, not suggestions. They represent the exact class of bug that the coding agent is blind to because of context pressure.
Invoke the /simplify skill via the Skill tool. It has its own tuned logic for finding code reuse, unnecessary complexity, dead code, efficiency issues, and API surface bloat. Do NOT replicate its logic inline - the skill is better at it.
The skill operates on recently changed code by default, which matches the deep-review scope.
Before dispatching Review 3, identify the current orchestrator:
This is intentionally based on the agent running the skill, not on which agent wrote the diff. The goal is to force a second review engine with different defaults, tool behavior, and blind spots.
Launch the independent reviewer in the background while you do reviews 1 and 2. Use the agent's background execution mechanism so it runs concurrently with your own analysis. Set timeout: 300000 (5 minutes) - independent reviews can take longer than the default 2 minutes on large diffs.
Project context first: if the project has docs/ai/codex.md, read it before invoking Codex — projects often pin extra flags (e.g. --dangerously-bypass-approvals-and-sandbox for browser walkthroughs) or document the local convention for piping prompts.
Launch Codex in the background while you do reviews 1 and 2:
# For uncommitted changes:
codex review --uncommitted
# For branch changes:
codex review --base main
Do NOT pass an inline prompt argument with --uncommitted or --base — the codex CLI rejects that combination (error: the argument '--uncommitted' cannot be used with '[PROMPT]'). The flags select scope; codex review runs its default review on that diff. If you need to feed custom instructions, pipe via stdin with - and consult docs/ai/codex.md for the project's preferred prompt-file pattern.
Important: --base takes a BRANCH name, NOT a SHA. If your scope is a SHA range (e.g. <phase-base>^..<phase-head> from /fly's phase-gate deep-review), create a temp branch at the base SHA first - DO NOT skip codex.
git branch -f /tmp/codex-base <phase-base>^
codex review --base /tmp/codex-base
git branch -D /tmp/codex-base # cleanup after dispatch
Run Claude Code in non-interactive print mode and feed it the exact review diff. Keep staged and unstaged changes separate so it can catch index-only mistakes and unstaged follow-up edits.
# For uncommitted changes:
git diff --cached > /tmp/deep-review-staged.patch
git diff > /tmp/deep-review-unstaged.patch
{
printf '%s\n' 'You are the independent reviewer for /deep-review.'
printf '%s\n' 'Do not invoke or read task-observer; this is a delegated/non-interactive review and the parent session logs observations.'
printf '%s\n' 'Review only. Do not modify files. Report correctness, safety, tests, maintainability, and rule-compliance findings with file:line references.'
printf '%s\n' 'STAGED DIFF:'
cat /tmp/deep-review-staged.patch
printf '%s\n' 'UNSTAGED DIFF:'
cat /tmp/deep-review-unstaged.patch
} | claude -p
# For branch changes:
{
printf '%s\n' 'You are the independent reviewer for /deep-review.'
printf '%s\n' 'Do not invoke or read task-observer; this is a delegated/non-interactive review and the parent session logs observations.'
printf '%s\n' 'Review only. Do not modify files. Report correctness, safety, tests, maintainability, and rule-compliance findings with file:line references.'
git diff main...HEAD
} | claude -p
If your scope is a SHA range (e.g. <phase-base>^..<phase-head> from /fly's phase-gate deep-review), feed that exact diff to Claude Code:
{
printf '%s\n' 'You are the independent reviewer for /deep-review.'
printf '%s\n' 'Do not invoke or read task-observer; this is a delegated/non-interactive review and the parent session logs observations.'
printf '%s\n' 'Review only. Do not modify files. Report correctness, safety, tests, maintainability, and rule-compliance findings with file:line references.'
git diff <phase-base>^..<phase-head>
} | claude -p
The independent reviewer perspective is load-bearing for deep-review; skipping it loses one of the six sub-reviewers and degrades the review.
If the diff includes frontend files (.tsx, .jsx, .css, .scss, or component/layout/page files), launch a subagent in the background to do a UI-focused review. The subagent uses Playwright MCP to actually interact with the running app - not just read code. It should:
browser_navigate to the relevant URLbrowser_take_screenshot for visual layout assessmentbrowser_snapshot for accessibility tree / content verificationbrowser_click, browser_type, browser_hover, browser_press_keyprefers-reduced-motionThis is better than delegating UI review to the independent code reviewer because the UI subagent has direct access to the codebase, can render and interact with the actual UI, and catch behavioral issues that code-only review misses.
Skip this review entirely if no frontend files are in the diff.
Once all reviews are complete, merge the results:
Deduplicate - if multiple reviews flag the same issue, mention it once and note that multiple reviewers caught it (higher confidence).
Categorize every finding into one of three buckets:
Must fix (auto-fix these)
npm test shows red on the touched paths, fix it as part of the review. Tests that were passing before but flake/break under your changes are NEW failures (always must-fix). Tests that were broken before need fixing too — they're a correctness signal someone has been ignoring and the deep-review is the moment to clear them.Easy wins (auto-fix these)
Fix these too (auto-fix, but note them in the summary)
Defer (present for user decision - do NOT auto-fix)
Present the consolidated review in this format:
## Deep Review Summary
Reviewed by: <orchestrator> (diff + simplify + collateral audit), <independent reviewer>[, UI review]
Scope: [uncommitted changes / branch diff against main]
Files changed: [count] ([N] frontend)
### Collateral Changes (for your decision)
- [ ] file:line - what changed and why it's unrelated to the feature
### Must Fix (auto-fixing)
- [ ] Issue description - file:line - what's wrong and how it's being fixed
### Easy Wins (auto-fixing)
- [ ] Issue description - file:line - what's wrong and how it's being fixed
### Also Fixing (reviewer suggestions, straightforward)
- [ ] Issue description - file:line - what's being improved
### Deferred (big-effort, out of scope, or debatable)
For each deferred item, use this format - plain English, no jargon, framed in product/user terms:
- [ ] **<plain-English title>**
- **What's happening:** <2-3 sentences describing the issue in user/product terms. Avoid "type", "cast", "interface", "ref" unless it's the only honest framing - prefer "when a user does X, the app does Y instead of Z". Translate file:line citations into "the X feature does Y when Z".>
- **User-facing impact:** <one sentence: what does the user actually see, feel, lose, or risk if this stays unfixed? Examples: "Users on slow connections see a flash of empty state before content loads", "If two people edit the same form at once, one set of changes silently overwrites the other", "Nothing visible today, but every new field added has to be manually wired in 4 places - one will get missed and that field will silently not save". If there's truly no user-visible impact, say so explicitly: "No user-facing impact - this is purely about <code maintainability / future-proofing>" - don't pad.>
- **Why I'm not fixing it now:** <one short sentence: needs your decision / phase-sized work / risky-and-debatable>
- **Where:** file:line
Why this format matters: without the user-facing impact line, deferred items read as engineering todos and the user has no way to weigh them against other work. With it, they read as product decisions, which is the framing needed to actually decide. If you cannot articulate a user-facing impact (even "no user-facing impact - purely internal"), you do not understand the finding well enough to defer it - re-read the reviewer's notes.
Before applying other fixes, check and update the architecture diagram if drift exists.
If docs/ai/architecture.md exists and has a ## This diagram covers section:
A/D/R file statuses) under those pathsdocs/ai/architecture.md itself was already modified in this diff/sync-architecture. It edits the diagram directly (no approval gate) and leaves the update unstaged.Note the architecture update in your consolidated summary as "Architecture diagram auto-synced (N structural changes)" so the user can spot it when reviewing the auto-fixes.
Skip this step silently if there's no docs/ai/architecture.md, no coverage section, or no structural changes.
Apply fixes for all items in "Must fix", "Easy wins", and "Fix these too":
npx tsc --noEmit 2>&1 | tail -20
npm run lint 2>&1 | tail -20
cargo check, go vet, ruff check).After applying all fixes from step 4, run one more review cycle to make sure the fixes didn't introduce new issues or reveal problems that were masked by the original code.
# If the independent reviewer is Codex:
codex review --uncommitted
# If the independent reviewer is Claude Code:
git diff --cached > /tmp/deep-review-staged.patch
git diff > /tmp/deep-review-unstaged.patch
{
printf '%s\n' 'You are the independent reviewer for the /deep-review verification round.'
printf '%s\n' 'Do not invoke or read task-observer; this is a delegated/non-interactive review and the parent session logs observations.'
printf '%s\n' 'Review only. Do not modify files. Report only new issues introduced by the fixes.'
printf '%s\n' 'STAGED DIFF:'
cat /tmp/deep-review-staged.patch
printf '%s\n' 'UNSTAGED DIFF:'
cat /tmp/deep-review-unstaged.patch
} | claude -p
timeout: 300000 (5 minutes) as in step 2.After auto-fixes and verification are complete, present only the deferred items. Use the exact same plain-English / user-facing-impact format from step 3 - do not abbreviate to a one-liner here. The user is being asked to make a decision; they need the same context the consolidated review had.
"I've auto-fixed [N] items across must-fix, easy-wins, and reviewer suggestions. Verification round: [clean / fixed X additional items].
The changes are uncommitted so you can review them.
[If deferred items exist:] These [X] items I left alone - they need your call. Each is described in plain English with the user-facing impact, so you can weigh them without digging into the code:
[for each deferred item, render the full block:]
- What's happening: <2-3 sentences in user/product terms>
- User-facing impact: <one sentence: what the user sees / risks / loses, or "No user-facing impact - purely internal">
- Why I'm not fixing it now:
- Where: file:line
Want me to tackle any of these?"
Anti-pattern: "Issue: unsafe cast at form.tsx:42 - deferred because it needs a refactor." This is the engineering framing the user just told you not to use. The right framing: "When users edit forms with custom field overrides, the app could crash on save because we're not validating the override shape. User-facing impact: rare today (only one form uses overrides), but if we add more, the crash surface grows silently. Not fixing now: needs a small schema refactor that touches the form types in 3 places. Where: form.tsx:42."
Before final response, identify review findings or auto-fixes that reveal a
reusable bug class, missing guardrail, repeated workflow issue, or architecture
gap. For each durable pattern, invoke /learn capture with:
reviewBefore writing a new entry, check the last five active learnings and same-session learning captures. Do not create duplicate learning entries for issues already captured by bugfix, QA, task-observer, review, or before-merge checks. If the learning is already covered, say:
🧠 Learning already captured: <plain-English summary>
If new evidence materially improves the existing learning, update that entry's
Sources, evidence trail, confidence, or technical refs instead of creating a
sibling. When a learning is newly captured, say:
🧠 Captured learning: <plain-English summary>