adom-plan — Exhaustive Plan Review

@@ -36,7 +36,7 @@     }   ],   "source_path": "SKILL.md",-  "readme": "# adom-plan \u2014 Exhaustive Plan Review\n\nEnd-to-end planning pipeline: expand a sketch into a detailed plan, then stress-test it via adversarial multi-model debate. Runs a built-in Opus expansion pass to flesh out the sketch, then launches **three adversarial pairs** (6 agents: Opus vs Sonnet per category) arguing architecture, implementation, and security from opposite dispositions. A 7th agent red-teams the consensus. Final output is a scored, vetted plan with validation strategies, E2E testing, a risk register, and prioritized action items.\n\n**Total agents: up to 8** (1 expansion + 6 debate + 1 red-team consensus).\n\n![How the agents coordinate](/blob/skill/adom-plan/screenshots/coordination.png)\n\n## How it works\n\n1. **Phase 0** \u2014 Locate the plan (plan file, file path argument, or conversation context)\n2. **Phase 0.5** \u2014 Expand the plan via a built-in Opus expansion agent\n3. **Phase 1** \u2014 Fetch platform context (wiki catalog, installed skills, recent commits, existing plans)\n4. **Phase 2** \u2014 Launch 6 adversarial debate agents in parallel (3 pairs):\n   - Architecture: Opus advocate vs Sonnet challenger\n   - Implementation: Sonnet roadmap-builder vs Opus gap-finder\n   - Security & Risk: Sonnet auditor vs Sonnet red-team attacker\n5. **Phase 3** \u2014 Red-team the consensus with one final Opus agent\n6. **Phase 4** \u2014 Scored synthesis: scorecard, contested decisions, risk register, E2E strategy, action items\n7. **Phase 5** \u2014 Present the summary to the user\n\n## Key features\n\n- **Adversarial pairing** \u2014 two agents argue each category from opposite dispositions, surfacing disagreements a single model would self-censor\n- **Multi-model diversity** \u2014 Opus reasons conservatively and architecturally; Sonnet is pragmatic and detail-oriented\n- **Structured scoring** \u2014 1\u20135 scale across Feasibility, Maintainability, Platform Leverage, Simplicity; 2+ point deltas auto-flagged\n- **Platform awareness** \u2014 fetches the wiki catalog so agents reference real tools, not hypothetical ones\n- **The 30-Day Failure Scenario** \u2014 forces concrete, actionable thinking about what will actually go wrong\n- **Consensus red-team** \u2014 attacks the \"safe\" decisions everyone agrees on, because the most dangerous risks are the ones nobody flags\n\n## Then build it \u2014 pairs with `three-musketeers`\n\nadom-plan is the **plan half** of Adom's complex-project pipeline. Once the plan is vetted here, build it with **[`three-musketeers`](/adom/three-musketeers)** \u2014 the companion skill that drives the actual build through a Builder \u2192 Adversarial Reviewer \u2192 Verifier loop until it genuinely works:\n\n1. **Plan robustly** with adom-plan \u2014 6+ vetting agents harden *what to build*.\n2. **Build robustly** with three-musketeers \u2014 3 building agents harden *that it was built and actually works* (the Verifier confirms behavior as a user, not against the plan, so the builder is free to correct anything adom-plan got wrong).\n\nExpensive but effective \u2014 reach for the full plan\u2192build pipeline on high-stakes or long-running work.\n\n## Invocation\n\n```\n/adom-plan                          # review the active plan file\n/adom-plan path/to/plan.md          # review a specific file\n```\n\n## Output\n\nThe skill appends a **Debate Review Summary** to the plan file containing:\n\n- **Scorecard** \u2014 per-section grades (A/B/C/F) with dimensional scores\n- **Consensus Decisions** \u2014 verified safe items\n- **Contested Decisions** \u2014 where agents disagreed, with recommendations\n- **Fragile Consensus** \u2014 items the red-team flagged\n- **Risk Register** \u2014 consolidated threat table with mitigations\n- **Validation & E2E Strategy** \u2014 complete test plan\n- **The 30-Day Failure Scenario** \u2014 the most likely production failure\n- **Action Items** \u2014 numbered list tagged BLOCKING / RECOMMENDED / NICE-TO-HAVE\n",+  "readme": "# adom-plan \u2014 Exhaustive Plan Review\n\nEnd-to-end planning pipeline: expand a sketch into a detailed plan, then stress-test it via adversarial multi-model debate. Runs a built-in Opus expansion pass to flesh out the sketch, then launches **three adversarial pairs** (6 agents: Opus vs Sonnet per category) arguing architecture, implementation, and security from opposite dispositions. A 7th agent red-teams the consensus. Final output is a scored, vetted plan with validation strategies, E2E testing, a risk register, and prioritized action items.\n\n**Total agents: up to 8** (1 expansion + 6 debate + 1 red-team consensus).\n\n![How the agents coordinate](/blob/skill/adom-plan/screenshots/coordination.png)\n\n## How it works\n\n1. **Phase 0** \u2014 Locate the plan (plan file, file path argument, or conversation context)\n2. **Phase 0.5** \u2014 Expand the plan via a built-in Opus expansion agent\n3. **Phase 1** \u2014 Fetch platform context (wiki catalog, installed skills, recent commits, existing plans)\n4. **Phase 2** \u2014 Launch 6 adversarial debate agents in parallel (3 pairs):\n   - Architecture: Opus advocate vs Sonnet challenger\n   - Implementation: Sonnet roadmap-builder vs Opus gap-finder\n   - Security & Risk: Sonnet auditor vs Sonnet red-team attacker\n5. **Phase 3** \u2014 Red-team the consensus with one final Opus agent\n6. **Phase 4** \u2014 Scored synthesis: scorecard, contested decisions, risk register, E2E strategy, action items\n7. **Phase 5** \u2014 Present the summary to the user\n\n## Key features\n\n- **Adversarial pairing** \u2014 two agents argue each category from opposite dispositions, surfacing disagreements a single model would self-censor\n- **Multi-model diversity** \u2014 Opus reasons conservatively and architecturally; Sonnet is pragmatic and detail-oriented\n- **Structured scoring** \u2014 1\u20135 scale across Feasibility, Maintainability, Platform Leverage, Simplicity; 2+ point deltas auto-flagged\n- **Platform awareness** \u2014 fetches the wiki catalog so agents reference real tools, not hypothetical ones\n- **The 30-Day Failure Scenario** \u2014 forces concrete, actionable thinking about what will actually go wrong\n- **Consensus red-team** \u2014 attacks the \"safe\" decisions everyone agrees on, because the most dangerous risks are the ones nobody flags\n\n## Then build it \u2014 pairs with `three-musketeers`\n\nadom-plan is the **plan half** of Adom's complex-project pipeline. Once the plan is vetted here, build it with **[`three-musketeers`](/drew2/three-musketeers)** \u2014 the companion skill that drives the actual build through a Builder \u2192 Adversarial Reviewer \u2192 Verifier loop until it genuinely works:\n\n1. **Plan robustly** with adom-plan \u2014 6+ vetting agents harden *what to build*.\n2. **Build robustly** with three-musketeers \u2014 3 building agents harden *that it was built and actually works* (the Verifier confirms behavior as a user, not against the plan, so the builder is free to correct anything adom-plan got wrong).\n\nExpensive but effective \u2014 reach for the full plan\u2192build pipeline on high-stakes or long-running work.\n\n## Invocation\n\n```\n/adom-plan                          # review the active plan file\n/adom-plan path/to/plan.md          # review a specific file\n```\n\n## Output\n\nThe skill appends a **Debate Review Summary** to the plan file containing:\n\n- **Scorecard** \u2014 per-section grades (A/B/C/F) with dimensional scores\n- **Consensus Decisions** \u2014 verified safe items\n- **Contested Decisions** \u2014 where agents disagreed, with recommendations\n- **Fragile Consensus** \u2014 items the red-team flagged\n- **Risk Register** \u2014 consolidated threat table with mitigations\n- **Validation & E2E Strategy** \u2014 complete test plan\n- **The 30-Day Failure Scenario** \u2014 the most likely production failure\n- **Action Items** \u2014 numbered list tagged BLOCKING / RECOMMENDED / NICE-TO-HAVE\n",   "author": {     "id": "695820315b5f1e4db2fcf602",     "name": "Kyle Bergstedt",