design-debate

Design Debate

Decide whether to do something — before writing a plan for it — by making independent subagents genuinely disagree, not politely converge. The value isn't in getting three opinions; it's in the friction between them, and in a final verdict that says which argument actually held up.

Prerequisites

• A concrete decision or idea to debate, not yet written as a plan file (if it already is, use plan-review instead)
• Enough repo/codebase access to gather real facts before the debate starts
• The context-file skill, to persist the verdict as a finding
• The plan-create skill, as the next step if the verdict is "proceed"

When to Use

• "Should we split/merge/replace X?" — a decision with real tradeoffs on more than one side
• The user explicitly asks for pushback, a second opinion, or a collegial review
• A decision surfaced from real pain and it's unclear whether the fix is worth its cost

When NOT to Use

• A plan file already exists for this work — use plan-review
• The question needs narrowing before it's even debatable — use socratic-method first
• There's only one reasonable answer — AVOID manufacturing debate where none is warranted

Workflow

1. State the decision precisely

Write it as a yes/no or A-vs-B choice, not a vague topic.

2. Ground the debate in real facts BEFORE assigning positions

UNLESS you already have hard numbers, ALWAYS investigate first: current scale, who consumes the thing in question, what a proposed change would actually touch.

wc -l path/to/thing/in/question
grep -rl "the/consumer/pattern" . | wc -l

This confirms the actual size and blast radius before anyone argues about it — an ungrounded debate produces confident conclusions built on guessed facts.

3. Compose one identical brief for every reviewer

Every reviewer gets the same decision, the same grounding facts, and any candidate designs already on the table — differences in conclusions must come from role, not information.