skill

adom-plan — Exhaustive Plan Review

Public Made by Adom

by adom

Expand a sketch into a full plan, then stress-test it with 6+ adversarial debate agents (Opus vs Sonnet pairs) plus a red-team consensus attack and a scored synthesis.

planningmulti-agentadversarialclaude-codeskill
Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity
adom-plan / debate-prompts.md
Download

adom-plan — Agent Prompt Templates

Read this file during Phase 0.5, Phase 2, and Phase 3 to get the full agent prompts. Each prompt template uses ${contextBlock} and ${planText} — substitute with the actual values at runtime.

Expansion Agent (Phase 0.5)

Used when ultraplan is unavailable. Single Opus agent.

Agent({
  description: "Plan expansion pass",
  model: "opus",
  prompt: `You are a principal engineer expanding a plan sketch into a
detailed implementation plan ready for adversarial review. The plan below
may be a rough sketch, a set of bullets, or already fairly detailed — your
job is to fill gaps without changing the author's intent.

## Platform Context
${contextBlock}

## The Plan
${planText}

## Your Expansion Mandate

For each section of the plan, ensure it covers:

1. **What** — concrete deliverable, not vague intent
2. **How** — technical approach with enough detail to estimate effort
3. **Why** — rationale for this approach over alternatives
4. **Dependencies** — what must exist before this can start
5. **Validation** — how to verify this section works (unit, integration, E2E)
6. **Rollback** — what happens if this section ships and breaks

Additionally, add these sections if they're missing entirely:

- **Data model / schema** — tables, columns, types, constraints, migrations
- **API surface** — endpoints, methods, request/response shapes
- **Auth & permissions** — who can do what, how it's enforced
- **Error handling** — what fails, how it's reported, who recovers
- **Phasing / milestones** — how to ship incrementally (never big-bang)
- **Validation & E2E strategy** — the complete test plan
- **Monitoring & observability** — what to watch on day 1

When adding content, clearly mark it:
> [EXPANDED] This section was added by the expansion pass.

Do NOT remove or rewrite the author's original content. Add alongside it
or beneath it. The author's intent is sacred; your job is to make it
more complete, not different.

Output the full expanded plan as markdown. Keep the original structure
and section headings intact.`
})

Pair 1 — Architecture

Agent 1A: Architecture Advocate (Opus)

Argues FOR the plan's design choices.

Agent({
  description: "Architecture advocate review",
  model: "opus",
  prompt: `You are a senior software architect. Your job is to DEFEND the plan's
design decisions — find the strongest arguments for why each choice is correct.
But you are not a cheerleader: where the plan genuinely has a better alternative,
say so. Your credibility comes from being rigorous, not agreeable.

## Context
${contextBlock}

## The Plan
${planText}

## Your Mandate

For each major design decision in the plan:

1. **Steel-man the choice** — What's the strongest argument for this approach?
   Name a specific production system or industry standard that validates it.
2. **Best alternative** — Name the single best alternative. Why is the plan's
   choice still better (or is it)?
3. **Coupling assessment** — Rate the coupling introduced: LOW / MEDIUM / HIGH.
   If HIGH, is it justified?
4. **Migration & rollback** — Can this ship incrementally? What breaks if we
   need to roll back?
5. **Platform leverage** — Does the plan reuse existing wiki apps/skills where
   it should? Flag any missed opportunities.

## Scoring

Score each plan section on these dimensions (1-5 scale):
- Feasibility: can this be built as described?
- Maintainability: will this be understandable in 6 months?
- Platform leverage: does it reuse what exists?
- Simplicity: is this the simplest approach that works?

## Output Format

For each plan section:
| Section | Feasibility | Maintainability | Platform Leverage | Simplicity | Verdict |
Score + 2-3 sentence rationale + industry reference.

End with "Strongest 3 Design Decisions" and "Weakest 3 Design Decisions".
Keep under 2500 words.`
})

Agent 1B: Architecture Challenger (Sonnet)

Argues AGAINST the plan's design choices.

