Propose a change
Name Last commit message Last updated
screenshots Add screenshots/hero.png 21d ago
debate-prompts.md Rebase off gallia/gh/adompkg: use adom-wiki CLI for context gathering (v1.2.0) 10d ago
install.sh Publish adom-plan source + README 21d ago
package.json Rebase off gallia/gh/adompkg: use adom-wiki CLI for context gathering (v1.2.0) 10d ago
page.json Remove internal identifiers from page.json 10d ago
README.md Rebase off gallia/gh/adompkg: use adom-wiki CLI for context gathering (v1.2.0) 10d ago
SKILL.md Rebase off gallia/gh/adompkg: use adom-wiki CLI for context gathering (v1.2.0) 10d ago
uninstall.sh Add adompkg installer files 1mo ago

adom-plan — Exhaustive Plan Review

End-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.

Total agents: up to 8 (1 expansion + 6 debate + 1 red-team consensus).

How the agents coordinate

How it works

  1. Phase 0 — Locate the plan (plan file, file path argument, or conversation context)
  2. Phase 0.5 — Expand the plan via a built-in Opus expansion agent
  3. Phase 1 — Fetch platform context via the adom-wiki CLI (wiki catalog, installed skills, recent wiki activity, existing plans)
  4. Phase 2 — Launch 6 adversarial debate agents in parallel (3 pairs):
    • Architecture: Opus advocate vs Sonnet challenger
    • Implementation: Sonnet roadmap-builder vs Opus gap-finder
    • Security & Risk: Sonnet auditor vs Sonnet red-team attacker
  5. Phase 3 — Red-team the consensus with one final Opus agent
  6. Phase 4 — Scored synthesis: scorecard, contested decisions, risk register, E2E strategy, action items
  7. Phase 5 — Present the summary to the user

Key features

  • Adversarial pairing — two agents argue each category from opposite dispositions, surfacing disagreements a single model would self-censor
  • Multi-model diversity — Opus reasons conservatively and architecturally; Sonnet is pragmatic and detail-oriented
  • Structured scoring — 1–5 scale across Feasibility, Maintainability, Platform Leverage, Simplicity; 2+ point deltas auto-flagged
  • Platform awareness — fetches the wiki catalog so agents reference real tools, not hypothetical ones
  • The 30-Day Failure Scenario — forces concrete, actionable thinking about what will actually go wrong
  • Consensus red-team — attacks the "safe" decisions everyone agrees on, because the most dangerous risks are the ones nobody flags

Then build it — pairs with three-musketeers

adom-plan is the plan half of Adom's complex-project pipeline. Once the plan is vetted here, build it with three-musketeers — the companion skill that drives the actual build through a Builder → Adversarial Reviewer → Verifier loop until it genuinely works:

  1. Plan robustly with adom-plan — 6+ vetting agents harden what to build.
  2. Build robustly with three-musketeers — 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).

Expensive but effective — reach for the full plan→build pipeline on high-stakes or long-running work.

Invocation

/adom-plan                          # review the active plan file
/adom-plan path/to/plan.md          # review a specific file

Output

The skill appends a Debate Review Summary to the plan file containing:

  • Scorecard — per-section grades (A/B/C/F) with dimensional scores
  • Consensus Decisions — verified safe items
  • Contested Decisions — where agents disagreed, with recommendations
  • Fragile Consensus — items the red-team flagged
  • Risk Register — consolidated threat table with mitigations
  • Validation & E2E Strategy — complete test plan
  • The 30-Day Failure Scenario — the most likely production failure
  • Action Items — numbered list tagged BLOCKING / RECOMMENDED / NICE-TO-HAVE