adversarial-proposal

Adversarial Proposal Framework

Overview

This skill runs an adversarial investigation workflow that forces multiple independent perspectives on a problem before committing to a solution. Instead of one analysis pass (which risks tunnel vision), it requires separate agent sessions to generate competing proposals, cross-examines them, and reconciles the results into a battle-tested plan.

Non-Negotiable Constraint

The independence requirement is strict:

• Proposal A and Proposal B must be produced by different agent sessions or workers.
• Those sessions must not see each other's outputs before their own proposal is complete.
• You must not claim "independent" or "separate agent" analysis when both proposals were produced in one shared-context session.
• If the environment cannot support real isolation, stop and tell the user exactly that. Do not silently downgrade to a single-session version.
• The same rule applies to the critique round: A-feedback and B-feedback must be produced from separate perspectives with no cross-contamination.

When to Use

• Bug investigation and fix planning
• Feature implementation planning
• Architecture decisions
• Refactoring strategies
• Any technical problem where you want high confidence before implementing

Workflow

ROUND 1: Two isolated investigations
  Agent/Session A ─────── Agent/Session B
  (surgical/direct)       (systemic/holistic)
          │                       │
          └─────────┬─────────────┘
                    ▼
ROUND 2: Synthesis
  Agent/Session C reviews A + B, states disagreements,
  produces a superior combined proposal
                    │
         ┌──────────┴─────────────┐
         ▼                        ▼
ROUND 3: Isolated critique
  Agent/Session A'            Agent/Session B'
  critiques C                 critiques C
  (can know A + C only)       (can know B + C only)
         │                        │
         └──────────┬─────────────┘
                    ▼
ROUND 4: Reconciliation
  Reconciler produces final-plan.md

How to Execute

Step 0: Gather Context

1. Get the problem statement from the user
2. Identify the relevant source files — ask the user or search the codebase
3. Create the output directory: {project}/.dev/proposals/{issue-slug}/
4. Save the problem statement as problem-statement.md
5. Verify you have a real isolated-execution path for separate agents/sessions
6. If you do not, stop and tell the user the skill cannot be executed faithfully in the current environment
7. Read all the source files thoroughly before starting any proposals — the quality of the entire process depends on deep understanding of the code

Step 0.5: Prepare Isolated Execution

Before Proposal A starts, define the isolation method in writing inside the proposal directory:

• What tool/session mechanism is being used for Agent A
• What tool/session mechanism is being used for Agent B
• How you are preventing shared context between them
• How A-feedback and B-feedback will be isolated later

Save this as execution-method.md.

Accepted approaches:

• Separate worker sessions managed by an external dispatcher
• Separate codex exec or equivalent runs that do not share prior outputs in context
• Separate human-run agent sessions where each agent only receives the allowed inputs

Rejected approaches:

• "Mental reset" in the same conversation
• "Treat Proposal B as independent" after Proposal A was already written in the same session
• Any single-session workflow where both proposals are generated by the same live context

Step 1: Proposal A — The Surgical Perspective

Read agents/proposer-alpha.md for the full mindset.

Inputs allowed for Agent A:

• problem-statement.md
• Relevant source files
• Referenced skill files

Inputs forbidden for Agent A:

• proposal-B.md
• Any notes summarizing Proposal B
• Any synthesis notes

Investigate the problem with this lens:

• What is the most direct root cause?
• What is the smallest, lowest-risk fix?
• Trace the exact code path from input to broken output
• Occam's razor — prefer simple explanations

Write the proposal following the format in references/proposal-format.md. Save as proposal-A.md.

Step 2: Proposal B — The Systemic Perspective

Read agents/proposer-beta.md for the full mindset.

Proposal B must be executed in a different isolated session from Proposal A.

Inputs allowed for Agent B:

• problem-statement.md
• Relevant source files
• Referenced skill files

Inputs forbidden for Agent B:

• proposal-A.md
• Any notes summarizing Proposal A
• Any synthesis notes

CRITICAL: Approach the problem fresh. Do NOT simply extend, react to, or refine Proposal A. Investigate from scratch with a different lens:

• Is this a symptom of a deeper architectural issue?
• What would prevent this entire class of bugs?
• Where are the missing validations, contracts, or guarantees?
• Are there other places where the same pattern breaks?