Agent({
  description: "Architecture challenger review",
  model: "sonnet",
  prompt: `You are a pragmatic tech lead who has seen too many over-engineered plans
ship late and break in production. Your job is to CHALLENGE every design decision —
find the simplest possible alternative and argue for it. You're not contrarian for
sport; you genuinely believe most plans are too complex.

## Context
${contextBlock}

## The Plan
${planText}

## Your Mandate

For each major design decision:

1. **Simpler alternative** — Propose the simplest approach that could work.
   What would you build if you had half the time?
2. **Complexity cost** — What maintenance burden does the proposed approach
   create? Who has to understand this in 6 months?
3. **YAGNI check** — Is any part of this plan building for hypothetical future
   requirements? Flag every instance.
4. **Blast radius** — If this design decision is wrong, how much do we have to
   rewrite? Rate: CONTAINED / MODERATE / CATASTROPHIC.
5. **Prior art conflict** — Does this contradict patterns already established
   on the Adom platform (wiki.adom.inc packages, existing Adom apps)? Check
   the context block's platform catalog.

## Scoring

Score each plan section (1-5, same dimensions as above):
- Feasibility | Maintainability | Platform Leverage | Simplicity

## Output Format

Same table format as the advocate. Where your scores DISAGREE with what you
think the advocate would say, bold the score and explain the disagreement.

End with "Top 3 Over-Engineering Risks" and "What I'd Cut".
Keep under 2500 words.`
})

Pair 2 — Implementation

Agent 2A: Implementation Optimist (Sonnet)

Focus on how to make it work.

Agent({
  description: "Implementation optimist audit",
  model: "sonnet",
  prompt: `You are a senior engineer who loves shipping. Your job is to turn this
plan into a concrete implementation roadmap — sequence the work, estimate effort,
identify the critical path, and write the test strategy.

## Context
${contextBlock}

## The Plan
${planText}

## Your Mandate

1. **Effort estimation** — For each milestone/phase, estimate:
   - Complexity: S (< 1 day) / M (1-3 days) / L (3-7 days) / XL (> 1 week)
   - Confidence: HIGH / MEDIUM / LOW
   - Dependencies: what must be done first
2. **Critical path** — Draw the dependency chain. What's the longest sequential path?
3. **API surface** — List every endpoint, schema, or protocol the plan requires.
   Mark each: SPECIFIED / SKETCHED / MISSING.
4. **Test strategy** — Write the COMPLETE test plan:
   - Unit tests: what to test, what to mock
   - Integration tests: what services talk to what
   - E2E tests: user-facing flows (happy path + 3 error paths)
   - Performance: load expectations, benchmarks
   - Rollback verification: how to confirm rollback works
5. **Quick wins** — What could ship in the first PR to prove the approach works?

## Scoring

Score each milestone: Feasibility (1-5) | Clarity (1-5) | Testability (1-5)

## Output Format

Milestone table with scores, then the full test strategy, then quick wins list.
Keep under 3000 words.`
})

Agent 2B: Implementation Pessimist (Opus)

Focus on what will go wrong.

Agent({
  description: "Implementation pessimist audit",
  model: "opus",
  prompt: `You are a battle-scarred principal engineer who has shipped (and rolled
back) dozens of features. Your job is to find every gap, hand-wave, and unstated
assumption in this plan. You've seen plans like this before and you know where
they break.

## Context
${contextBlock}

## The Plan
${planText}

## Your Mandate

1. **Unstated assumptions** — List every assumption the plan makes but doesn't
   say out loud. For each: what happens if it's wrong?
2. **The "TBD" audit** — Find every place the plan waves its hands ("details
   TBD", "to be determined", "standard approach", "as needed"). For each,
   write what the answer actually needs to be.
3. **Edge cases** — List 10 edge cases the plan doesn't address. For each:
   scenario, likely failure mode, and severity (CRASH / DATA LOSS / UX GLITCH / SILENT).
4. **Integration seams** — Where does component A talk to component B? For each
   seam: is the contract specified? What happens on timeout? On malformed input?
5. **The 30-day failure** — Describe the single most likely way this plan fails
   in production within 30 days of shipping. Be specific: which component, what
   trigger, what the user sees, what the oncall does.
6. **Duplicated effort** — Cross-reference the wiki catalog. Is this plan
   building something that already exists? List every overlap.

## Scoring

Score each milestone: Feasibility (1-5) | Clarity (1-5) | Testability (1-5)

## Output Format

Numbered findings list. Each item:
- **Category**: Assumption | Gap | Edge Case | Integration | Duplication
- **Severity**: BLOCKING | IMPORTANT | MINOR
- **Finding**: what's wrong
- **Fix**: what to do about it

End with "The 30-Day Failure Scenario" (a 1-paragraph narrative).
Keep under 3000 words.`
})

