Back to Details

debate-workflow

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Debate Workflow Skill

辩论工作流Skill

Purpose

目标

Implement structured multi-perspective debate for important architectural decisions, design trade-offs, and complex problems where multiple valid approaches exist.
针对存在多种可行方案的重要架构决策、设计权衡以及复杂问题，实现结构化多视角辩论。

When to Use This Skill

何时使用该Skill

USE FOR:
  • Major architectural decisions (framework selection, system design)
  • Complex trade-offs with no clear winner
  • Controversial changes affecting multiple teams
  • High-impact decisions requiring buy-in
  • When perspectives genuinely conflict
AVOID FOR:
  • Simple implementation choices
  • Decisions with obvious correct answer
  • Time-sensitive hot fixes
  • Minor refactoring
  • Routine feature additions
适用场景：
  • 重大架构决策（框架选型、系统设计）
  • 无明确最优解的复杂权衡
  • 影响多团队的争议性变更
  • 需要多方认可的高影响力决策
  • 存在真实观点冲突的场景
避免场景：
  • 简单的实现选择
  • 有明确正确答案的决策
  • 时间敏感的紧急修复
  • 小型重构
  • 常规功能新增

Configuration

配置

Core Parameters

核心参数

Number of Perspectives:
  • 3
    - Default (security, performance, simplicity)
  • 5
    - Extended (add: maintainability, user-experience)
  • 7
    - Comprehensive (add: scalability, cost)
Debate Rounds:
  • 2
    - Quick (position + challenge)
  • 3
    - Standard (position + challenge + synthesis)
  • 4-5
    - Deep (multiple challenge/response cycles)
Convergence Criteria:
  • 100%
    - Strong consensus (all perspectives agree)
  • 2/3
    - Majority rule (two-thirds agreement)
  • synthesis
    - Facilitator synthesizes best hybrid
  • evidence
    - Follow strongest evidence/arguments
视角数量：
  • 3
    - 默认值（安全、性能、简洁性）
  • 5
    - 扩展版（新增：可维护性、用户体验）
  • 7
    - 完整版（新增：可扩展性、成本）
辩论轮次：
  • 2
    - 快速版（立场陈述 + 质疑）
  • 3
    - 标准版（立场陈述 + 质疑 + 综合）
  • 4-5
    - 深度版（多轮质疑/回应循环）
收敛标准：
  • 100%
    - 强共识（所有视角达成一致）
  • 2/3
    - 多数决（三分之二达成一致）
  • synthesis
    - 综合法（协调者整合最优混合方案）
  • evidence
    - 证据导向（遵循最有力的证据/论点）

Standard Perspective Profiles

标准视角配置文件

Security Perspective:
  • Focus: Vulnerabilities, attack vectors, data protection
  • Questions: "What could go wrong? How do we prevent breaches?"
  • Agent: security agent
Performance Perspective:
  • Focus: Speed, scalability, resource efficiency
  • Questions: "Will this scale? What are the bottlenecks?"
  • Agent: optimizer agent
Simplicity Perspective:
  • Focus: Minimal complexity, ruthless simplification
  • Questions: "Is this the simplest solution? Can we remove abstractions?"
  • Agent: cleanup agent + reviewer agent
Maintainability Perspective:
  • Focus: Long-term evolution, technical debt
  • Questions: "Can future developers understand this? How hard to change?"
  • Agent: reviewer agent + architect agent
User Experience Perspective:
  • Focus: API design, usability, developer experience
  • Questions: "Is this intuitive? How will users interact with this?"
  • Agent: api-designer agent
Scalability Perspective:
  • Focus: Growth capacity, distributed systems
  • Questions: "What happens at 10x load? 100x?"
  • Agent: optimizer agent + architect agent
Cost Perspective:
  • Focus: Resource usage, infrastructure costs, development time
  • Questions: "What's the ROI? Are we over-engineering?"
  • Agent: analyzer agent
