[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DF6FK4MNQRWC9YV6DAKXYT":3,"skill-same:01M6DF6FK4MNQRWC9YV6DAKXYT":68},{"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":18,"publishedAt":32,"linkOnly":33,"markdownContent":34,"markdownBody":35,"frontMatter":36,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":14,"repositoryHtmlUrl":46,"repositoryHomepageUrl":6,"ownerHtmlUrl":47,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":48,"install":49,"resources":61},"01M6DF6FK4MNQRWC9YV6DAKXYT","plan-review-gate",null,"Automatic adversarial review gate that spawns 3 independent reviewers in parallel after any plan is drafted - all must PASS before presenting to user","Prekzursil\u002Fagent-skills-toolchain","Prekzursil","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F54636077?v=4","01M6DACZ1PCQHD99SCR1YXG28B","Andrei Mihai Visalon","01M6DACZ670WZF535V3WYYSS4Z",0,"MIT","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fplan-review-gate\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31],"review","plan","plan review","gate","plan review gate","writing","adversarial review","validation","execution","parallel","user","implementation","plans","2026-11-10 10:12:30",false,"---\nname: plan-review-gate\ndescription: Automatic adversarial review gate that spawns 3 independent reviewers in parallel after any plan is drafted - all must PASS before presenting to user\nauto_activate: true\ntriggers:\n  - \"plan drafted\"\n  - \"implementation plan created\"\n  - after:writing-plans\n  - after:orchestrated-execution:plan-validation\n---\n\n# Plan Review Gate\n\n**Core principle**: No plan reaches the user without surviving independent adversarial scrutiny.\n\n## Purpose\n\nThis skill automatically activates after any implementation plan is drafted, before presenting it to the user. It spawns three independent adversarial reviewers in parallel — Feasibility, Completeness, and Scope & Alignment — each as a fresh `Task()` instance. ALL three must PASS. On failure, the planner incorporates feedback and resubmits to entirely fresh reviewer instances. The gate iterates until consensus or max iterations.\n\n---\n\n## Activation Triggers\n\nThis skill auto-activates when:\n\n1. An implementation plan is drafted (by planner, explorer, or orchestrator)\n2. The `writing-plans` skill completes a plan\n3. The orchestrator's plan validation phase produces a plan for review\n4. User explicitly requests: `\u002Fplan-review \u003Cpath-to-plan>`\n\n**Do NOT use for**: Trivial changes (single-file bug fixes, copy edits, config tweaks). The plan must have at least 2 work units or touch 3+ files to warrant gate review.\n\n---\n\n## The 3 Adversarial Reviewers\n\nEach reviewer is a fresh `Task()` instance with read-only access to the codebase. Reviewers produce binary PASS\u002FFAIL verdicts backed by cited evidence. No suggestions — only findings.\n\n### Reviewer 1: Feasibility\n\nCan this plan actually be executed against the real codebase?\n\n| Check | Classification | Criteria |\n| --- | --- | --- |\n| File paths exist | BLOCKING if fabricated | Every file path referenced in the plan must exist (verify with glob\u002Fgrep) |\n| Dependency ordering correct | BLOCKING if circular or forward-ref | Work units depend only on things that exist or are created before them |\n| Technical approach matches codebase | BLOCKING if incompatible | Proposed patterns, libraries, and conventions match what the codebase actually uses |\n| No unstated assumptions | BLOCKING if critical | Plan does not silently depend on services, env vars, or infrastructure that doesn't exist |\n| File scope realistic | WARNING | Each work unit's file scope is achievable without cascading changes |\n\n### Reviewer 2: Completeness\n\nDoes the plan fully address every aspect of the user's request?\n\n| Check | Classification | Criteria |\n| --- | --- | --- |\n| All requirements mapped | BLOCKING if gap exists | Every user requirement maps to at least one plan item |\n| Verification steps defined | BLOCKING if missing | Each change has a way to verify it worked (test, manual check, or assertion) |\n| Edge cases considered | BLOCKING if obvious gaps | Error scenarios, empty states, boundary conditions addressed |\n| Rollback\u002Fbackward compatibility | WARNING | Plan considers what happens if changes need to be reverted |\n| Cross-file integration points | BLOCKING if missing | Files that import\u002Fdepend on changed files are accounted for |\n\n### Reviewer 3: Scope & Alignment\n\nIs the plan right-sized for what the user actually asked?\n\n| Check | Classification | Criteria |\n| --- | --- | --- |\n| Matches user request | BLOCKING if divergent | Plan solves what was asked, not what the planner finds interesting |\n| No scope creep | BLOCKING if present | No unnecessary features, abstractions, or refactoring beyond the request |\n| No under-scoping | BLOCKING if present | Obvious implications of the request are not omitted |\n| Complexity proportional | WARNING | Solution complexity matches problem complexity |\n| No simpler alternative missed | WARNING | Plan is not over-engineered when a simpler approach would suffice |\n\n---\n\n## Reviewer Isolation Rules\n\nThese rules are **mandatory**. Violating any of them invalidates the review.\n\n1. **Fresh instances only.** Each reviewer is a new `Task()` instance — never resumed, never given prior context.\n2. **No cross-reviewer visibility.** No reviewer sees another reviewer's output. Ever.\n3. **Read-only codebase access.** Reviewers can read files, run grep\u002Fglob, but cannot modify anything.\n4. **No prior review findings on re-review.** When re-reviewing after iteration, completely fresh instances are spawned. The new reviewers have zero knowledge of what previous reviewers found.\n5. **Input is limited to:** the plan text, the user's original request, and the codebase (via read-only tools).\n\n**Why isolation matters:** Reviewers who see prior findings anchor on those findings instead of reviewing independently. Fresh instances prevent this bias and ensure each review cycle is a genuine independent check.\n\n---\n\n## Workflow\n\n```text\n1. Plan drafted by planner\u002Fexplorer\u002Forchestrator\n2. Spawn 3 adversarial reviewers in PARALLEL (fresh Task() instances)\n3. Collect all 3 verdicts\n4. IF all PASS --> present plan to user with gate approval summary\n5. IF any FAIL -->\n   a. Planner reads ALL feedback from all reviewers\n   b. Planner incorporates changes OR documents why feedback doesn't apply\n   c. Spawn 3 NEW reviewer instances (never reuse -- prevents anchoring)\n   d. Repeat from step 3\n6. Max 3 iterations --> present plan with remaining issues noted for user decision\n```\n\n### Phase 1: Spawn Reviewers (Parallel)\n\n```typescript\n\u002F\u002F Spawn all three reviewers in parallel for efficiency\nconst [feasibilityResult, completenessResult, scopeResult] = await Promise.all([\n  Task({\n    subagent_type: \"general-purpose\",\n    description: \"Feasibility review\",\n    prompt: feasibilityReviewPrompt(planText, userRequest),\n  }),\n  Task({\n    subagent_type: \"general-purpose\",\n    description: \"Completeness review\",\n    prompt: completenessReviewPrompt(planText, userRequest),\n  }),\n  Task({\n    subagent_type: \"general-purpose\",\n    description: \"Scope & Alignment review\",\n    prompt: scopeAlignmentReviewPrompt(planText, userRequest),\n  }),\n]);\n```\n\n### Phase 2: Evaluate Gate\n\n```text\nIF feasibilityResult.verdict === \"PASS\"\n   AND completenessResult.verdict === \"PASS\"\n   AND scopeResult.verdict === \"PASS\":\n  --> GATE APPROVED. Present plan to user.\n\nELSE:\n  --> Consolidate all FAIL findings.\n  --> Pass to planner for revision.\n  --> Increment iteration counter.\n  --> IF iterations >= 3: present plan with remaining issues to user.\n  --> ELSE: spawn fresh reviewers on revised plan.\n```\n\n### Phase 3: Iteration (on FAIL)\n\n1. Planner receives consolidated feedback from ALL reviewers (both PASS and FAIL)\n2. Planner revises the plan, addressing each FAIL finding explicitly\n3. For each finding, planner either:\n   - **Fixes it** — modifies the plan to resolve the issue\n   - **Rebuts it** — documents why the finding is incorrect or not applicable (with evidence)\n4. Spawn 3 entirely new `Task()` instances for re-review\n5. New reviewers see ONLY the revised plan and original request — NOT previous findings\n\n### Phase 4: Escalation (after 3 iterations)\n\nIf the gate has not achieved consensus after 3 iterations:\n\n```markdown\n## Plan Review Gate: ESCALATION REQUIRED (3\u002F3 iterations exhausted)\n\n### Remaining Blocking Issues\n\n#### Feasibility\n- [issue with evidence]\n\n#### Completeness\n- [issue with evidence]\n\n#### Scope & Alignment\n- [issue with evidence]\n\n### Iteration History\n| Iteration | Feasibility | Completeness | Scope & Alignment |\n|-----------|-------------|--------------|-------------------|\n| 1         | FAIL        | PASS         | FAIL              |\n| 2         | PASS        | PASS         | FAIL              |\n| 3         | PASS        | PASS         | FAIL              |\n\n### Options\n1. **Override** — Proceed with plan as-is (remaining issues become known risks)\n2. **Revise** — Continue iterating on the plan manually\n3. **Simplify** — Reduce scope to eliminate contentious items\n4. **Cancel** — Abandon this plan and start fresh\n\nPlease choose an option or provide additional context.\n```\n\n---\n\n## Reviewer Prompts\n\n### Feasibility Reviewer Prompt\n\n````markdown\nYou are the FEASIBILITY REVIEWER for a plan review gate.\n\n## Mode\nAdversarial — your job is to FIND FAILURES in plan feasibility, not to approve.\n\n## Rubric\nRead and follow: .\u002Frubrics\u002Fplan-review-rubric-adversarial.md (Feasibility section)\n\n## User's Original Request\n${userRequest}\n\n## Plan Under Review\n${planText}\n\n## Your Task\nDetermine whether this plan can actually be executed against the real codebase. Check:\n\n1. **File paths exist** — Use glob\u002Fgrep to verify every file path the plan references actually exists. Fabricated paths = BLOCKING FAIL.\n2. **Dependency ordering** — Verify work units don't have circular dependencies or reference things created in later steps. Read the codebase to confirm.\n3. **Technical approach** — Does the plan use patterns, libraries, and conventions that match the actual codebase? Read existing code to verify.\n4. **Unstated assumptions** — Does the plan silently depend on services, configurations, or infrastructure that doesn't exist?\n\n## Rules\n- Check EACH criterion. Cite file:line or glob results as evidence for PASS, or specific gaps for FAIL.\n- Any single BLOCKING issue means overall FAIL.\n- You have NO context from previous reviews. Judge fresh.\n- Do NOT suggest improvements. Only report PASS or FAIL with evidence.\n- Do NOT consider other reviewers. You are independent.\n\n## Output Format\nFollow the per-reviewer output format defined in the skill.\n````\n\n### Completeness Reviewer Prompt\n\n````markdown\nYou are the COMPLETENESS REVIEWER for a plan review gate.\n\n## Mode\nAdversarial — your job is to FIND GAPS in plan coverage, not to approve.\n\n## Rubric\nRead and follow: .\u002Frubrics\u002Fplan-review-rubric-adversarial.md (Completeness section)\n\n## User's Original Request\n${userRequest}\n\n## Plan Under Review\n${planText}\n\n## Your Task\nDetermine whether this plan fully addresses every aspect of the user's request. Check:\n\n1. **Requirement mapping** — Extract each distinct requirement from the user's request. For each one, find the plan item that addresses it. Missing mapping = BLOCKING FAIL.\n2. **Verification steps** — Each planned change must have a defined way to verify it works (test, assertion, manual check). Missing verification = BLOCKING FAIL.\n3. **Edge cases** — Are error scenarios, empty states, and boundary conditions addressed? Obvious gaps = BLOCKING FAIL.\n4. **Rollback\u002Fbackward compatibility** — Does the plan consider what happens if changes need to be reverted?\n5. **Cross-file integration** — Are files that import or depend on changed files accounted for?\n\n## Rules\n- Check EACH criterion. Cite specific user requirements and plan items as evidence.\n- Any single BLOCKING issue means overall FAIL.\n- You have NO context from previous reviews. Judge fresh.\n- Do NOT suggest improvements. Only report PASS or FAIL with evidence.\n- Do NOT consider other reviewers. You are independent.\n\n## Output Format\nFollow the per-reviewer output format defined in the skill.\n````\n\n### Scope & Alignment Reviewer Prompt\n\n````markdown\nYou are the SCOPE & ALIGNMENT REVIEWER for a plan review gate.\n\n## Mode\nAdversarial — your job is to FIND MISALIGNMENT between the plan and user request, not to approve.\n\n## Rubric\nRead and follow: .\u002Frubrics\u002Fplan-review-rubric-adversarial.md (Scope & Alignment section)\n\n## User's Original Request\n${userRequest}\n\n## Plan Under Review\n${planText}\n\n## Your Task\nDetermine whether this plan is right-sized for what the user actually asked. Check:\n\n1. **Matches user request** — Does the plan solve what was asked? Or does it solve something the planner found more interesting? Divergence = BLOCKING FAIL.\n2. **No scope creep** — Are there features, abstractions, or refactoring beyond what was requested? Unnecessary additions = BLOCKING FAIL.\n3. **No under-scoping** — Are obvious implications of the request omitted? Missing obvious work = BLOCKING FAIL.\n4. **Complexity proportional** — Is the solution complexity proportional to the problem complexity?\n5. **Simpler alternative** — Is there a significantly simpler approach that achieves the same outcome?\n\n## Rules\n- Check EACH criterion. Cite the user's request and plan scope as evidence.\n- Any single BLOCKING issue means overall FAIL.\n- You have NO context from previous reviews. Judge fresh.\n- Do NOT suggest improvements. Only report PASS or FAIL with evidence.\n- Do NOT consider other reviewers. You are independent.\n\n## Output Format\nFollow the per-reviewer output format defined in the skill.\n````\n\n---\n\n## Output Formats\n\n### Per-Reviewer Output\n\nEach reviewer produces output in this exact format:\n\n```markdown\n## [Reviewer Name] — [PASS\u002FFAIL]\n\n### Evidence\n- [Finding 1]: [file:line reference or specific gap with evidence]\n- [Finding 2]: [file:line reference or specific gap with evidence]\n- ...\n\n### Verdict\n[PASS: All criteria met — no blocking issues found]\nOR\n[FAIL: {numbered list of blocking issues with evidence}]\n```\n\n### Consolidated Gate Output (All PASS)\n\n```markdown\n## Plan Review Gate — APPROVED (iteration N of 3)\n\n| Reviewer | Verdict | Key Finding |\n|----------|---------|-------------|\n| Feasibility | PASS | All file paths verified, deps ordered correctly |\n| Completeness | PASS | All N requirements mapped to plan items |\n| Scope & Alignment | PASS | Plan matches user request, no scope creep |\n\nPlan is ready for user review.\n```\n\n### Consolidated Gate Output (Any FAIL)\n\n```markdown\n## Plan Review Gate — REVISION NEEDED (iteration N of 3)\n\n| Reviewer | Verdict | Blocking Issues |\n|----------|---------|-----------------|\n| Feasibility | PASS | — |\n| Completeness | FAIL | 2 blocking issues |\n| Scope & Alignment | FAIL | 1 blocking issue |\n\n### Blocking Issues (MUST ADDRESS)\n\n#### Completeness Reviewer\n1. **Missing requirement mapping**: User asked for X but no plan item addresses it\n2. **No verification for WU-003**: Plan item has no test or assertion defined\n\n#### Scope & Alignment Reviewer\n1. **Scope creep**: WU-005 adds caching layer not requested by user\n\n---\n\n**Iteration**: N of 3\n**Action Required**: Planner must address all blocking issues and resubmit.\n```\n\n---\n\n## Anti-Patterns\n\n| # | Anti-Pattern | Why It's Wrong | What to Do Instead |\n| --- | --- | --- | --- |\n| 1 | **Reusing reviewer instances** — passing findings to next review cycle | Anchoring bias: reviewer checks for previous findings instead of reviewing fresh | Spawn new `Task()` instances with no prior context |\n| 2 | **Cross-reviewer contamination** — sharing one reviewer's output with another | Destroys independence; reviewers converge instead of checking independently | Each reviewer sees only: plan, user request, codebase |\n| 3 | **Treating FAIL as advisory** — \"reviewer failed but the issues are minor\" | Undermines the gate; equivalent to not having a gate | FAIL means revise and re-review. No exceptions. |\n| 4 | **Skipping the gate for \"simple\" plans** — \"this is straightforward, skip review\" | Judgment of simplicity is exactly what the gate validates | If the plan has 2+ work units or touches 3+ files, run the gate |\n| 5 | **Planner self-reviewing** — same agent that wrote the plan also reviews it | Confirmation bias; planner will approve their own work | Reviewers must be separate `Task()` instances from the planner |\n| 6 | **Unlimited iterations** — \"keep reviewing until it passes\" | Diminishing returns; likely a fundamental plan problem after 3 rounds | Max 3 iterations, then escalate to user with full context |\n| 7 | **Partial re-review** — only re-running the reviewer that failed | Other reviewers might fail on the revised plan | All 3 reviewers re-run on every iteration (fresh instances) |\n\n---\n\n## Integration Points\n\n### Upstream (inputs to this gate)\n\n- `writing-plans` skill — produces plans that feed into this gate\n- `orchestrated-execution` plan validation — pre-flight checklist runs before this gate\n- Direct plan drafting by planner\u002Fexplorer agents\n\n### Downstream (after gate approval)\n\n- Plan presented to user for final approval\n- **After user approval**: Persist the approved plan to `.beads\u002Fplans\u002Factive-plan.md` (see Section: Plan Persistence below)\n- User-approved plan flows to `orchestrated-execution` for the 4-phase execution loop\n- Work unit decomposition and implementation begin\n\n### Plan Persistence\n\nAfter the gate approves AND the user approves the plan, persist it to BEADS so it survives context compaction:\n\n```bash\nmkdir -p .beads\u002Fplans\n\n# Write with metadata header\ncat > .beads\u002Fplans\u002Factive-plan.md \u003C\u003C 'PLAN_EOF'\n# Active Plan\n\u003C!-- approved: \u003Ctimestamp> -->\n\u003C!-- gate-iterations: \u003CN> -->\n\u003C!-- user-approved: true -->\n\u003C!-- status: in-progress -->\n\n\u003Cfull approved plan text>\nPLAN_EOF\n```\n\nThis enables context recovery — if the agent loses context mid-execution, it can re-read the approved plan from disk instead of re-running the entire gate. See `orchestrated-execution` Section 6.5 for the full recovery protocol.\n\n### Relationship to Design Review Gate\n\nThe **design review gate** (`design-review-gate`) validates _design documents_ using 5 specialist agents (PM, Architect, Designer, Security, CTO) with APPROVED\u002FNEEDS_REVISION verdicts.\n\nThe **plan review gate** (this skill) validates _implementation plans_ using 3 adversarial reviewers (Feasibility, Completeness, Scope & Alignment) with binary PASS\u002FFAIL verdicts.\n\nThese are complementary gates at different stages:\n1. Design review gate validates _what_ to build\n2. Plan review gate validates _how_ to build it\n3. Orchestrated execution validates _that_ it was built correctly\n\n---\n\n## Success Criteria\n\nThe plan review gate succeeds when:\n\n- [ ] All three reviewers return PASS verdict\n- [ ] All blocking issues are resolved with evidence\n- [ ] Plan is presented to user with gate approval summary\n- [ ] Reviewer isolation was maintained (fresh instances, no cross-contamination)\n- [ ] Gate completed within 3 iterations\n\n---\n\n## Related Skills\n\n- `design-review-gate` — Validates design documents before planning begins\n- `orchestrated-execution` — Executes approved plans using the 4-phase loop\n- `writing-plans` — Produces plans that feed into this gate\n\n---\n\n## Rubric Reference\n\nReviewers follow: `.\u002Frubrics\u002Fplan-review-rubric-adversarial.md`\n\nThis adversarial rubric is distinct from `.\u002Frubrics\u002Fplan-review-rubric.md` (used by the CTO Agent for collaborative plan review). See the rubric file for detailed scoring criteria and evidence requirements.\n","# Plan Review Gate\n\n**Core principle**: No plan reaches the user without surviving independent adversarial scrutiny.\n\n## Purpose\n\nThis skill automatically activates after any implementation plan is drafted, before presenting it to the user. It spawns three independent adversarial reviewers in parallel — Feasibility, Completeness, and Scope & Alignment — each as a fresh `Task()` instance. ALL three must PASS. On failure, the planner incorporates feedback and resubmits to entirely fresh reviewer instances. The gate iterates until consensus or max iterations.\n\n---\n\n## Activation Triggers\n\nThis skill auto-activates when:\n\n1. An implementation plan is drafted (by planner, explorer, or orchestrator)\n2. The `writing-plans` skill completes a plan\n3. The orchestrator's plan validation phase produces a plan for review\n4. User explicitly requests: `\u002Fplan-review \u003Cpath-to-plan>`\n\n**Do NOT use for**: Trivial changes (single-file bug fixes, copy edits, config tweaks). The plan must have at least 2 work units or touch 3+ files to warrant gate review.\n\n---\n\n## The 3 Adversarial Reviewers\n\nEach reviewer is a fresh `Task()` instance with read-only access to the codebase. Reviewers produce binary PASS\u002FFAIL verdicts backed by cited evidence. No suggestions — only findings.\n\n### Reviewer 1: Feasibility\n\nCan this plan actually be executed against the real codebase?\n\n| Check | Classification | Criteria |\n| --- | --- | --- |\n| File paths exist | BLOCKING if fabricated | Every file path referenced in the plan must exist (verify with glob\u002Fgrep) |\n| Dependency ordering correct | BLOCKING if circular or forward-ref | Work units depend only on things that exist or are created before them |\n| Technical approach matches codebase | BLOCKING if incompatible | Proposed patterns, libraries, and conventions match what the codebase actually uses |\n| No unstated assumptions | BLOCKING if critical | Plan does not silently depend on services, env vars, or infrastructure that doesn't exist |\n| File scope realistic | WARNING | Each work unit's file scope is achievable without cascading changes |\n\n### Reviewer 2: Completeness\n\nDoes the plan fully address every aspect of the user's request?\n\n| Check | Classification | Criteria |\n| --- | --- | --- |\n| All requirements mapped | BLOCKING if gap exists | Every user requirement maps to at least one plan item |\n| Verification steps defined | BLOCKING if missing | Each change has a way to verify it worked (test, manual check, or assertion) |\n| Edge cases considered | BLOCKING if obvious gaps | Error scenarios, empty states, boundary conditions addressed |\n| Rollback\u002Fbackward compatibility | WARNING | Plan considers what happens if changes need to be reverted |\n| Cross-file integration points | BLOCKING if missing | Files that import\u002Fdepend on changed files are accounted for |\n\n### Reviewer 3: Scope & Alignment\n\nIs the plan right-sized for what the user actually asked?\n\n| Check | Classification | Criteria |\n| --- | --- | --- |\n| Matches user request | BLOCKING if divergent | Plan solves what was asked, not what the planner finds interesting |\n| No scope creep | BLOCKING if present | No unnecessary features, abstractions, or refactoring beyond the request |\n| No under-scoping | BLOCKING if present | Obvious implications of the request are not omitted |\n| Complexity proportional | WARNING | Solution complexity matches problem complexity |\n| No simpler alternative missed | WARNING | Plan is not over-engineered when a simpler approach would suffice |\n\n---\n\n## Reviewer Isolation Rules\n\nThese rules are **mandatory**. Violating any of them invalidates the review.\n\n1. **Fresh instances only.** Each reviewer is a new `Task()` instance — never resumed, never given prior context.\n2. **No cross-reviewer visibility.** No reviewer sees another reviewer's output. Ever.\n3. **Read-only codebase access.** Reviewers can read files, run grep\u002Fglob, but cannot modify anything.\n4. **No prior review findings on re-review.** When re-reviewing after iteration, completely fresh instances are spawned. The new reviewers have zero knowledge of what previous reviewers found.\n5. **Input is limited to:** the plan text, the user's original request, and the codebase (via read-only tools).\n\n**Why isolation matters:** Reviewers who see prior findings anchor on those findings instead of reviewing independently. Fresh instances prevent this bias and ensure each review cycle is a genuine independent check.\n\n---\n\n## Workflow\n\n```text\n1. Plan drafted by planner\u002Fexplorer\u002Forchestrator\n2. Spawn 3 adversarial reviewers in PARALLEL (fresh Task() instances)\n3. Collect all 3 verdicts\n4. IF all PASS --> present plan to user with gate approval summary\n5. IF any FAIL -->\n   a. Planner reads ALL feedback from all reviewers\n   b. Planner incorporates changes OR documents why feedback doesn't apply\n   c. Spawn 3 NEW reviewer instances (never reuse -- prevents anchoring)\n   d. Repeat from step 3\n6. Max 3 iterations --> present plan with remaining issues noted for user decision\n```\n\n### Phase 1: Spawn Reviewers (Parallel)\n\n```typescript\n\u002F\u002F Spawn all three reviewers in parallel for efficiency\nconst [feasibilityResult, completenessResult, scopeResult] = await Promise.all([\n  Task({\n    subagent_type: \"general-purpose\",\n    description: \"Feasibility review\",\n    prompt: feasibilityReviewPrompt(planText, userRequest),\n  }),\n  Task({\n    subagent_type: \"general-purpose\",\n    description: \"Completeness review\",\n    prompt: completenessReviewPrompt(planText, userRequest),\n  }),\n  Task({\n    subagent_type: \"general-purpose\",\n    description: \"Scope & Alignment review\",\n    prompt: scopeAlignmentReviewPrompt(planText, userRequest),\n  }),\n]);\n```\n\n### Phase 2: Evaluate Gate\n\n```text\nIF feasibilityResult.verdict === \"PASS\"\n   AND completenessResult.verdict === \"PASS\"\n   AND scopeResult.verdict === \"PASS\":\n  --> GATE APPROVED. Present plan to user.\n\nELSE:\n  --> Consolidate all FAIL findings.\n  --> Pass to planner for revision.\n  --> Increment iteration counter.\n  --> IF iterations >= 3: present plan with remaining issues to user.\n  --> ELSE: spawn fresh reviewers on revised plan.\n```\n\n### Phase 3: Iteration (on FAIL)\n\n1. Planner receives consolidated feedback from ALL reviewers (both PASS and FAIL)\n2. Planner revises the plan, addressing each FAIL finding explicitly\n3. For each finding, planner either:\n   - **Fixes it** — modifies the plan to resolve the issue\n   - **Rebuts it** — documents why the finding is incorrect or not applicable (with evidence)\n4. Spawn 3 entirely new `Task()` instances for re-review\n5. New reviewers see ONLY the revised plan and original request — NOT previous findings\n\n### Phase 4: Escalation (after 3 iterations)\n\nIf the gate has not achieved consensus after 3 iterations:\n\n```markdown\n## Plan Review Gate: ESCALATION REQUIRED (3\u002F3 iterations exhausted)\n\n### Remaining Blocking Issues\n\n#### Feasibility\n- [issue with evidence]\n\n#### Completeness\n- [issue with evidence]\n\n#### Scope & Alignment\n- [issue with evidence]\n\n### Iteration History\n| Iteration | Feasibility | Completeness | Scope & Alignment |\n|-----------|-------------|--------------|-------------------|\n| 1         | FAIL        | PASS         | FAIL              |\n| 2         | PASS        | PASS         | FAIL              |\n| 3         | PASS        | PASS         | FAIL              |\n\n### Options\n1. **Override** — Proceed with plan as-is (remaining issues become known risks)\n2. **Revise** — Continue iterating on the plan manually\n3. **Simplify** — Reduce scope to eliminate contentious items\n4. **Cancel** — Abandon this plan and start fresh\n\nPlease choose an option or provide additional context.\n```\n\n---\n\n## Reviewer Prompts\n\n### Feasibility Reviewer Prompt\n\n````markdown\nYou are the FEASIBILITY REVIEWER for a plan review gate.\n\n## Mode\nAdversarial — your job is to FIND FAILURES in plan feasibility, not to approve.\n\n## Rubric\nRead and follow: .\u002Frubrics\u002Fplan-review-rubric-adversarial.md (Feasibility section)\n\n## User's Original Request\n${userRequest}\n\n## Plan Under Review\n${planText}\n\n## Your Task\nDetermine whether this plan can actually be executed against the real codebase. Check:\n\n1. **File paths exist** — Use glob\u002Fgrep to verify every file path the plan references actually exists. Fabricated paths = BLOCKING FAIL.\n2. **Dependency ordering** — Verify work units don't have circular dependencies or reference things created in later steps. Read the codebase to confirm.\n3. **Technical approach** — Does the plan use patterns, libraries, and conventions that match the actual codebase? Read existing code to verify.\n4. **Unstated assumptions** — Does the plan silently depend on services, configurations, or infrastructure that doesn't exist?\n\n## Rules\n- Check EACH criterion. Cite file:line or glob results as evidence for PASS, or specific gaps for FAIL.\n- Any single BLOCKING issue means overall FAIL.\n- You have NO context from previous reviews. Judge fresh.\n- Do NOT suggest improvements. Only report PASS or FAIL with evidence.\n- Do NOT consider other reviewers. You are independent.\n\n## Output Format\nFollow the per-reviewer output format defined in the skill.\n````\n\n### Completeness Reviewer Prompt\n\n````markdown\nYou are the COMPLETENESS REVIEWER for a plan review gate.\n\n## Mode\nAdversarial — your job is to FIND GAPS in plan coverage, not to approve.\n\n## Rubric\nRead and follow: .\u002Frubrics\u002Fplan-review-rubric-adversarial.md (Completeness section)\n\n## User's Original Request\n${userRequest}\n\n## Plan Under Review\n${planText}\n\n## Your Task\nDetermine whether this plan fully addresses every aspect of the user's request. Check:\n\n1. **Requirement mapping** — Extract each distinct requirement from the user's request. For each one, find the plan item that addresses it. Missing mapping = BLOCKING FAIL.\n2. **Verification steps** — Each planned change must have a defined way to verify it works (test, assertion, manual check). Missing verification = BLOCKING FAIL.\n3. **Edge cases** — Are error scenarios, empty states, and boundary conditions addressed? Obvious gaps = BLOCKING FAIL.\n4. **Rollback\u002Fbackward compatibility** — Does the plan consider what happens if changes need to be reverted?\n5. **Cross-file integration** — Are files that import or depend on changed files accounted for?\n\n## Rules\n- Check EACH criterion. Cite specific user requirements and plan items as evidence.\n- Any single BLOCKING issue means overall FAIL.\n- You have NO context from previous reviews. Judge fresh.\n- Do NOT suggest improvements. Only report PASS or FAIL with evidence.\n- Do NOT consider other reviewers. You are independent.\n\n## Output Format\nFollow the per-reviewer output format defined in the skill.\n````\n\n### Scope & Alignment Reviewer Prompt\n\n````markdown\nYou are the SCOPE & ALIGNMENT REVIEWER for a plan review gate.\n\n## Mode\nAdversarial — your job is to FIND MISALIGNMENT between the plan and user request, not to approve.\n\n## Rubric\nRead and follow: .\u002Frubrics\u002Fplan-review-rubric-adversarial.md (Scope & Alignment section)\n\n## User's Original Request\n${userRequest}\n\n## Plan Under Review\n${planText}\n\n## Your Task\nDetermine whether this plan is right-sized for what the user actually asked. Check:\n\n1. **Matches user request** — Does the plan solve what was asked? Or does it solve something the planner found more interesting? Divergence = BLOCKING FAIL.\n2. **No scope creep** — Are there features, abstractions, or refactoring beyond what was requested? Unnecessary additions = BLOCKING FAIL.\n3. **No under-scoping** — Are obvious implications of the request omitted? Missing obvious work = BLOCKING FAIL.\n4. **Complexity proportional** — Is the solution complexity proportional to the problem complexity?\n5. **Simpler alternative** — Is there a significantly simpler approach that achieves the same outcome?\n\n## Rules\n- Check EACH criterion. Cite the user's request and plan scope as evidence.\n- Any single BLOCKING issue means overall FAIL.\n- You have NO context from previous reviews. Judge fresh.\n- Do NOT suggest improvements. Only report PASS or FAIL with evidence.\n- Do NOT consider other reviewers. You are independent.\n\n## Output Format\nFollow the per-reviewer output format defined in the skill.\n````\n\n---\n\n## Output Formats\n\n### Per-Reviewer Output\n\nEach reviewer produces output in this exact format:\n\n```markdown\n## [Reviewer Name] — [PASS\u002FFAIL]\n\n### Evidence\n- [Finding 1]: [file:line reference or specific gap with evidence]\n- [Finding 2]: [file:line reference or specific gap with evidence]\n- ...\n\n### Verdict\n[PASS: All criteria met — no blocking issues found]\nOR\n[FAIL: {numbered list of blocking issues with evidence}]\n```\n\n### Consolidated Gate Output (All PASS)\n\n```markdown\n## Plan Review Gate — APPROVED (iteration N of 3)\n\n| Reviewer | Verdict | Key Finding |\n|----------|---------|-------------|\n| Feasibility | PASS | All file paths verified, deps ordered correctly |\n| Completeness | PASS | All N requirements mapped to plan items |\n| Scope & Alignment | PASS | Plan matches user request, no scope creep |\n\nPlan is ready for user review.\n```\n\n### Consolidated Gate Output (Any FAIL)\n\n```markdown\n## Plan Review Gate — REVISION NEEDED (iteration N of 3)\n\n| Reviewer | Verdict | Blocking Issues |\n|----------|---------|-----------------|\n| Feasibility | PASS | — |\n| Completeness | FAIL | 2 blocking issues |\n| Scope & Alignment | FAIL | 1 blocking issue |\n\n### Blocking Issues (MUST ADDRESS)\n\n#### Completeness Reviewer\n1. **Missing requirement mapping**: User asked for X but no plan item addresses it\n2. **No verification for WU-003**: Plan item has no test or assertion defined\n\n#### Scope & Alignment Reviewer\n1. **Scope creep**: WU-005 adds caching layer not requested by user\n\n---\n\n**Iteration**: N of 3\n**Action Required**: Planner must address all blocking issues and resubmit.\n```\n\n---\n\n## Anti-Patterns\n\n| # | Anti-Pattern | Why It's Wrong | What to Do Instead |\n| --- | --- | --- | --- |\n| 1 | **Reusing reviewer instances** — passing findings to next review cycle | Anchoring bias: reviewer checks for previous findings instead of reviewing fresh | Spawn new `Task()` instances with no prior context |\n| 2 | **Cross-reviewer contamination** — sharing one reviewer's output with another | Destroys independence; reviewers converge instead of checking independently | Each reviewer sees only: plan, user request, codebase |\n| 3 | **Treating FAIL as advisory** — \"reviewer failed but the issues are minor\" | Undermines the gate; equivalent to not having a gate | FAIL means revise and re-review. No exceptions. |\n| 4 | **Skipping the gate for \"simple\" plans** — \"this is straightforward, skip review\" | Judgment of simplicity is exactly what the gate validates | If the plan has 2+ work units or touches 3+ files, run the gate |\n| 5 | **Planner self-reviewing** — same agent that wrote the plan also reviews it | Confirmation bias; planner will approve their own work | Reviewers must be separate `Task()` instances from the planner |\n| 6 | **Unlimited iterations** — \"keep reviewing until it passes\" | Diminishing returns; likely a fundamental plan problem after 3 rounds | Max 3 iterations, then escalate to user with full context |\n| 7 | **Partial re-review** — only re-running the reviewer that failed | Other reviewers might fail on the revised plan | All 3 reviewers re-run on every iteration (fresh instances) |\n\n---\n\n## Integration Points\n\n### Upstream (inputs to this gate)\n\n- `writing-plans` skill — produces plans that feed into this gate\n- `orchestrated-execution` plan validation — pre-flight checklist runs before this gate\n- Direct plan drafting by planner\u002Fexplorer agents\n\n### Downstream (after gate approval)\n\n- Plan presented to user for final approval\n- **After user approval**: Persist the approved plan to `.beads\u002Fplans\u002Factive-plan.md` (see Section: Plan Persistence below)\n- User-approved plan flows to `orchestrated-execution` for the 4-phase execution loop\n- Work unit decomposition and implementation begin\n\n### Plan Persistence\n\nAfter the gate approves AND the user approves the plan, persist it to BEADS so it survives context compaction:\n\n```bash\nmkdir -p .beads\u002Fplans\n\n# Write with metadata header\ncat > .beads\u002Fplans\u002Factive-plan.md \u003C\u003C 'PLAN_EOF'\n# Active Plan\n\u003C!-- approved: \u003Ctimestamp> -->\n\u003C!-- gate-iterations: \u003CN> -->\n\u003C!-- user-approved: true -->\n\u003C!-- status: in-progress -->\n\n\u003Cfull approved plan text>\nPLAN_EOF\n```\n\nThis enables context recovery — if the agent loses context mid-execution, it can re-read the approved plan from disk instead of re-running the entire gate. See `orchestrated-execution` Section 6.5 for the full recovery protocol.\n\n### Relationship to Design Review Gate\n\nThe **design review gate** (`design-review-gate`) validates _design documents_ using 5 specialist agents (PM, Architect, Designer, Security, CTO) with APPROVED\u002FNEEDS_REVISION verdicts.\n\nThe **plan review gate** (this skill) validates _implementation plans_ using 3 adversarial reviewers (Feasibility, Completeness, Scope & Alignment) with binary PASS\u002FFAIL verdicts.\n\nThese are complementary gates at different stages:\n1. Design review gate validates _what_ to build\n2. Plan review gate validates _how_ to build it\n3. Orchestrated execution validates _that_ it was built correctly\n\n---\n\n## Success Criteria\n\nThe plan review gate succeeds when:\n\n- [ ] All three reviewers return PASS verdict\n- [ ] All blocking issues are resolved with evidence\n- [ ] Plan is presented to user with gate approval summary\n- [ ] Reviewer isolation was maintained (fresh instances, no cross-contamination)\n- [ ] Gate completed within 3 iterations\n\n---\n\n## Related Skills\n\n- `design-review-gate` — Validates design documents before planning begins\n- `orchestrated-execution` — Executes approved plans using the 4-phase loop\n- `writing-plans` — Produces plans that feed into this gate\n\n---\n\n## Rubric Reference\n\nReviewers follow: `.\u002Frubrics\u002Fplan-review-rubric-adversarial.md`\n\nThis adversarial rubric is distinct from `.\u002Frubrics\u002Fplan-review-rubric.md` (used by the CTO Agent for collaborative plan review). See the rubric file for detailed scoring criteria and evidence requirements.\n",{"name":5,"triggers":37,"description":7,"auto_activate":42},[38,39,40,41],"plan drafted","implementation plan created","after:writing-plans","after:orchestrated-execution:plan-validation",true,"main","a298c929b6cbd662e1fce54302ce520d5ceea1a5","tools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fplan-review-gate","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain","https:\u002F\u002Fgithub.com\u002FPrekzursil","2026-11-02 14:30:57",{"source":8,"skillName":5,"commands":50,"prompt":60,"zipAvailable":42},[51,54,57],{"tool":52,"command":53},"npx","npx skills add Prekzursil\u002Fagent-skills-toolchain --skill plan-review-gate",{"tool":55,"command":56},"bunx","bunx skills add Prekzursil\u002Fagent-skills-toolchain --skill plan-review-gate",{"tool":58,"command":59},"pnpm","pnpm dlx skills add Prekzursil\u002Fagent-skills-toolchain --skill plan-review-gate","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fplan-review-gate\u002FSKILL.md",[62],{"path":63,"resourceType":64,"resourceTypeDesc":65,"sizeBytes":66,"sourceHtmlUrl":67},"rubrics\u002Fplan-review-rubric-adversarial.md","REFERENCE","参考文档",8961,"https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fplan-review-gate\u002Frubrics\u002Fplan-review-rubric-adversarial.md",[69,90,121,147,161,176],{"skillNo":70,"name":71,"nameZh":6,"description":72,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":73,"categories":74,"keywords":75,"publishedAt":32},"01M6DF7D7478R55P46REYH4QAC","clarify-requirements","Resolve genuine pre-execution ambiguity by scanning repo context, generating 1-6 grounded options, and asking 1-3 focused questions via AskUserQuestion. NOT for mid-task use (injection risk); NOT when the goal is already unambiguous; use to disambiguate vague prompts before any file edits.","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Fworkspace-hooks\u002Fskills\u002Fclarify-requirements\u002FSKILL.md",[],[76,77,78,79,80,81,82,83,84,85,86,87,88,27,89],"clarify requirements","clarify","requirements","risk","options","task","prompts","goal","scanning","use","context","repo","injection","file",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":101,"publishedAt":32},"01M6DF79CA4BHJS66J8EZDBPWJ","openmm-md","Run FREE, open-source, Windows-native GPU molecular dynamics via the openmm-md MCP (OpenMM + CUDA on the local NVIDIA GPU). Use for protein \u002F protein-ligand MD when you want a free stack or are on Windows without a Schrodinger license. Covers the full workflow (prepare, solvate, minimize, equilibrate, production, analyze, mmgbsa) AND an honest decision guide vs Schrodinger Desmond, including how to run Desmond legitimately on Linux or a cloud GPU with a real license. This is a deliberately LESSER free alternative and does NOT replace the schrodinger MCP tools. Do NOT use it to pick a free tool when a validated FEP+, WaterMap, IFD-MD, or Prime MM-GBSA result is actually required.","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Fmcp\u002Fopenmm-md-mcp\u002Fskill\u002Fopenmm-md\u002FSKILL.md",[96],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[102,103,104,105,106,107,108,109,110,111,112,113,114,115,85,116,117,118,119,120],"openmm md","how","decision","pick","linux","analyze","tool","stack","open","NVIDIA","gpu","license","workflow","windows","free","molecular dynamics","local","do","MCP",{"skillNo":122,"name":123,"nameZh":6,"description":124,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":125,"categories":126,"keywords":133,"publishedAt":32},"01M6DF76C1MG85VEWP8VZCBNMN","visual-review","Take screenshots of web pages and UI using Playwright for visual review and iteration","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fvisual-review\u002FSKILL.md",[127,130],{"categoryNo":128,"categoryName":129,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000003","演示文稿",{"categoryNo":131,"categoryName":132,"taxonomyType":99,"taxonomyTypeDesc":100},"01JBSEEDCAT000000000000008","测试与质量",[19,134,135,136,137,138,139,140,141,142,103,143,144,145,146],"visual","visual review","pages","web","false","iteration","take","check","slides","ui","screenshot","playwright","screenshots",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":32},"01M6DF73AQVCBZKEN0YXEX9FXP","status","Diagnostic status report — shows metaswarm installation state, project setup, and potential issues","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fstatus\u002FSKILL.md",[],[149,154,155,156,157,158,159,160],"setup","report","project","installation","project setup","issues","state",{"skillNo":162,"name":163,"nameZh":6,"description":164,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":165,"categories":166,"keywords":168,"publishedAt":32},"01M6DF6X6C2XB0P6GX76P7TTYV","start","Use when starting work on any task, when the user mentions metaswarm, or when the user wants to begin tracked development work","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fstart\u002FSKILL.md",[167],{"categoryNo":97,"categoryName":98,"taxonomyType":99,"taxonomyTypeDesc":100},[163,169,81,170,171,172,85,29,173,174,175],"start issue","issue","ready","work on issue","work","work on","development",{"skillNo":177,"name":154,"nameZh":6,"description":178,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":179,"categories":180,"keywords":181,"publishedAt":32},"01M6DF6QMJ9AJKFKHHKRT005PQ","Interactive project setup — detects your project, configures metaswarm, writes project-local files","https:\u002F\u002Fgithub.com\u002FPrekzursil\u002Fagent-skills-toolchain\u002Fblob\u002Fmain\u002Ftools\u002Feditor\u002Fmetaswarm\u002Fskills\u002Fsetup\u002FSKILL.md",[],[154,156,118,182,158,183],"files","interactive"]