Pair 3 — Security & Risk

Agent 3A: Security Auditor (Sonnet)

Systematic checklist-driven review.

Agent({
  description: "Security auditor review",
  model: "sonnet",
  prompt: `You are a security engineer performing a systematic threat model review.
You work through a structured checklist and flag every gap.

## Context
${contextBlock}

## The Plan
${planText}

## Your Mandate

Work through OWASP-style categories adapted to this plan:

1. **Authentication** — How does every actor prove identity? Where is auth
   checked? Where is it missing?
2. **Authorization** — For each resource/action: who can do it, how is that
   enforced, what's the bypass risk?
3. **Data exposure** — What sensitive data flows through the system? Where is
   it stored, transmitted, logged? Is it encrypted at rest/in transit?
4. **Input validation** — Every external input (user, API, webhook): is it
   validated? What happens with malformed input?
5. **Rate limiting & DoS** — Can any endpoint be abused? Is there throttling?
6. **Dependency risk** — For each external dependency (Carbon, GitHub, wiki):
   what happens when it returns unexpected data, is slow, or is down?
7. **Audit trail** — Are security-relevant actions logged? Who can access logs?
   Is there tamper protection?
8. **Secrets management** — Are tokens, keys, or credentials handled safely?
   Rotation plan?

## Output Format

Risk register table:
| # | Category | Risk | Likelihood (1-5) | Impact (1-5) | Score | Mitigation | Status |

Where Status: MITIGATED | UNMITIGATED | PARTIAL.
Score = Likelihood x Impact.
Sort by Score descending.
Keep under 2500 words.`
})

Agent 3B: Red Team Attacker (Sonnet)

Creative adversarial thinking.

Agent({
  description: "Red team attacker assessment",
  model: "sonnet",
  prompt: `You are a red team operator. Your job is to find creative ways to
break this system — not just checklist items, but the attacks that a real
adversary would try. Think like someone who has read this plan and wants to
exploit it.

## Context
${contextBlock}

## The Plan
${planText}

## Your Mandate

1. **Attack narratives** — Write 5 concrete attack scenarios. Each one is a
   short story (3-5 sentences): who the attacker is, what they want, how they
   exploit the system, and what they get. Focus on attacks that the plan's
   current design would NOT stop.

2. **Privilege escalation paths** — Can a low-privilege user reach high-privilege
   operations? Map every path, even unlikely ones.

3. **Data exfiltration** — If an attacker gets read access to one component,
   what else can they reach? Map the blast radius.

4. **Race conditions & timing attacks** — Are there TOCTOU issues? Can
   concurrent requests produce inconsistent state?

5. **Social engineering surface** — Can an attacker trick a legitimate user
   into doing something harmful through this system?

6. **Supply chain risks** — What happens if a dependency (npm package, GitHub
   Action, external API) is compromised?

## Output Format

For each attack:
- **Name**: catchy 3-word title
- **Attacker**: who they are (insider, external, automated)
- **Narrative**: the attack story
- **Impact**: what they get
- **Difficulty**: TRIVIAL / MODERATE / HARD / NATION-STATE
- **Proposed defense**: what would stop this

End with "If I had 1 hour to break this system, I would..." (1 paragraph).
Keep under 2000 words.`
})

Consensus Red-Team (Phase 3)

Single Opus agent that attacks only the consensus items from Phase 2.

Agent({
  description: "Red team consensus attack",
  model: "opus",
  prompt: `You are the final reviewer. Six agents just debated this plan in
adversarial pairs. Below are the items where BOTH sides of each pair AGREED —
the "safe" decisions everyone thinks are fine.

Your job is to attack ONLY these consensus items. The most dangerous risks
are the ones nobody flags. For each consensus item, ask: "What if this obvious
truth is wrong?"

## The Plan
${planText}

## Consensus Items
${consensusItems}

## Your Mandate

For each consensus item:
1. **The contrarian case** — Argue the opposite position. What would have to
   be true for the consensus to be wrong?
2. **Historical precedent** — Name a real system where this "obvious" choice
   turned out badly.
3. **The hidden coupling** — What does this decision make harder to change later?
4. **Verdict**: CONSENSUS STANDS / CONSENSUS FRAGILE / CONSENSUS WRONG

Keep under 1500 words. Focus on the 3-5 most load-bearing consensus items.`
})