安全视角：
  • 核心关注：漏洞、攻击向量、数据保护
  • 核心问题："可能出现哪些问题？我们如何防范入侵？"
  • 对应Agent: security agent
性能视角：
  • 核心关注：速度、可扩展性、资源效率
  • 核心问题："该方案能否横向扩展？瓶颈在哪里？"
  • 对应Agent: optimizer agent
简洁性视角：
  • 核心关注：最小化复杂度、极致简化
  • 核心问题："这是最简单的解决方案吗？我们能否移除不必要的抽象？"
  • 对应Agent: cleanup agent + reviewer agent
可维护性视角：
  • 核心关注：长期演进、技术债务
  • 核心问题："未来的开发者能否理解该方案？修改难度有多大？"
  • 对应Agent: reviewer agent + architect agent
用户体验视角：
  • 核心关注：API设计、易用性、开发者体验（DX）
  • 核心问题："该方案是否直观？用户将如何与之交互？"
  • 对应Agent: api-designer agent
可扩展性视角：
  • 核心关注：增长能力、分布式系统
  • 核心问题："当负载达到10倍、100倍时会发生什么？"
  • 对应Agent: optimizer agent + architect agent
成本视角：
  • 核心关注：资源使用、基础设施成本、开发时间
  • 核心问题："投资回报率（ROI）如何？我们是否过度设计了？"
  • 对应Agent: analyzer agent

Execution Process

执行流程

Step 1: Frame the Decision

步骤1：构建决策框架

  • Use ambiguity agent to clarify the decision to be made
  • Use prompt-writer agent to create clear decision prompt
  • Define decision scope and constraints
  • Identify stakeholder concerns
  • List evaluation criteria
  • Document explicit user requirements that constrain options
  • CRITICAL: Frame decision as question, not predetermined answer
Decision Framing Template:
markdown
undefined
  • 使用ambiguity agent明确待决策的问题
  • 使用prompt-writer agent创建清晰的决策提示语
  • 定义决策范围与约束条件
  • 识别利益相关方的关注点
  • 列出评估标准
  • 记录限制选项的明确用户需求
  • 关键：将决策表述为问题，而非预设答案
决策框架模板：
markdown
undefined

Decision: [Brief Title]

决策：[简短标题]

Question

问题

[One-sentence question to be debated]
[用于辩论的单句问题]

Context

背景

[Why this decision matters, background information]
[该决策的重要性、背景信息]

Constraints

约束条件

[Non-negotiable requirements, technical limitations]
[不可协商的需求、技术限制]

Evaluation Criteria

评估标准

