| name | debate |
| description | Structured multi-perspective debate for evaluating decisions. 3-phase methodology: independent generation, adversarial exchange, synthesis. Use when a decision has multiple valid approaches or high stakes.
|
| disable-model-invocation | true |
| argument-hint | [decision or question] |
Purpose
Produce higher-quality decisions by evaluating them from multiple
independent perspectives that challenge each other's assumptions.
Research shows multi-perspective analysis mitigates anchoring bias,
confirmation bias, and groupthink while surfacing risks that
single-perspective analysis misses.
This is an interactive skill. Confirm framing and perspectives with the
user before starting, then present debate findings and rulings one at a
time for the user to accept, challenge, or override.
Instructions
0. Context recall (SeleneDB)
If SeleneDB is available (see selene-integration.md),
create a session and recall prior debate context:
-
Create session with skill: 'debate' and scope: $ARGUMENTS
-
Scoped auto-recall — query for prior debates on related topics:
- Prior
:Decision nodes (debate rulings) on similar topics
- Prior
:Perspective nodes that addressed the same domain
- Any
:Document {doc_type: 'debate'} on overlapping questions
-
If relevant prior debates exist, present them:
"Prior debate context:
- [Date]: Debated '[topic]' — ruled [summary of ruling]
- [Any residual disagreements from prior debates on this topic]
This prior analysis may inform the current debate."
Prior rulings and residual disagreements are especially valuable —
they prevent re-debating settled questions and surface unresolved tensions
that may still apply.
If no prior context exists, skip silently.
Setup
- If
$ARGUMENTS was provided, use it as the decision to evaluate
- Frame the decision clearly: what needs to be decided, what constraints
exist, what the stakes are
- Ask the user to confirm the framing before proceeding
Choose perspectives
Select 3-5 perspectives with explicitly different frames. Each must
optimize for something different. Tailor to the decision domain.
Common perspective sets:
| Domain | Perspectives |
|---|
| Technical architecture | Performance, Security, DX/Maintainability, Devil's Advocate |
| Strategic/product | Product, Engineering, Operations, Customer, Devil's Advocate |
| Build vs depend | In-house Advocate, Dependency Advocate, Risk Analyst, Devil's Advocate |
| Edge/cloud | Edge Advocate, Cloud Advocate, Integration Architect, Devil's Advocate |
Always include Devil's Advocate. This perspective must:
- Argue from a specific alternative frame (not just "disagree")
- Propose a concrete alternative, not just criticize
- Be bounded to 1-2 rounds of objection before synthesis
Ask the user to confirm or adjust perspectives before starting.
Phase 1: Independent generation
Each perspective generates its full argument independently before seeing
others. This prevents anchoring to the first position stated.
Each argument must use the Toulmin structure:
| Component | Purpose | Example |
|---|
| Claim | The position | "We should build HNSW in-house" |
| Grounds | Evidence | Benchmarks, complexity analysis, team capability |
| Warrant | Why the evidence supports the claim | "Full control over memory layout enables 2x search speed" |
| Qualifier | Degree of certainty | "Likely correct if team maintains 2+ Rust engineers" |
| Rebuttal | When this position is wrong | "Unless time-to-market matters more than performance" |
In team mode: spawn one teammate per perspective. Each generates
independently before any messaging.
In single-agent mode: generate each perspective sequentially,
maintaining clear separation. Do not let earlier perspectives influence
later ones.
Phase 2: Adversarial exchange (2-3 rounds)
Perspectives engage with each other's arguments. Each round has
decreasing contentiousness:
- Round 1 (high contentiousness): each perspective must identify the
strongest counterargument to their position and address it directly.
Must engage with the strongest opposing argument, not the weakest.
- Round 2 (medium): perspectives revise their positions based on
what they learned. Must explicitly state what (if anything) changed
their assessment and why.
- Round 3 (low, optional): final positions with explicit residual
disagreements. Only run if significant unresolved tensions remain.
Anti-conformity rule: a perspective that agrees with the majority
must provide substantive new reasoning, not just "I agree." Agreement
without new evidence is noise.
In team mode: teammates message each other directly to challenge
arguments. Lead monitors but does not intervene unless debate stalls.
In single-agent mode: for each round, revisit each perspective
with knowledge of others' arguments.
Phase 3: Synthesis
The moderator (lead or main agent) evaluates the full debate trajectory.
Score each perspective's final argument:
| Dimension | 1 (Weak) | 3 (Moderate) | 5 (Strong) |
|---|
| Evidence | Assertions only | Some data/examples | Concrete metrics, benchmarks |
| Relevance | Tangential | Related but indirect | Directly addresses decision criteria |
| Rebuttal quality | Ignores counterargs | Acknowledges opposition | Systematically addresses strongest counterargs |
| Reversibility | Ignores lock-in | Mentions switching cost | Quantifies commitment and exit paths |
| Confidence calibration | No uncertainty | Vague hedging | Explicit conditions for being wrong |
Bias check: before producing the final output, check for:
- Anchoring to the first perspective generated
- Sunk cost reasoning ("we've already invested in X")
- Groupthink (all perspectives converging without genuine tension)
- Optimism bias (underestimating effort or risk)
Produce the output document. See
debate-output-template.md for the format.
Graph write: synthesis (SeleneDB)
After synthesis is complete, write perspectives and the ruling:
For each perspective:
INSERT (p:Perspective {
role: $role_name,
priority_focus: $focus,
claim: $claim,
grounds: $grounds,
warrant: $warrant,
qualifier: $qualifier,
rebuttal: $rebuttal,
score: $score
})
RETURN id(p) AS persp_id
For the ruling:
INSERT (d:Decision {
summary: $ruling,
rationale: $deciding_factor,
alternatives: $residual_disagreements,
confidence: $confidence
})
RETURN id(d) AS ruling_id
Link everything to the debate document:
MATCH (doc:Document) WHERE id(doc) = $doc_id
MATCH (p:Perspective) WHERE id(p) = $persp_id
INSERT (doc)-[:argued_by]->(p)
MATCH (d:Decision) WHERE id(d) = $ruling_id
INSERT (doc)-[:ruled_as]->(d)
Residual disagreements stored in alternatives surface in future debates
on the same topic, seeding the adversarial exchange with known tensions.
Save and report
Save findings to _agentskills/debates/.
Name: YYYY-MM-DD-<topic>-debate.md.
Create the directory if it does not exist.
Present a summary: the decision, key arguments, and the ruling.
Supporting files
Red Flags
Stop and reassess if you observe:
- All perspectives converging without genuine tension (groupthink)
- Devil's Advocate only criticizing without proposing alternatives
- Anchoring to the first perspective generated
- Forcing consensus instead of documenting residual disagreements
Common Rationalizations
| Rationalization | Why It's Wrong |
|---|
| "Single perspective is enough" | One perspective finds one answer. You need three to find the right one. |
| "Skip exchange rounds, arguments are clear" | Arguments that seem clear haven't been challenged. Exchange reveals weaknesses. |
| "Force consensus, disagreements confuse" | Residual disagreements are signals, not noise. Report them honestly. |
| "Raw findings sufficient, skip synthesis" | Synthesis distills actionable recommendations. Findings without synthesis are just data. |
Verification
Guidance
3-5 perspectives, 3 rounds. Research consistently shows this is the
sweet spot. Beyond 5 perspectives, gains are marginal and token costs
increase substantially. Beyond 3 rounds, positions are established and
further exchange adds little.
Diversity of frame matters more than quantity. Three perspectives
with genuinely different optimization targets outperform five perspectives
that share similar reasoning frames.
The Devil's Advocate must propose alternatives, not just object.
Pure criticism without constructive alternatives causes analysis paralysis.
An effective Devil's Advocate says "here is a concrete failure mode, and
here is what we should do instead."
Residual disagreements are valuable. Do not force false consensus.
Documenting what remains unresolved and under what conditions to revisit
is more useful than a fabricated agreement.
SeleneDB prevents re-debating settled questions. Prior rulings surface
automatically when a similar decision comes up. Residual disagreements from
past debates seed the adversarial exchange, ensuring known tensions get
addressed rather than rediscovered.