[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6JYSCD7VX79P8XCDDPAYXNT":3,"skill-same:01M6JYSCD7VX79P8XCDDPAYXNT":91},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":23,"publishedAt":45,"linkOnly":46,"markdownContent":47,"markdownBody":48,"frontMatter":49,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":6,"ownerHtmlUrl":68,"ownerBlogUrl":69,"ownerDescription":70,"updatedAt":71,"install":72,"resources":84},"01M6JYSCD7VX79P8XCDDPAYXNT","plan-swarm-review",null,"Iterative plan review using multisampling + focused decomposition.\nLaunches parallel independent agents to find issues that single-pass\nreview misses. Up to four bounded rounds: broad, multisample, focused,\nfocused-plus-multisample. Use when: \"swarm review\", \"review plan thoroughly\",\n\"multisample review\", \"deep plan review\", \"plan swarming\", \"stress test\nthe plan\", or when evidenced cross-component risk warrants deeper plan review.\nSize alone does not require a swarm or another review round. Do NOT use to\ndesign a multi-agent harness or Generator-Evaluator architecture from scratch;\nuse harness-design for that. Ordinary code\u002Fdiff review routes to deep-review;\nuse this skill's code mode only when the user explicitly requests a swarm\nsecurity\u002Fbug review of code.","AnastasiyaW\u002Fcodex-claude-code-config","AnastasiyaW","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F92753226?v=4","01M6JYPD9X5RRF8G7AH91NYD3R","Anastasiia Butova","01M6JYPDFBGM5EV8G8BABQ3GDY",214,"MIT","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Farchitecture\u002Fplan-swarm-review\u002FSKILL.md",[18],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44],"review","plan swarm review","plan","swarm","when","design","mode","decomposition","deep","deeper","bug","up","only","review round","edit","write","read","issues","code","architecture","component","2026-11-10 10:12:30",false,"---\nname: plan-swarm-review\ndescription: |\n  Iterative plan review using multisampling + focused decomposition.\n  Launches parallel independent agents to find issues that single-pass\n  review misses. Up to four bounded rounds: broad, multisample, focused,\n  focused-plus-multisample. Use when: \"swarm review\", \"review plan thoroughly\",\n  \"multisample review\", \"deep plan review\", \"plan swarming\", \"stress test\n  the plan\", or when evidenced cross-component risk warrants deeper plan review.\n  Size alone does not require a swarm or another review round. Do NOT use to\n  design a multi-agent harness or Generator-Evaluator architecture from scratch;\n  use harness-design for that. Ordinary code\u002Fdiff review routes to deep-review;\n  use this skill's code mode only when the user explicitly requests a swarm\n  security\u002Fbug review of code.\nmetadata:\n  user-invocable: true\n  upstream-model-hint: opus\nallowed-tools:\n  - Read\n  - Grep\n  - Glob\n  - Agent\n  - AskUserQuestion\n  - TodoWrite\n  - Edit\n  - Write\n---\n\n# Plan Swarm Review\n\nIterative plan hardening through multisampling and focused decomposition.\n\n## Scope and task ownership\n\nThe user's current task and selected model govern this review. Audit-only is\nread-only unless changes are requested. In an already authorized implementation\nor repair task, apply confirmed in-scope reversible fixes and run their focused\ncausal checks; do not ask again merely because a review round found the problem.\nAn optional deeper review does not block those fixes or the original milestone.\nStop expanding review when the current acceptance criteria are sufficiently\nproved, then return to the owning task. Preserve actual external, deletion, and\nirreversible boundaries. The four rounds are a bounded menu, not a required loop.\n\n**Core insight**: a single agent misses issues due to attention budget limits.\nMultiple independent agents reading the same document find different problems\n(stochastic diversity). Focused decomposition further improves depth per aspect.\nIterative fix-then-re-review uncovers issues previously masked by other bugs.\n\nSource: deksden (@deksden_notes) — \"Plan Swarming\" technique, April 2026.\nRelated: Anthropic Harness Design (Generator-Evaluator), deep-review (parallel competency code review).\n\nResearch backing:\n- [2502.11027] Sampling diversity in LLM inference — diverse prompts beat identical: +10.8% reasoning, +9.5% code\n- [2602.09341] AgentAuditor — reasoning tree audit beats majority voting, recovers 65-82% of minority-correct findings\n- [2602.17875] MultiVer — 4 parallel agents hit 82.7% recall on vulnerability detection (beats fine-tuned models)\n- [2510.00317] MAVUL — multi-agent vuln detection: +600% vs single-agent\n- Anthropic Code Review (Mar 2026) — parallel agents raise substantive findings from 16% to 54%\n\n## Modes\n\nThis skill works in two modes:\n\n**Plan mode** (default): review design docs, specs, ADRs, RFCs before implementation.\n**Code mode**: review code files for bugs and vulnerabilities when the user\nexplicitly requests a swarm code review. Merely supplying a diff or asking for\nordinary code review routes to `deep-review`. In code mode, aspects shift from plan-oriented (contracts,\ncompleteness) to code-oriented (injection, auth bypass, race conditions, memory).\n\n---\n\n## Step 0: Identify the target document\n\nAsk the user which document to review if not obvious from context.\n\n**Plan mode**: PLAN.md, ADR, spec, design doc, RFC, or any structured\ndocument describing what will be built and how.\n\n**Code mode**: source code files, a module, or a directory. Best for\nsecurity audits, bug hunts, or pre-release quality checks.\n\n```\nRead the target document(s) fully. Note:\n- Total size (lines, sections\u002Ffiles)\n- Key components\u002Fmodules described or implemented\n- Interfaces between components\n- Data flows and mutations\n- External dependencies and trust boundaries\n```\n\nIf the target is \u003C100 lines with 1-2 simple components, suggest a single-pass\nreview instead — swarming is overkill for small targets.\n\n---\n\n## Step 1: ROUND 1 — Broad Review (single agent)\n\n**Purpose**: catch obvious issues before spending tokens on multisampling.\n\nLaunch ONE Agent with this prompt:\n\n```\nYou are a senior architect reviewing a plan document before implementation.\nYour goal: find issues that would cause bugs, rework, or confusion during\nimplementation.\n\n## Plan to review\n{paste or reference the plan document path}\n\nRead the entire plan. Then check for:\n\n1. CONTRACTS — are interfaces between components fully specified?\n   Types, error codes, required vs optional fields, versioning.\n2. DATA FLOW — is data transformation described end-to-end?\n   What happens at each boundary? Backward compatibility?\n3. NEGATIVE SCENARIOS — what happens when things fail?\n   Timeouts, partial failures, invalid input, race conditions.\n4. CONSISTENCY — do different sections contradict each other?\n   Same entity described differently in two places?\n5. COMPLETENESS — are there gaps? Steps that say \"TBD\" or \"later\"?\n   Scenarios mentioned but not covered?\n6. DEPENDENCIES — is implementation order clear?\n   Are blocking dependencies identified? Circular deps?\n7. AMBIGUITY — could two engineers read a section and implement\n   it differently? Vague terms like \"handle appropriately\"?\n\n## Output format\nFor EACH finding:\n\nFINDING: {one-line description}\nSECTION: {which section of the plan}\nSEVERITY: HIGH | MEDIUM | LOW\nEVIDENCE: {quote the problematic text, max 2 lines}\nFIX: {concrete change to the plan text}\n\nIf the plan is clean — output: \"NO_FINDINGS — plan review clean.\"\nDo NOT pad with praise. Only problems.\n```\n\n### After Round 1\n\nCollect findings. If **0 findings** → finish this review scope and return to the\nowning task; this is not proof that an implementation milestone is finished.\n\nIf findings exist:\n1. Present findings to user grouped by severity\n2. If fixes are already authorized, apply the confirmed scoped corrections and\n   run their focused checks. Otherwise report them within the audit-only request.\n3. Consider Round 2 only for a remaining concrete risk or an explicit depth request;\n   do not bundle permission for optional review with already authorized fixes.\n4. If user says stop → stop\n\n---\n\n## Step 2: ROUND 2 — Diverse Multisampling (N parallel agents, varied perspectives)\n\n**Purpose**: stochastic diversity catches what one pass missed.\n\n**IMPORTANT**: do NOT use identical prompts for all agents. Research [2502.11027]\nshows identical prompts produce correlated errors — agents \"cluster\" on the same\nissues and miss the same blind spots. Instead, give each agent a DIFFERENT\nperspective while reviewing the same document.\n\nLaunch **3 agents in parallel** (or 5 for critical plans), each with a\n**different reviewer persona**:\n\n**CRITICAL**: launch all agents in a SINGLE message (parallel tool calls).\nEach agent has isolated context — no cross-contamination.\n\n### Plan mode perspectives\n\n| Agent | Persona | Focus bias |\n|---|---|---|\n| 1 | **Skeptical implementer** | \"I have to code this tomorrow — what's unclear, contradictory, or impossible?\" |\n| 2 | **Security auditor** | \"Where are the trust boundaries? What happens with malicious input?\" |\n| 3 | **QA engineer** | \"How do I test this? What edge cases aren't covered? What breaks at scale?\" |\n| 4 | **New team member** | \"I just joined — what terms are undefined? What implicit knowledge is required?\" |\n| 5 | **Ops\u002FSRE** | \"What fails at 3am? What's the rollback plan? What's unmonitored?\" |\n\n### Code mode perspectives\n\n| Agent | Persona | Focus bias |\n|---|---|---|\n| 1 | **Attacker** | \"How do I exploit this? Injection, auth bypass, privilege escalation?\" |\n| 2 | **Concurrency specialist** | \"What races, deadlocks, or ordering issues exist?\" |\n| 3 | **Performance engineer** | \"What's O(n^2)? What allocates unbounded memory? What blocks the event loop?\" |\n| 4 | **Error recovery auditor** | \"What happens when X fails? Is cleanup correct? Are resources leaked?\" |\n| 5 | **Integration tester** | \"Do contracts match? Are types compatible? What breaks at boundaries?\" |\n\n```\nYou are a {PERSONA} reviewing {plan\u002Fcode} before implementation\u002Fdeployment.\nYour perspective: {FOCUS_BIAS}\n\nReview the ENTIRE document through your specific lens.\n{same checklist and output format as Round 1}\n```\n\n### After Round 2\n\n1. **Deduplicate**: group findings by section + issue type. When multiple\n   agents find the same issue → mark as HIGH CONFIDENCE (consensus).\n2. **Preserve minority findings**: a finding from only 1 of 5 agents is\n   NOT automatically low-value. Research [2602.09341] shows minority-correct\n   findings are often the most valuable — non-obvious bugs that only one\n   perspective catches. Flag these as UNIQUE CATCH, do not discard.\n3. **Synthesize**: produce merged report. Separate consensus vs unique catches.\n4. Present to user with round report format (see Output Format below).\n5. Apply already authorized scoped fixes; use Round 3 only for a concrete unresolved\n   risk or an explicit depth request, not as a condition for continuing implementation.\n\n**Review stop criteria**: no unresolved finding affecting current acceptance or\nsafety. A severity count is not proof: two material medium findings still need\nresolution. End this review branch without abandoning the owning task.\n\n---\n\n## Step 3: ROUND 3 — Focused Review (decompose into aspects)\n\n**Purpose**: narrow scope = deeper analysis per aspect.\n\n### Step 3a: Determine focus aspects\n\nBased on the target content, select 3-7 aspects.\n\n### Plan mode aspects\n\n| Aspect | When to include |\n|---|---|\n| **Contracts & Interfaces** | Plan describes >2 interacting components |\n| **Data Flow & Migrations** | Plan involves data transformation, DB changes, or state migration |\n| **Negative Scenarios** | Plan describes user-facing features or distributed systems |\n| **Consistency** | Plan is >300 lines or written by multiple authors |\n| **Completeness** | Plan references external systems or has phased rollout |\n| **Security & Trust** | Plan involves auth, user input, or external APIs |\n| **Dependencies & Order** | Plan has >5 implementation steps or parallel workstreams |\n\n### Code mode aspects (for bug\u002Fvulnerability hunting)\n\n**Before launching agents:** read `references\u002Fvulnerability-kb.md` for condensed detection\nheuristics per CWE class. Feed the relevant CWE heuristics into each agent's prompt.\nFull Vul-RAG entries with code examples: `knowledge-vault\u002Fdocs\u002Fsecurity\u002Fcwe\u002F`.\n\nBased on MultiVer [2602.17875] and VulAgent [2509.11523] patterns:\n\n| Aspect | What to trace |\n|---|---|\n| **Injection & Input Validation** | SQL\u002FNoSQL\u002Fcommand\u002FLDAP injection, XSS, path traversal, template injection |\n| **Auth & Access Control** | Auth bypass, privilege escalation, IDOR, missing authorization checks |\n| **Concurrency & State** | Race conditions, TOCTOU, deadlocks, shared mutable state, atomicity violations |\n| **Memory & Resources** | Buffer overflows, use-after-free, resource leaks, unbounded allocations |\n| **Error Handling & Recovery** | Swallowed errors, info leakage in errors, incomplete cleanup, missing rollback |\n| **Cryptography & Secrets** | Weak algorithms, hardcoded secrets, improper random, timing attacks |\n| **Business Logic** | State machine violations, numeric overflow in prices, missing validation of business rules |\n\nPresent selected aspects to user: \"I'll focus review on these {N} aspects: ...\"\n\n### Step 3b: Launch focused agents\n\nFor each aspect, launch ONE Agent with a FOCUSED prompt:\n\n```\nYou are reviewing a plan document with a SINGLE focus: {ASPECT_NAME}.\nIgnore everything outside your focus area — other reviewers handle those.\n\n## Your focus: {ASPECT_NAME}\n{ASPECT_DESCRIPTION — 2-3 sentences explaining what to look for}\n\n## Plan to review\n{reference the plan document path — the latest version with all prior fixes}\n\nRead the ENTIRE plan but analyze ONLY through the lens of {ASPECT_NAME}.\nGo deep: trace every {aspect-relevant thing} end-to-end. Check that every\nscenario is complete, every interface is specified, every edge case is handled.\n\n## Output format\nFINDING: {one-line description}\nSECTION: {which section}\nSEVERITY: HIGH | MEDIUM | LOW\nASPECT: {ASPECT_NAME}\nEVIDENCE: {quote, max 2 lines}\nFIX: {concrete change}\n\nIf clean — output: \"NO_FINDINGS — {ASPECT_NAME} review clean.\"\n```\n\n**Launch ALL aspect agents in a SINGLE message** (parallel).\n\n### After Round 3\n\nSame dedup + synthesis. Present focused report.\n\nUse the same acceptance-bound review stop criteria. Optional Round 4 is a separate\ndepth decision; already authorized fixes and delivery do not wait for it.\n\n---\n\n## Step 4: ROUND 4 — Focused + Multisampling (optional, expensive)\n\n**Purpose**: maximum depth. Only for critical plans where Round 3 still found high-severity issues.\n\n**Gate**: ask user explicitly: \"Round 3 still found {N} high-severity issues.\nRound 4 will launch {aspects x 2-3} agents (~{estimate} tokens). Continue?\"\n\nFor each aspect from Round 3 that had findings, launch **2-3 agents** with\nthe same focused prompt. Same parallel launch pattern.\n\n### After Round 4\n\nFinal synthesis. At this depth, the plan should be clean.\nIf still finding high-severity issues → the plan likely needs structural\nrework, not just polish. Tell the user.\n\n---\n\n## Output Format (used after each round)\n\n```\n====================================================\n  ROUND {N}: {BROAD | MULTISAMPLE | FOCUSED | FOCUSED+MULTISAMPLE}\n  Agents: {count}  |  New findings: {count}  |  Dupes removed: {count}\n====================================================\n\n-- HIGH ({count}) ------------------------------------\n  1. [{aspect}] {description}\n     Section: {section reference}\n     Evidence: \"{quoted text}\"\n     Fix: {concrete change}\n     Confidence: {HIGH if found by multiple agents, MEDIUM otherwise}\n\n-- MEDIUM ({count}) ----------------------------------\n  2. [{aspect}] {description}\n     ...\n\n-- LOW ({count}) -------------------------------------\n  3. ...\n\n====================================================\n  CUMULATIVE: {total_high} high \u002F {total_medium} medium \u002F {total_low} low\n  RECOMMENDATION: CONTINUE -> Round {N+1} | STOP - plan is clean\n====================================================\n```\n\n---\n\n## Step 5: Final summary\n\nAfter the last round (wherever the process stops):\n\n```\n====================================================\n  PLAN SWARM REVIEW COMPLETE\n====================================================\n  Rounds executed: {N}\n  Total agents launched: {count}\n  Total findings: {count} ({fixed} fixed, {deferred} deferred)\n\n  By severity:\n    HIGH:   {count found} -> {count fixed}\n    MEDIUM: {count found} -> {count fixed}\n    LOW:    {count found} -> {count fixed}\n\n  Round breakdown:\n    R1 (broad):       {findings_count} findings\n    R2 (multisample): {findings_count} findings\n    R3 (focused):     {findings_count} findings\n    R4 (focus+multi): {findings_count} findings\n\n  VERDICT: {HARDENED | IMPROVED | NEEDS_REWORK}\n====================================================\n```\n\nVerdicts:\n- **HARDENED** — no unresolved acceptance-critical finding in the reviewed scope;\n  this is not a blanket safety or runtime certification\n- **IMPROVED** — significant issues found and fixed, some medium deferred\n- **NEEDS_REWORK** — structural issues remain, plan needs major revision\n\n---\n\n## Gotchas\n\n- **Token cost**: Round 4 with 7 aspects x 3 samples = 21 agent launches.\n  Always confirm with user before expensive rounds.\n- **Plan mutations between rounds**: after applying fixes, the plan changes.\n  Each new round MUST read the UPDATED plan, not the original.\n  Reference the file path, not inline text, so agents always read current version.\n- **Subagent depth**: use the actual host's supported delegation limits. For this\n  workflow, reviewers inspect their assigned scope directly rather than silently\n  expanding the coordinator's agreed review budget.\n- **Diminishing returns**: Round 4 typically finds 1-3 medium issues.\n  If Round 3 found 0 high, skip Round 4.\n- **False positives**: multisampling creates duplicates. The dedup step (after\n  each round) is critical — don't count the same issue from 3 agents as 3 issues.\n- **Routing**: ordinary code\u002Fdiff review uses \u002Fdeep-review. This skill's code mode\n  is for an explicitly requested swarm security\u002Fbug review, not automatic expansion.\n\n## Troubleshooting\n\n- A review finds a fix but the user already asked for implementation: keep ownership,\n  apply the scoped reversible correction and its causal check, then continue the\n  original task. Do not turn an optional next round into a permission blocker.\n- Review keeps generating unrelated improvements: bind each proposed round and\n  finding to current acceptance or an evidenced material risk; omit optional polish.\n\n## When to use this vs other review skills\n\n| Scenario | Use |\n|---|---|\n| Quick architecture check | \u002Fplan-eng-review |\n| CEO-level scope challenge | \u002Fplan-ceo-review |\n| Design\u002FUX review | \u002Fplan-design-review |\n| Code diff review (pre-merge) | \u002Freview or \u002Fdeep-review |\n| **Thorough plan hardening before implementation** | **\u002Fplan-swarm-review** (plan mode) |\n| **Plan with many interacting components** | **\u002Fplan-swarm-review** (plan mode) |\n| **High-stakes plan (infra, security, payments)** | **\u002Fplan-swarm-review** (plan mode) |\n| **Explicit swarm security audit of a module\u002Fcodebase** | **\u002Fplan-swarm-review** (code mode) |\n| **Explicit swarm pre-release vulnerability hunt** | **\u002Fplan-swarm-review** (code mode) |\n| **Ordinary bug hunt or code review** | **\u002Fdeep-review** |\n","# Plan Swarm Review\n\nIterative plan hardening through multisampling and focused decomposition.\n\n## Scope and task ownership\n\nThe user's current task and selected model govern this review. Audit-only is\nread-only unless changes are requested. In an already authorized implementation\nor repair task, apply confirmed in-scope reversible fixes and run their focused\ncausal checks; do not ask again merely because a review round found the problem.\nAn optional deeper review does not block those fixes or the original milestone.\nStop expanding review when the current acceptance criteria are sufficiently\nproved, then return to the owning task. Preserve actual external, deletion, and\nirreversible boundaries. The four rounds are a bounded menu, not a required loop.\n\n**Core insight**: a single agent misses issues due to attention budget limits.\nMultiple independent agents reading the same document find different problems\n(stochastic diversity). Focused decomposition further improves depth per aspect.\nIterative fix-then-re-review uncovers issues previously masked by other bugs.\n\nSource: deksden (@deksden_notes) — \"Plan Swarming\" technique, April 2026.\nRelated: Anthropic Harness Design (Generator-Evaluator), deep-review (parallel competency code review).\n\nResearch backing:\n- [2502.11027] Sampling diversity in LLM inference — diverse prompts beat identical: +10.8% reasoning, +9.5% code\n- [2602.09341] AgentAuditor — reasoning tree audit beats majority voting, recovers 65-82% of minority-correct findings\n- [2602.17875] MultiVer — 4 parallel agents hit 82.7% recall on vulnerability detection (beats fine-tuned models)\n- [2510.00317] MAVUL — multi-agent vuln detection: +600% vs single-agent\n- Anthropic Code Review (Mar 2026) — parallel agents raise substantive findings from 16% to 54%\n\n## Modes\n\nThis skill works in two modes:\n\n**Plan mode** (default): review design docs, specs, ADRs, RFCs before implementation.\n**Code mode**: review code files for bugs and vulnerabilities when the user\nexplicitly requests a swarm code review. Merely supplying a diff or asking for\nordinary code review routes to `deep-review`. In code mode, aspects shift from plan-oriented (contracts,\ncompleteness) to code-oriented (injection, auth bypass, race conditions, memory).\n\n---\n\n## Step 0: Identify the target document\n\nAsk the user which document to review if not obvious from context.\n\n**Plan mode**: PLAN.md, ADR, spec, design doc, RFC, or any structured\ndocument describing what will be built and how.\n\n**Code mode**: source code files, a module, or a directory. Best for\nsecurity audits, bug hunts, or pre-release quality checks.\n\n```\nRead the target document(s) fully. Note:\n- Total size (lines, sections\u002Ffiles)\n- Key components\u002Fmodules described or implemented\n- Interfaces between components\n- Data flows and mutations\n- External dependencies and trust boundaries\n```\n\nIf the target is \u003C100 lines with 1-2 simple components, suggest a single-pass\nreview instead — swarming is overkill for small targets.\n\n---\n\n## Step 1: ROUND 1 — Broad Review (single agent)\n\n**Purpose**: catch obvious issues before spending tokens on multisampling.\n\nLaunch ONE Agent with this prompt:\n\n```\nYou are a senior architect reviewing a plan document before implementation.\nYour goal: find issues that would cause bugs, rework, or confusion during\nimplementation.\n\n## Plan to review\n{paste or reference the plan document path}\n\nRead the entire plan. Then check for:\n\n1. CONTRACTS — are interfaces between components fully specified?\n   Types, error codes, required vs optional fields, versioning.\n2. DATA FLOW — is data transformation described end-to-end?\n   What happens at each boundary? Backward compatibility?\n3. NEGATIVE SCENARIOS — what happens when things fail?\n   Timeouts, partial failures, invalid input, race conditions.\n4. CONSISTENCY — do different sections contradict each other?\n   Same entity described differently in two places?\n5. COMPLETENESS — are there gaps? Steps that say \"TBD\" or \"later\"?\n   Scenarios mentioned but not covered?\n6. DEPENDENCIES — is implementation order clear?\n   Are blocking dependencies identified? Circular deps?\n7. AMBIGUITY — could two engineers read a section and implement\n   it differently? Vague terms like \"handle appropriately\"?\n\n## Output format\nFor EACH finding:\n\nFINDING: {one-line description}\nSECTION: {which section of the plan}\nSEVERITY: HIGH | MEDIUM | LOW\nEVIDENCE: {quote the problematic text, max 2 lines}\nFIX: {concrete change to the plan text}\n\nIf the plan is clean — output: \"NO_FINDINGS — plan review clean.\"\nDo NOT pad with praise. Only problems.\n```\n\n### After Round 1\n\nCollect findings. If **0 findings** → finish this review scope and return to the\nowning task; this is not proof that an implementation milestone is finished.\n\nIf findings exist:\n1. Present findings to user grouped by severity\n2. If fixes are already authorized, apply the confirmed scoped corrections and\n   run their focused checks. Otherwise report them within the audit-only request.\n3. Consider Round 2 only for a remaining concrete risk or an explicit depth request;\n   do not bundle permission for optional review with already authorized fixes.\n4. If user says stop → stop\n\n---\n\n## Step 2: ROUND 2 — Diverse Multisampling (N parallel agents, varied perspectives)\n\n**Purpose**: stochastic diversity catches what one pass missed.\n\n**IMPORTANT**: do NOT use identical prompts for all agents. Research [2502.11027]\nshows identical prompts produce correlated errors — agents \"cluster\" on the same\nissues and miss the same blind spots. Instead, give each agent a DIFFERENT\nperspective while reviewing the same document.\n\nLaunch **3 agents in parallel** (or 5 for critical plans), each with a\n**different reviewer persona**:\n\n**CRITICAL**: launch all agents in a SINGLE message (parallel tool calls).\nEach agent has isolated context — no cross-contamination.\n\n### Plan mode perspectives\n\n| Agent | Persona | Focus bias |\n|---|---|---|\n| 1 | **Skeptical implementer** | \"I have to code this tomorrow — what's unclear, contradictory, or impossible?\" |\n| 2 | **Security auditor** | \"Where are the trust boundaries? What happens with malicious input?\" |\n| 3 | **QA engineer** | \"How do I test this? What edge cases aren't covered? What breaks at scale?\" |\n| 4 | **New team member** | \"I just joined — what terms are undefined? What implicit knowledge is required?\" |\n| 5 | **Ops\u002FSRE** | \"What fails at 3am? What's the rollback plan? What's unmonitored?\" |\n\n### Code mode perspectives\n\n| Agent | Persona | Focus bias |\n|---|---|---|\n| 1 | **Attacker** | \"How do I exploit this? Injection, auth bypass, privilege escalation?\" |\n| 2 | **Concurrency specialist** | \"What races, deadlocks, or ordering issues exist?\" |\n| 3 | **Performance engineer** | \"What's O(n^2)? What allocates unbounded memory? What blocks the event loop?\" |\n| 4 | **Error recovery auditor** | \"What happens when X fails? Is cleanup correct? Are resources leaked?\" |\n| 5 | **Integration tester** | \"Do contracts match? Are types compatible? What breaks at boundaries?\" |\n\n```\nYou are a {PERSONA} reviewing {plan\u002Fcode} before implementation\u002Fdeployment.\nYour perspective: {FOCUS_BIAS}\n\nReview the ENTIRE document through your specific lens.\n{same checklist and output format as Round 1}\n```\n\n### After Round 2\n\n1. **Deduplicate**: group findings by section + issue type. When multiple\n   agents find the same issue → mark as HIGH CONFIDENCE (consensus).\n2. **Preserve minority findings**: a finding from only 1 of 5 agents is\n   NOT automatically low-value. Research [2602.09341] shows minority-correct\n   findings are often the most valuable — non-obvious bugs that only one\n   perspective catches. Flag these as UNIQUE CATCH, do not discard.\n3. **Synthesize**: produce merged report. Separate consensus vs unique catches.\n4. Present to user with round report format (see Output Format below).\n5. Apply already authorized scoped fixes; use Round 3 only for a concrete unresolved\n   risk or an explicit depth request, not as a condition for continuing implementation.\n\n**Review stop criteria**: no unresolved finding affecting current acceptance or\nsafety. A severity count is not proof: two material medium findings still need\nresolution. End this review branch without abandoning the owning task.\n\n---\n\n## Step 3: ROUND 3 — Focused Review (decompose into aspects)\n\n**Purpose**: narrow scope = deeper analysis per aspect.\n\n### Step 3a: Determine focus aspects\n\nBased on the target content, select 3-7 aspects.\n\n### Plan mode aspects\n\n| Aspect | When to include |\n|---|---|\n| **Contracts & Interfaces** | Plan describes >2 interacting components |\n| **Data Flow & Migrations** | Plan involves data transformation, DB changes, or state migration |\n| **Negative Scenarios** | Plan describes user-facing features or distributed systems |\n| **Consistency** | Plan is >300 lines or written by multiple authors |\n| **Completeness** | Plan references external systems or has phased rollout |\n| **Security & Trust** | Plan involves auth, user input, or external APIs |\n| **Dependencies & Order** | Plan has >5 implementation steps or parallel workstreams |\n\n### Code mode aspects (for bug\u002Fvulnerability hunting)\n\n**Before launching agents:** read `references\u002Fvulnerability-kb.md` for condensed detection\nheuristics per CWE class. Feed the relevant CWE heuristics into each agent's prompt.\nFull Vul-RAG entries with code examples: `knowledge-vault\u002Fdocs\u002Fsecurity\u002Fcwe\u002F`.\n\nBased on MultiVer [2602.17875] and VulAgent [2509.11523] patterns:\n\n| Aspect | What to trace |\n|---|---|\n| **Injection & Input Validation** | SQL\u002FNoSQL\u002Fcommand\u002FLDAP injection, XSS, path traversal, template injection |\n| **Auth & Access Control** | Auth bypass, privilege escalation, IDOR, missing authorization checks |\n| **Concurrency & State** | Race conditions, TOCTOU, deadlocks, shared mutable state, atomicity violations |\n| **Memory & Resources** | Buffer overflows, use-after-free, resource leaks, unbounded allocations |\n| **Error Handling & Recovery** | Swallowed errors, info leakage in errors, incomplete cleanup, missing rollback |\n| **Cryptography & Secrets** | Weak algorithms, hardcoded secrets, improper random, timing attacks |\n| **Business Logic** | State machine violations, numeric overflow in prices, missing validation of business rules |\n\nPresent selected aspects to user: \"I'll focus review on these {N} aspects: ...\"\n\n### Step 3b: Launch focused agents\n\nFor each aspect, launch ONE Agent with a FOCUSED prompt:\n\n```\nYou are reviewing a plan document with a SINGLE focus: {ASPECT_NAME}.\nIgnore everything outside your focus area — other reviewers handle those.\n\n## Your focus: {ASPECT_NAME}\n{ASPECT_DESCRIPTION — 2-3 sentences explaining what to look for}\n\n## Plan to review\n{reference the plan document path — the latest version with all prior fixes}\n\nRead the ENTIRE plan but analyze ONLY through the lens of {ASPECT_NAME}.\nGo deep: trace every {aspect-relevant thing} end-to-end. Check that every\nscenario is complete, every interface is specified, every edge case is handled.\n\n## Output format\nFINDING: {one-line description}\nSECTION: {which section}\nSEVERITY: HIGH | MEDIUM | LOW\nASPECT: {ASPECT_NAME}\nEVIDENCE: {quote, max 2 lines}\nFIX: {concrete change}\n\nIf clean — output: \"NO_FINDINGS — {ASPECT_NAME} review clean.\"\n```\n\n**Launch ALL aspect agents in a SINGLE message** (parallel).\n\n### After Round 3\n\nSame dedup + synthesis. Present focused report.\n\nUse the same acceptance-bound review stop criteria. Optional Round 4 is a separate\ndepth decision; already authorized fixes and delivery do not wait for it.\n\n---\n\n## Step 4: ROUND 4 — Focused + Multisampling (optional, expensive)\n\n**Purpose**: maximum depth. Only for critical plans where Round 3 still found high-severity issues.\n\n**Gate**: ask user explicitly: \"Round 3 still found {N} high-severity issues.\nRound 4 will launch {aspects x 2-3} agents (~{estimate} tokens). Continue?\"\n\nFor each aspect from Round 3 that had findings, launch **2-3 agents** with\nthe same focused prompt. Same parallel launch pattern.\n\n### After Round 4\n\nFinal synthesis. At this depth, the plan should be clean.\nIf still finding high-severity issues → the plan likely needs structural\nrework, not just polish. Tell the user.\n\n---\n\n## Output Format (used after each round)\n\n```\n====================================================\n  ROUND {N}: {BROAD | MULTISAMPLE | FOCUSED | FOCUSED+MULTISAMPLE}\n  Agents: {count}  |  New findings: {count}  |  Dupes removed: {count}\n====================================================\n\n-- HIGH ({count}) ------------------------------------\n  1. [{aspect}] {description}\n     Section: {section reference}\n     Evidence: \"{quoted text}\"\n     Fix: {concrete change}\n     Confidence: {HIGH if found by multiple agents, MEDIUM otherwise}\n\n-- MEDIUM ({count}) ----------------------------------\n  2. [{aspect}] {description}\n     ...\n\n-- LOW ({count}) -------------------------------------\n  3. ...\n\n====================================================\n  CUMULATIVE: {total_high} high \u002F {total_medium} medium \u002F {total_low} low\n  RECOMMENDATION: CONTINUE -> Round {N+1} | STOP - plan is clean\n====================================================\n```\n\n---\n\n## Step 5: Final summary\n\nAfter the last round (wherever the process stops):\n\n```\n====================================================\n  PLAN SWARM REVIEW COMPLETE\n====================================================\n  Rounds executed: {N}\n  Total agents launched: {count}\n  Total findings: {count} ({fixed} fixed, {deferred} deferred)\n\n  By severity:\n    HIGH:   {count found} -> {count fixed}\n    MEDIUM: {count found} -> {count fixed}\n    LOW:    {count found} -> {count fixed}\n\n  Round breakdown:\n    R1 (broad):       {findings_count} findings\n    R2 (multisample): {findings_count} findings\n    R3 (focused):     {findings_count} findings\n    R4 (focus+multi): {findings_count} findings\n\n  VERDICT: {HARDENED | IMPROVED | NEEDS_REWORK}\n====================================================\n```\n\nVerdicts:\n- **HARDENED** — no unresolved acceptance-critical finding in the reviewed scope;\n  this is not a blanket safety or runtime certification\n- **IMPROVED** — significant issues found and fixed, some medium deferred\n- **NEEDS_REWORK** — structural issues remain, plan needs major revision\n\n---\n\n## Gotchas\n\n- **Token cost**: Round 4 with 7 aspects x 3 samples = 21 agent launches.\n  Always confirm with user before expensive rounds.\n- **Plan mutations between rounds**: after applying fixes, the plan changes.\n  Each new round MUST read the UPDATED plan, not the original.\n  Reference the file path, not inline text, so agents always read current version.\n- **Subagent depth**: use the actual host's supported delegation limits. For this\n  workflow, reviewers inspect their assigned scope directly rather than silently\n  expanding the coordinator's agreed review budget.\n- **Diminishing returns**: Round 4 typically finds 1-3 medium issues.\n  If Round 3 found 0 high, skip Round 4.\n- **False positives**: multisampling creates duplicates. The dedup step (after\n  each round) is critical — don't count the same issue from 3 agents as 3 issues.\n- **Routing**: ordinary code\u002Fdiff review uses \u002Fdeep-review. This skill's code mode\n  is for an explicitly requested swarm security\u002Fbug review, not automatic expansion.\n\n## Troubleshooting\n\n- A review finds a fix but the user already asked for implementation: keep ownership,\n  apply the scoped reversible correction and its causal check, then continue the\n  original task. Do not turn an optional next round into a permission blocker.\n- Review keeps generating unrelated improvements: bind each proposed round and\n  finding to current acceptance or an evidenced material risk; omit optional polish.\n\n## When to use this vs other review skills\n\n| Scenario | Use |\n|---|---|\n| Quick architecture check | \u002Fplan-eng-review |\n| CEO-level scope challenge | \u002Fplan-ceo-review |\n| Design\u002FUX review | \u002Fplan-design-review |\n| Code diff review (pre-merge) | \u002Freview or \u002Fdeep-review |\n| **Thorough plan hardening before implementation** | **\u002Fplan-swarm-review** (plan mode) |\n| **Plan with many interacting components** | **\u002Fplan-swarm-review** (plan mode) |\n| **High-stakes plan (infra, security, payments)** | **\u002Fplan-swarm-review** (plan mode) |\n| **Explicit swarm security audit of a module\u002Fcodebase** | **\u002Fplan-swarm-review** (code mode) |\n| **Explicit swarm pre-release vulnerability hunt** | **\u002Fplan-swarm-review** (code mode) |\n| **Ordinary bug hunt or code review** | **\u002Fdeep-review** |\n",{"name":5,"metadata":50,"description":53,"allowed-tools":54},{"user-invocable":51,"upstream-model-hint":52},true,"opus","Iterative plan review using multisampling + focused decomposition.\nLaunches parallel independent agents to find issues that single-pass\nreview misses. Up to four bounded rounds: broad, multisample, focused,\nfocused-plus-multisample. Use when: \"swarm review\", \"review plan thoroughly\",\n\"multisample review\", \"deep plan review\", \"plan swarming\", \"stress test\nthe plan\", or when evidenced cross-component risk warrants deeper plan review.\nSize alone does not require a swarm or another review round. Do NOT use to\ndesign a multi-agent harness or Generator-Evaluator architecture from scratch;\nuse harness-design for that. Ordinary code\u002Fdiff review routes to deep-review;\nuse this skill's code mode only when the user explicitly requests a swarm\nsecurity\u002Fbug review of code.\n",[55,56,57,58,59,60,61,62],"Read","Grep","Glob","Agent","AskUserQuestion","TodoWrite","Edit","Write","main","ac20f93f36e574610dbc51743bb21e7765142e95","skills\u002Farchitecture\u002Fplan-swarm-review",32,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config","https:\u002F\u002Fgithub.com\u002FAnastasiyaW","https:\u002F\u002Fhappyin.work","ComfyUI specialist · turnkey image-processing pipelines · diffusion models, computer vision · Belgrade","2026-11-14 01:35:49",{"source":8,"skillName":5,"commands":73,"prompt":83,"zipAvailable":51},[74,77,80],{"tool":75,"command":76},"npx","npx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill plan-swarm-review",{"tool":78,"command":79},"bunx","bunx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill plan-swarm-review",{"tool":81,"command":82},"pnpm","pnpm dlx skills add AnastasiyaW\u002Fcodex-claude-code-config --skill plan-swarm-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Farchitecture\u002Fplan-swarm-review\u002FSKILL.md",[85],{"path":86,"resourceType":87,"resourceTypeDesc":88,"sizeBytes":89,"sourceHtmlUrl":90},"references\u002Fvulnerability-kb.md","REFERENCE","参考文档",7413,"https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Farchitecture\u002Fplan-swarm-review\u002Freferences\u002Fvulnerability-kb.md",[92,101,116,141,167,185],{"skillNo":93,"name":94,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":98,"publishedAt":45},"01M6JZ2SNGKFN8NK3HZBMVGQP1","owner-voice","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fowner-voice\u002FSKILL.md",[97],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[99,100],"owner voice","voice",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":108,"publishedAt":45},"01M6JZ2N0C2WFCAK6T8N3RMBVS","humanize-russian","Редактировать русский текст для ясности и естественного звучания, сохраняя факты,\nтермины, источники и жанр. Использовать когда: убрать канцелярит, сделать текст\nживее, отредактировать русский черновик или статью перед публикацией.\nНе определяет авторство и не обещает обход детекторов. Для английского —\nhumanize-english; для структуры и доказательств — article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-russian\u002FSKILL.md",[107],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[109,110,111,112,24,113,114,115],"russian","humanize","humanize russian","english","structure","article","2026",{"skillNo":117,"name":118,"nameZh":6,"description":119,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":120,"categories":121,"keywords":122,"publishedAt":45},"01M6JZ2GN264R6GKBQ5QVZE0ZS","humanize-english","Edit English drafts for clear, natural language while preserving facts, uncertainty,\ntechnical meaning, citations and genre. Use when: humanize this text, remove AI-style\nfiller, improve English prose, or edit an English article before publication.\nNot an authorship detector or a promise to bypass one. For Russian use\nhumanize-russian; for thesis\u002Fevidence and structure use article-structure-review.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fhumanize-english\u002FSKILL.md",[],[110,112,123,124,109,125,126,127,38,113,128,129,130,24,131,115,28,132,133,134,135,136,137,138,114,139,140],"humanize english","technical","evidence","use","remove","text","improve","Citations","Publication","for","facts","natural language","drafts","meaning","uncertainty","style","thesis","promise",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":45},"01M6JZ2BM31D5Y609DQJJJM6MM","caveman","Ultra-compressed reply mode. Cuts output tokens ~65-75% by answering in terse \"caveman\" style while keeping full technical accuracy, and shapes what survives: action first, state restated every turn, concrete time estimates, visible wins. Intensity levels: lite, full (default), ultra, wenyan-lite, wenyan-full, wenyan-ultra. Use when user says \"caveman\", \"talk like caveman\", \"use caveman\", \"less tokens\", \"be brief\", or Russian \"пещерный режим\", \"говори как пещерный\", \"кратко\", \"меньше токенов\", \"экономь токены\" — or invokes \u002Fcaveman. Preserves the user's language (Russian in → Russian caveman out). Off only: \"stop caveman\" \u002F \"normal mode\" \u002F \"обычный режим\". Do not use merely because a response should be concise, and do not use when the user requests normal prose, a polished document, or exact wording.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Fcaveman\u002FSKILL.md",[],[143,138,28,148,149,150,151,30,152,153,154,155,156,157,158,159,160,109,161,162,163,36,126,124,164,165,166],"normal","terse","accuracy","ultra","document","requests","concise","output","intensity","tokens","full","time","do","action","default","stop","first","brief","state",{"skillNo":168,"name":169,"nameZh":6,"description":170,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":171,"categories":172,"keywords":182,"publishedAt":45},"01M6JZ25Y5GJXFKXNR6TRQX237","article-structure-review","Проверить структуру технической статьи после черновика: задача читателя, жанр,\nопора значимых утверждений на доказательства и честные ограничения.\nUse after the first draft, before publication. Исправлять структуру, когда это\nвходит в запрос; не создавать обязательный конвейер из других навыков.\nДля локальной языковой редактуры — humanize-english или humanize-russian.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fwriting\u002Farticle-structure-review\u002FSKILL.md",[173,176,177],{"categoryNo":174,"categoryName":175,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":178,"categoryName":179,"taxonomyType":180,"taxonomyTypeDesc":181},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[183,114,113,24,184,110,109,126,164,112,131,115],"article structure review","draft",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":194,"publishedAt":45},"01M6JZ1XN7WQQCWCHHMTTD8K28","video-post-production","Video post-production rules: audio mastering, color, captions, platform export. Use when: 'add music', 'add voiceover', 'export for tiktok', 'add captions', 'color grade', 'audio levels', 'master audio', 'export settings', 'platform requirements'. Covers FFmpeg patterns, audio chain, subtitle standards, and platform-specific export configs. Do NOT use to generate or animate the video frames\u002Fscenes in code (use remotion-production-guide), to write the script (use video-narrative-arc), or to evaluate script quality (use script-evaluator); this is the finishing stage applied to an already-rendered video.","https:\u002F\u002Fgithub.com\u002FAnastasiyaW\u002Fcodex-claude-code-config\u002Fblob\u002Fmain\u002Fskills\u002Fvideo-production\u002Fvideo-post-production\u002FSKILL.md",[191],{"categoryNo":192,"categoryName":193,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[195,196,197,198,199,28,200,201,202,203,204,205,206,207,39,208,209,210,211,42,212],"video post production","post","Production","Video","patterns","post-production","narrative","add","chain","tiktok","voiceover","master","export","music","Captions","Audio","Remotion","generate"]