design-debate

name	design-debate
description	Use when a design direction is uncertain, when the team could go multiple ways, or when the user wants to see competing approaches argued before committing — orchestrates structured debate between agents who advocate for different directions

Design Debate

Good design decisions come from tension, not consensus. When agents converge too quickly, they optimise for agreement instead of the best answer. This skill creates productive conflict — agents argue for competing directions with real trade-offs, and the user decides.

When to Use

• When the design-strategist identifies multiple viable directions
• When the design-lead proposes a visual direction and alternatives exist
• When the user says "I'm not sure which way to go" or "what are my options?"
• When the design-critic recommends "rethink" — a debate can surface the better path
• When a decision has significant downstream consequences (navigation pattern, layout model, interaction paradigm)
• When the user explicitly asks for a debate: "debate this", "argue both sides", "what are the trade-offs?"

Do Not Use When

• The decision is trivial (icon choice, exact padding value)
• Accessibility requirements dictate the answer — there is nothing to debate
• The user has already made up their mind — respect their direction
• The brief clearly specifies the approach — follow it

Process

Step 1: Frame the Question

Define the design question precisely. A debate without a clear question produces noise.

Format:

DESIGN QUESTION: [Specific, answerable question]
CONTEXT: [Brief context from design-state.md]
CONSTRAINTS: [Non-negotiable requirements from brief, accessibility, taste profile]
STAKES: [Why this decision matters — what it affects downstream]

Example:

DESIGN QUESTION: Should the onboarding flow use a multi-step wizard or a single scrollable page?
CONTEXT: App for first-time pet owners, ages 25-45. Primary persona has mild anxiety about "doing it right."
CONSTRAINTS: Must be completable in under 3 minutes. Must work on mobile. Must not require account creation upfront.
STAKES: Sets the interaction pattern for all future multi-step flows in the app.

Step 2: Assign Advocates

Select 2-3 agents to argue for different directions. Each agent argues FOR their assigned position — they are advocates, not neutral analysts.

Role	What They Argue
Advocate A	The case for Direction A — strengths, evidence, personas it serves best
Advocate B	The case for Direction B — strengths, evidence, personas it serves best
Advocate C (optional)	A third direction, a hybrid, or a "neither — here's why" position

Assign agents based on their expertise:

Agent	Best suited to advocate for
design-strategist	UX patterns, information architecture, user flow approaches
design-lead	Visual directions, layout models, component architecture
content-writer	Content strategy approaches, tone directions, naming conventions
motion-designer	Interaction paradigms, feedback models, transition approaches
accessibility-reviewer	The most inclusive option, cognitive load implications
design-scout	Evidence-backed positions from competitive research

Step 3: Run the Debate

Each advocate delivers their argument in this format:

## [Agent Name] argues for: [Direction]

### The Case
[2-3 paragraphs making the strongest possible argument for this direction.
Be specific — reference the brief, personas, principles, and evidence.]

### Who This Serves Best
[Which personas benefit most and why]

### Who This Serves Least
[Which personas might struggle and why — be honest]

### Trade-Offs
[What you give up by choosing this direction]

### Evidence
[Research, patterns, competitive examples, or design principles that support this]

Rules for advocates:

1. Argue to win — make the strongest case you can. Do not hedge
2. Be honest about weaknesses — a strong argument acknowledges its trade-offs
3. Reference the brief — ground arguments in the project's actual goals
4. Reference personas — every argument must address who it helps and who it doesn't
5. No straw men — do not weaken the opposing position to make yours look better

Step 4: Cross-Examination

After all advocates present, each gets one round of rebuttal:

### [Agent Name] responds to [Other Agent]:
[1-2 paragraphs directly addressing the strongest point of the opposing argument.
Concede what is true. Challenge what is weak.]

This prevents echo-chamber advocacy — each agent must engage with the other side's best arguments.

Step 5: Accessibility Check

Before presenting to the user, the accessibility-reviewer evaluates all proposed directions:

## Accessibility Assessment

| Direction | Accessibility Impact | Concern Level |
|-----------|---------------------|---------------|
| Direction A | [Assessment] | Low / Medium / High |
| Direction B | [Assessment] | Low / Medium / High |

[If any direction creates accessibility barriers, flag it clearly.
This is not an argument for a direction — it is a constraint check.]

If a direction has High accessibility concern, it should be flagged prominently in the presentation to the user. The user can still choose it, but they should know the cost.

Step 6: Present to User

Show the debate to the user in a structured format:

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  DESIGN DEBATE
  Question: [The design question]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  DIRECTION A: [Name]
  Argued by: [agent]
  [2-3 sentence summary of the case]
  Best for: [personas]
  Trade-off: [key trade-off]

  DIRECTION B: [Name]
  Argued by: [agent]
  [2-3 sentence summary of the case]
  Best for: [personas]
  Trade-off: [key trade-off]

  [DIRECTION C if applicable]

  ACCESSIBILITY: [One-line summary of any concerns]

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
  YOUR CALL: Which direction do you want to take?
  (You can also ask for more detail on any direction,
   or propose a hybrid.)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Step 7: Record the Decision

After the user decides:

1. Record the chosen direction in design-state.md Decisions Log with rationale
2. Record the rejected directions and why — this is valuable context for future debates
3. If the decision reveals a taste preference, update design-memory
4. Dispatch the appropriate agent to execute the chosen direction

Debate Depth

Not every debate needs the full process. Scale the depth to the stakes:

Stakes	Debate Format
High (sets architectural pattern)	Full debate: 2-3 advocates, cross-examination, accessibility review
Medium (affects multiple screens)	Quick debate: 2 advocates, no cross-examination, accessibility flag
Low (affects one component)	Micro debate: 2 options presented as a simple comparison table, user picks

Integration

• Called by: design-strategy, using-designpowers (when user requests debate), designpowers-critique (when "rethink" is recommended)
• Calls: Any agent as advocate, accessibility-reviewer for constraint check
• Updates: design-state with decision and rejected alternatives
• Informs: design-memory with taste signals from the user's choice
• Pairs with: design-strategy, design-memory, taste-feedback

Anti-Patterns

Pattern	Why It Fails
Debating after the user has decided	Wastes time. If the user has a direction, execute it
Debating trivial decisions	8px vs 12px padding is not a debate — it's a design system decision
Agents being polite instead of advocating	"Both options are great!" is not a debate. Agents must argue to win
Presenting a debate without accessibility review	Every direction must be evaluated for inclusion before the user chooses
Running a debate in auto mode without pausing	Debates ALWAYS pause for user decision — they are inherently direct-mode moments
More than 3 directions	Too many options cause decision paralysis. If there are more than 3, narrow down first