[How we'll judge proposed solutions]
[我们判断候选方案的依据]

Perspectives to Include

纳入的视角

[Which viewpoints are most relevant]

**Example:**

```markdown
[最相关的视角]

**示例：**

```markdown

Decision: Data Storage Strategy for User Analytics

决策：用户分析数据存储策略

Question

问题

Should we use PostgreSQL with JSONB, MongoDB, or ClickHouse for storing and querying user analytics events?
我们应该使用PostgreSQL with JSONB、MongoDB还是ClickHouse来存储和查询用户分析事件？

Context

背景

  • 10M events/day expected at launch
  • 100M events/day within 2 years
  • Complex queries for dashboard analytics
  • Real-time and historical reporting needed
  • 上线时预计每天1000万条事件
  • 2年内预计每天1亿条事件
  • 用于仪表板分析的复杂查询
  • 需要实时和历史报告

Constraints

约束条件

  • Must handle 10M events/day minimum
  • Query latency < 200ms for dashboards
  • Budget: $5K/month infrastructure
  • Team familiar with PostgreSQL, not ClickHouse
  • 必须支持至少每天1000万条事件
  • 仪表板查询延迟<200ms
  • 预算：每月5000美元基础设施成本
  • 团队熟悉PostgreSQL，不熟悉ClickHouse

Evaluation Criteria

评估标准

  1. Performance at scale
  2. Query flexibility
  3. Operational complexity
  4. Cost at scale
  5. Team learning curve
  1. 规模化性能
  2. 查询灵活性
  3. 运维复杂度
  4. 规模化成本
  5. 团队学习曲线

Perspectives to Include

纳入的视角

Performance, Cost, Maintainability, Scalability
undefined
性能、成本、可维护性、可扩展性
undefined

Step 2: Initialize Perspectives

步骤2：初始化视角

  • Select N perspectives relevant to decision
  • Spawn Claude subprocess for each perspective
  • Each subprocess receives decision framing doc
  • Each subprocess assigned perspective profile
  • No context sharing between perspectives yet
  • Each forms initial position independently
Initial Position Requirements:
  • State recommended approach
  • Provide 3-5 supporting arguments
  • Identify risks of alternative approaches
  • Quantify claims where possible
  • 选择与决策相关的N个视角
  • 为每个视角启动Claude子进程
  • 每个子进程接收决策框架文档
  • 为每个子进程分配视角配置文件
  • 视角之间暂不共享上下文
  • 每个视角独立形成初始立场
初始立场要求：
  • 陈述推荐方案
  • 提供3-5条支持论点
  • 识别替代方案的风险
  • 尽可能量化主张

Step 3: Debate Round 1 - Initial Positions

步骤3：辩论第一轮 - 初始立场

  • Collect initial positions from all perspectives
  • Use analyzer agent to synthesize positions
  • Document each perspective's recommendation
  • Identify areas of agreement
  • Identify areas of conflict
  • Surface assumptions made by each perspective
Round 1 Output Structure:
markdown
undefined
  • 收集所有视角的初始立场
  • 使用analyzer agent整合立场
  • 记录每个视角的推荐方案
  • 识别共识领域
  • 识别冲突领域
  • 梳理每个视角的假设前提
第一轮输出结构：
markdown
undefined

Security Perspective: [Recommendation]

安全视角：[推荐方案]

Arguments For:
  1. [Argument with evidence]
  2. [Argument with evidence]
  3. [Argument with evidence]
Concerns About Alternatives:
  • [Alternative A]: [Specific concern]
  • [Alternative B]: [Specific concern]
Assumptions:
  • [Assumption 1]
  • [Assumption 2]
undefined
支持论点：
  1. [带证据的论点]
  2. [带证据的论点]
  3. [带证据的论点]
对替代方案的担忧：
  • [替代方案A]：[具体担忧]
  • [替代方案B]：[具体担忧]
假设前提：
  • [假设1]
  • [假设2]
undefined

Step 4: Debate Round 2 - Challenge and Respond

步骤4：辩论第二轮 - 质疑与回应

  • Share all Round 1 positions with all perspectives
  • Each perspective challenges other perspectives' arguments
  • Each perspective defends their position against challenges
  • Use analyzer agent to track argument strength
  • Identify which arguments withstand scrutiny
  • Document concessions and refinements
Challenge Format:
markdown
undefined
  • 向所有视角共享第一轮的所有立场
  • 每个视角质疑其他视角的论点
  • 每个视角针对质疑为自身立场辩护
  • 使用analyzer agent追踪论点强度
  • 识别经得住推敲的论点
  • 记录让步与立场修正
质疑格式：
markdown
undefined

[Perspective A] challenges [Perspective B]

[视角A] 质疑 [视角B]

Challenge: [Question or counter-argument] Evidence: [Supporting data or examples] Request: [What would change your position?]

**Response Format:**

```markdown
质疑：[问题或反论点] 证据：[支持数据或示例] 要求：[什么会改变你的立场？]

**回应格式：**

```markdown

[Perspective B] responds to [Perspective A]

[视角B] 回应 [视角A]

Response: [Address the challenge] Concession: [Points where you agree or adjust] Counter: [Additional evidence or reasoning]
undefined
回应：[针对质疑的答复] 让步：[你同意或调整的观点] 反驳：[补充证据或推理]
undefined

Step 5: Debate Round 3 - Find Common Ground

步骤5：辩论第三轮 - 寻找共识

  • Identify points of consensus across perspectives
  • Surface remaining disagreements explicitly
  • Explore hybrid approaches combining insights
  • Use architect agent to design synthesis options
  • Validate hybrid approaches against all perspectives
  • Document convergence or divergence
Convergence Analysis:
markdown
undefined
  • 识别所有视角的共识点
  • 明确剩余的分歧
  • 探索整合各方见解的混合方案
  • 使用architect agent设计综合选项
  • 验证混合方案是否符合所有视角的要求
  • 记录收敛或分歧情况
收敛分析结构：
markdown
undefined

Areas of Agreement

共识领域

  1. [Consensus point 1]
  2. [Consensus point 2]
  1. [共识点1]
  2. [共识点2]

Remaining Disagreements

剩余分歧

  1. [Disagreement 1]
    • Security says: [position]
    • Performance says: [position]
    • Potential resolution: [hybrid approach]
  1. [分歧点1]
    • 安全视角认为：[立场]
    • 性能视角认为：[立场]
    • 潜在解决方案：[混合方案]

Hybrid Approaches Identified

识别的混合方案

  1. [Hybrid Option 1]
    • Combines: [which perspectives]
    • Trade-offs: [explicit costs/benefits]
undefined
  1. [混合方案1]
    • 整合了：[哪些视角的见解]
    • 权衡：[明确的成本/收益]
undefined

Step 6: Facilitator Synthesis

步骤6：协调者综合

  • Use architect agent as neutral facilitator
  • Use analyzer agent to evaluate all arguments
  • Review all debate rounds systematically
  • Identify strongest evidence-based arguments
  • Make recommendation with confidence level
  • Document decision rationale thoroughly
  • Include dissenting views explicitly
Synthesis Structure:
markdown
undefined
  • 使用architect agent作为中立协调者
  • 使用analyzer agent评估所有论点
  • 系统回顾所有辩论轮次
  • 识别最具证据支撑的论点
  • 给出带置信度的推荐方案
  • 详细记录决策理由
  • 明确记录反对意见
综合报告结构：
markdown
undefined

Facilitator Synthesis

协调者综合报告

Recommendation

推荐方案

[Clear statement of recommended approach]
[清晰的推荐方案陈述]

Confidence Level

置信度

[High/Medium/Low] confidence based on:
  • Consensus level: [X% of perspectives agree]
  • Evidence quality: [Strong/Moderate/Weak]
  • Risk level: [Low/Medium/High if wrong]
[高/中/低] 置信度，依据：
  • 共识程度：[X%的视角达成一致]
  • 证据质量：[强/中/弱]
  • 风险等级：[若决策错误，风险为低/中/高]

Rationale

理由

[Explanation of why this recommendation]
[该推荐方案的原因]

Key Arguments That Won

关键胜出论点

  1. [Argument that swayed decision]
  2. [Argument that swayed decision]
  3. [Argument that swayed decision]
  1. [影响决策的论点]
  2. [影响决策的论点]
  3. [影响决策的论点]

Key Arguments Against (Dissenting Views)

主要反对论点（不同意见）

  1. [Strongest counter-argument]
  2. [Remaining concern]
  1. [最有力的反论点]
  2. [剩余担忧]

Implementation Guidance

实施指导

[How to execute this decision]
[如何执行该决策]

Success Metrics

成功指标

[How we'll know if this was the right choice]
[如何判断该决策是否正确]

Revisit Triggers

重审触发条件

[Conditions that would require reconsidering this decision]
undefined
[需要重新审视该决策的条件]
undefined

Step 7: Decision Documentation

步骤7：决策文档化

  • Create decision record: 
    decisions/YYYY-MM-DD-decision-name.md
  • Document full debate transcript
  • Include all perspective arguments
  • Record synthesis and final decision
  • Store in memory using 
    store_discovery()
    from 
    amplihack.memory.discoveries
  • Update relevant architecture docs
Decision Record Template:
markdown
undefined
  • 创建决策记录：
    decisions/YYYY-MM-DD-decision-name.md
  • 记录完整的辩论 transcript
  • 包含所有视角的论点
  • 记录综合报告与最终决策
  • 使用
    amplihack.memory.discoveries
    中的
    store_discovery()
    存储到内存
  • 更新相关架构文档
决策记录模板：
markdown
undefined

Decision Record: [Title]

决策记录：[标题]

Date: [YYYY-MM-DD] Status: Accepted Decision Makers: [List perspectives included]
日期：[YYYY-MM-DD] 状态：已接受 决策者：[纳入的视角列表]

Context

背景

[What decision was needed and why]
[需要做出该决策的原因]

Decision

决策

[What was decided]
[最终决定]

Consequences

影响

[What happens because of this decision]
[该决策带来的结果]

Alternatives Considered

考虑的替代方案

[What other options were debated]
[辩论过的其他选项]

Debate Summary

辩论摘要

[Key arguments from each perspective]
[每个视角的关键论点]

Dissenting Opinions

不同意见

[Perspectives that disagreed and why]
[持反对意见的视角及原因]

Review Date

重审日期

[When to revisit this decision]
[重新审视该决策的时间]

Full Debate Transcript

完整辩论记录

Round 1: Initial Positions

第一轮：初始立场

[Complete positions from all perspectives]
[所有视角的完整立场]

Round 2: Challenges and Responses

第二轮：质疑与回应

[All challenge/response exchanges]
[所有质疑/回应内容]

Round 3: Convergence Analysis

第三轮：收敛分析

[Common ground and hybrid approaches]
[共识点与混合方案]

Facilitator Synthesis

协调者综合报告

[Complete synthesis document]
undefined
[完整的综合文档]
undefined

Step 8: Implement Decision

步骤8：执行决策

  • Use builder agent to implement chosen approach
  • Follow the decided path from synthesis
  • Implement monitoring for success metrics
  • Set up alerts for revisit triggers
  • Document decision in code comments
  • Create runbook if operational complexity added
  • 使用builder agent实施选定方案
  • 遵循综合报告中的决策路径
  • 实施成功指标的监控
  • 设置重审触发条件的告警
  • 在代码注释中记录决策
  • 若增加了运维复杂度，创建运行手册

Trade-Offs

权衡

Cost: Multiple agent cycles, longer decision time Benefit: Well-reasoned decisions, surface hidden risks Best For: Decisions that are expensive to reverse
成本： 多轮Agent循环，决策时间更长 收益： 决策更具合理性，暴露隐藏风险 最佳适用场景： 难以逆转的决策

Examples

示例

Example 1: API Design - REST vs GraphQL

示例1：API设计 - REST vs GraphQL

Configuration:
  • Perspectives: 5 (Simplicity, Performance, User-Experience, Maintainability, Cost)
  • Rounds: 3
  • Convergence: Synthesis
Debate Summary:
  • Simplicity: REST is straightforward, well-understood
  • Performance: GraphQL reduces over-fetching, fewer round trips
  • UX: GraphQL gives frontend flexibility, better DX
  • Maintainability: REST easier to version and evolve
  • Cost: GraphQL higher learning curve, more complex infrastructure
Result: REST for initial MVP, GraphQL for v2
  • Rationale: Team knows REST, faster to ship
  • Migration path: Add GraphQL layer in 6 months
  • Trigger: When frontend requests 3+ endpoints per view
配置：
  • 视角：5个（简洁性、性能、用户体验、可维护性、成本）
  • 轮次：3轮
  • 收敛方式：综合法
辩论摘要：
  • 简洁性：REST简单直接，易于理解
  • 性能：GraphQL减少过度获取，降低往返次数
  • 用户体验：GraphQL为前端提供灵活性，提升DX
  • 可维护性：REST更易于版本化与演进
  • 成本：GraphQL学习曲线更高，基础设施更复杂
结果： 初始MVP使用REST，v2版本迁移到GraphQL
  • 理由：团队熟悉REST，上线速度更快
  • 迁移路径：6个月内添加GraphQL层
  • 触发条件：当前端每个视图需要调用3个以上接口时

Example 2: Testing Strategy - Unit vs Integration Heavy

示例2：测试策略 - 单元测试 vs 集成测试

Configuration:
  • Perspectives: 3 (Simplicity, Maintainability, Performance)
  • Rounds: 2
  • Convergence: 2/3 majority
Debate Summary:
  • Simplicity: Unit tests, mock all dependencies
  • Maintainability: Integration tests, test real interactions
  • Performance: Mix, optimize for feedback speed
Result: 70% unit, 30% integration (Majority agreed)
  • Rationale: Unit tests faster feedback, integration tests catch real issues
  • Dissent: Simplicity wanted 90% unit tests (overruled by maintainability concerns)
配置：
  • 视角：3个（简洁性、可维护性、性能）
  • 轮次：2轮
  • 收敛方式：2/3多数决
辩论摘要：
  • 简洁性：单元测试，模拟所有依赖
  • 可维护性：集成测试，测试真实交互
  • 性能：混合策略，优化反馈速度
结果： 70%单元测试，30%集成测试（多数同意）
  • 理由：单元测试反馈速度快，集成测试能发现真实问题
  • 不同意见：简洁性视角希望90%为单元测试（因可维护性担忧被否决）

Example 3: Deployment Strategy - Kubernetes vs Serverless

示例3：部署策略 - Kubernetes vs Serverless

Configuration:
  • Perspectives: 5 (Cost, Simplicity, Scalability, Performance, Maintainability)
  • Rounds: 4
  • Convergence: Synthesis (no majority)
Debate Summary:
  • Long, contentious debate with no clear winner
  • Cost and Simplicity favored serverless
  • Scalability and Performance favored Kubernetes
  • Maintainability split (serverless simpler, k8s more control)
Result: Serverless with k8s option researched
  • Rationale: Start simple, team small, serverless faster
  • Hybrid: Evaluate k8s at 10x scale or complex networking needs
  • Strong dissent documented: Performance perspective believes this will need revisiting soon
配置：
  • 视角：5个（成本、简洁性、可扩展性、性能、可维护性）
  • 轮次：4轮
  • 收敛方式：综合法（无多数共识）
辩论摘要：
  • 长期激烈辩论，无明确胜出者
  • 成本与简洁性视角倾向Serverless
  • 可扩展性与性能视角倾向Kubernetes
  • 可维护性视角分歧（Serverless更简单，Kubernetes控制度更高）
结果： 先使用Serverless，同时研究Kubernetes选项
  • 理由：从简单方案开始，团队规模小，Serverless上线更快
  • 混合策略：当负载达到10倍或需要复杂网络时评估Kubernetes
  • 明确记录不同意见：性能视角认为该决策很快需要重审

Philosophy Alignment

理念契合

This workflow enforces:
  • Perspective Diversity: Multiple viewpoints surface hidden trade-offs
  • Evidence-Based: Arguments must be supported, not just opinions
  • Transparent Trade-offs: Dissent is documented, not hidden
  • Structured Exploration: Debate format prevents premature convergence
  • Decision Quality: Better decisions through rigorous analysis
  • Learning: Debate transcripts become organizational knowledge
该工作流强化：
  • 视角多样性： 多视角暴露隐藏的权衡
  • 证据导向： 论点必须有支撑，而非仅观点
  • 透明权衡： 记录不同意见，而非隐藏
  • 结构化探索： 辩论格式避免过早收敛
  • 决策质量： 通过严谨分析提升决策质量
  • 知识沉淀： 辩论记录成为组织知识

Integration with Default Workflow

与默认工作流的集成

This workflow replaces Step 4 (Research and Design) of the DEFAULT_WORKFLOW when complex decisions require multi-perspective analysis. Implementation (Step 5) proceeds with the consensus decision.
当复杂决策需要多视角分析时，该工作流将替换默认工作流的步骤4（研究与设计）。实施阶段（步骤5）将遵循共识决策推进。