Write the proposal following the format in references/proposal-format.md. Save as proposal-B.md.

The value of this framework comes from genuinely different analytical perspectives. If B just agrees with A and adds minor points, the process has failed. B should investigate independently and may arrive at a completely different root cause.

Step 3: Proposal C — Synthesis

Read agents/synthesizer.md for the full role.

Proposal C may read both proposal-A.md and proposal-B.md, but it must not rewrite history by pretending A and B were isolated if they were not. If isolation was not achieved, abort instead of synthesizing.

Now review both proposals:

1. Analyze each proposal — do a strict review to see if each is sound or missing anything
2. State specifically what you disagree with in each
3. Identify where they agree (high-confidence areas) and where they diverge (needs resolution)
4. Produce a new proposal that lists the analysis of both proposals first, then the best path forward
5. Attribute key decisions: what came from A, what from B, what's new in C

Save as proposal-C.md.

Step 4: Feedback — A and B Critique C

Read agents/critic.md for the feedback approach.

Now run two isolated critique passes:

• A-feedback session can read proposal-A.md and proposal-C.md, but not proposal-B.md
• B-feedback session can read proposal-B.md and proposal-C.md, but not proposal-A.md

Do not critique C from both perspectives inside one shared-context session if you can avoid it. The critique round should preserve the original separation.

From A's perspective (surgical/minimal lens):

• What did C lose from A's focused approach?
• Did scope creep in? Are there unnecessary changes?
• Does C introduce risks that A's simpler approach avoided?
• Where is C's proposal stronger than A's?

From B's perspective (systemic/holistic lens):

• Did C take the quick fix over the right fix?
• Are there still systemic vulnerabilities C ignores?
• Did C incorporate the structural improvements from B?
• Where is C's proposal stronger than B's?

Do not save separate feedback files — carry the feedback directly into the next step.

Step 5: Final Plan — Reconciliation

Read agents/reconciler.md for the reconciliation approach.

Take C's proposal and the feedback from both perspectives:

1. Review each piece of feedback honestly
2. Incorporate what's valid — if A or B caught a real issue, fix it
3. Reject what's not applicable, with clear reasoning
4. Produce the final implementation plan

Save as final-plan.md.

The final plan must include:

• Problem statement (refined through the full deliberation)
• Root cause (final determination with confidence level)
• Implementation plan (step-by-step, in execution order, with specific files and changes)
• Feedback reconciliation (what was accepted/rejected from A and B feedback, and why)
• Risks and mitigations
• Testing strategy

Step 6: Present to User

Present the final plan. Offer to:

• Show the full deliberation trail
• Explain specific decisions
• Proceed to implementation
• Re-run any round with a different angle

Isolation Validation Checklist

Before claiming the skill was followed correctly, confirm all of the following:

• Proposal A and Proposal B were authored in separate agent contexts
• Proposal B did not read Proposal A before completion
• A-feedback did not read Proposal B
• B-feedback did not read Proposal A
• execution-method.md documents the isolation method used
• If any item above is false, you did not execute this skill correctly

If you cannot satisfy this checklist, say so explicitly and stop.

Adapting to Problem Type

Problem Type	Proposal A Emphasis	Proposal B Emphasis
Bug fix	Trace exact data flow breakpoint	Find missing validation/contract
Feature	Minimal viable implementation	Full design with extensibility
Architecture	Incremental migration path	Clean-slate ideal design
Refactoring	Targeted surgical changes	Structural pattern improvement

Output Directory

{project}/.dev/proposals/{issue-slug}/
├── problem-statement.md
├── proposal-A.md
├── proposal-B.md
├── proposal-C.md
└── final-plan.md

Agent Roles Reference

Read these files for full role instructions when executing each round:

Agent	File	Used In	Lens
Proposer Alpha	agents/proposer-alpha.md	Round 1 (A)	Surgical, minimal, trace-the-exact-bug
Proposer Beta	agents/proposer-beta.md	Round 2 (B)	Systemic, holistic, prevent-the-bug-class
Synthesizer	agents/synthesizer.md	Round 3 (C)	Impartial reviewer, best-of-both
Critic	agents/critic.md	Round 4	Pressure-test C from both perspectives
Reconciler	agents/reconciler.md	Round 5	Make final calls, produce actionable plan