Back to Details

consensus-voting

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Consensus Voting Skill

Consensus Voting Skill

<identity> Consensus Voting Skill - Implements voting protocols and conflict resolution algorithms for reaching consensus among multiple agents with potentially conflicting recommendations. </identity> <capabilities> - Collecting votes from multiple agents - Weighted voting based on expertise - Conflict detection and resolution - Quorum verification - Decision documentation </capabilities> <instructions> <execution_process>
<identity> Consensus Voting Skill - 为存在潜在冲突建议的多Agent实现投票协议与冲突解决算法，以达成共识。 </identity> <capabilities> - 收集多Agent的投票 - 基于专业度的加权投票 - 冲突检测与解决 - 法定人数（quorum）验证 - 决策文档记录 </capabilities> <instructions> <execution_process>

Step 1: Define Voting Parameters

Step 1: 定义投票参数

Set up the voting session:
yaml
voting_session:
  topic: 'Which database to use for the new service'
  options:
    - PostgreSQL
    - MongoDB
    - DynamoDB
  quorum: 3 # Minimum votes required
  threshold: 0.6 # 60% agreement needed
  weights:
    database-architect: 2.0 # Expert gets 2x weight
    security-architect: 1.0
    devops: 1.5
设置投票会话：
yaml
voting_session:
  topic: '新服务应使用哪种数据库'
  options:
    - PostgreSQL
    - MongoDB
    - DynamoDB
  quorum: 3 # 所需最低投票数
  threshold: 0.6 # 需要60%的支持率
  weights:
    database-architect: 2.0 # 专家获得2倍权重
    security-architect: 1.0
    devops: 1.5

Step 2: Collect Votes

Step 2: 收集投票

Gather agent recommendations:
markdown
undefined
收集Agent的建议：
markdown
undefined

Vote Collection

投票收集

database-architect (weight: 2.0)

database-architect (权重: 2.0)

  • Vote: PostgreSQL
  • Rationale: Strong ACID guarantees, mature ecosystem
  • Confidence: 0.9
  • 投票: PostgreSQL
  • 理由: 强大的ACID保证、成熟的生态系统
  • 置信度: 0.9

security-architect (weight: 1.0)

security-architect (权重: 1.0)

  • Vote: PostgreSQL
  • Rationale: Better encryption at rest, audit logging
  • Confidence: 0.8
  • 投票: PostgreSQL
  • 理由: 更好的静态加密、审计日志
  • 置信度: 0.8

devops (weight: 1.5)

devops (权重: 1.5)

  • Vote: DynamoDB
  • Rationale: Managed service, auto-scaling
  • Confidence: 0.7
undefined
  • 投票: DynamoDB
  • 理由: 托管服务、自动扩缩容
  • 置信度: 0.7
undefined

Step 3: Calculate Consensus

Step 3: 计算共识

Apply weighted voting:
PostgreSQL: (2.0 * 0.9) + (1.0 * 0.8) = 2.6
DynamoDB:   (1.5 * 0.7) = 1.05
MongoDB:    0

Total weight: 4.5
PostgreSQL: 2.6 / 4.5 = 57.8%
DynamoDB:   1.05 / 4.5 = 23.3%

Threshold: 60% → No clear consensus
应用加权投票：
PostgreSQL: (2.0 * 0.9) + (1.0 * 0.8) = 2.6
DynamoDB:   (1.5 * 0.7) = 1.05
MongoDB:    0

总权重: 4.5
PostgreSQL: 2.6 / 4.5 = 57.8%
DynamoDB:   1.05 / 4.5 = 23.3%

阈值（threshold）: 60% → 未达成明确共识

Step 4: Resolve Conflicts

Step 4: 解决冲突

When no consensus is reached:
Strategy 1: Expert Override
  • If domain expert has strong opinion (>0.8 confidence), defer to expert
Strategy 2: Discussion Round
  • Ask dissenting agents to respond to majority arguments
  • Re-vote after discussion
Strategy 3: Escalation
  • Present options to user with pros/cons from each agent
  • Let user make final decision
当未达成共识时：
策略1：专家裁决
  • 若领域专家的意见置信度>0.8，以专家意见为准
策略2：讨论回合
  • 持不同意见的Agent回应多数方的论点
  • 讨论后重新投票
策略3：升级上报
  • 向用户展示各Agent的选项及优缺点
  • 由用户做出最终决策

Step 5: Document Decision

Step 5: 记录决策

Record the final decision:
markdown
undefined
记录最终决策：
markdown
undefined

Decision Record

决策记录

Topic

议题

Which database to use for the new service
新服务应使用哪种数据库

Decision

决策结果

PostgreSQL
PostgreSQL

Voting Summary

投票汇总

  • PostgreSQL: 57.8% (2 votes)
  • DynamoDB: 23.3% (1 vote)
  • Consensus: NOT REACHED (below 60% threshold)
  • PostgreSQL: 57.8% (2票)
  • DynamoDB: 23.3% (1票)
  • 共识状态: 未达成（低于60%阈值）

Resolution Method

解决方式

Expert override - database-architect (domain expert) had 0.9 confidence in PostgreSQL
专家裁决 - 领域专家database-architect对PostgreSQL的置信度为0.9

Dissenting Opinion

不同意见

DevOps preferred DynamoDB for operational simplicity. Mitigation: Will use managed PostgreSQL (RDS) to reduce operational burden.
DevOps倾向于DynamoDB以简化运维。 缓解措施：将使用托管式PostgreSQL（RDS）以降低运维负担。

Decision Date

决策日期

2026-01-23

</execution_process>

<best_practices>

1. **Quorum Required**: Don't decide without minimum participation
2. **Weight by Expertise**: Domain experts get more influence
3. **Document Dissent**: Record minority opinions for future reference
4. **Clear Thresholds**: Define what constitutes consensus upfront
5. **Escalation Path**: Have a process for unresolved conflicts

</best_practices>
</instructions>

<examples>
<usage_example>
**Conflict Resolution Request**:
The architect wants microservices but the developer prefers monolith. Resolve this conflict.

**Voting Process**:

```markdown
2026-01-23

</execution_process>

<best_practices>

1. **需满足法定人数（Quorum）**：未达到最低参与人数时不得决策
2. **按专业度加权**：领域专家拥有更大影响力
3. **记录不同意见**：记录少数派意见以备未来参考
4. **明确阈值**：提前定义共识的判定标准
5. **上报路径**：制定未解决冲突的处理流程

</best_practices>
</instructions>

<examples>
<usage_example>
**冲突解决请求**:
架构师想要微服务，但开发者偏好单体架构。 解决此冲突。

**投票流程**:

```markdown

Voting: Architecture Style

投票：架构风格

Votes

投票情况

  • architect: Microservices (weight 1.5, confidence 0.8)
  • developer: Monolith (weight 1.0, confidence 0.9)
  • devops: Microservices (weight 1.0, confidence 0.6)
  • architect: 微服务（权重1.5，置信度0.8）
  • developer: 单体架构（权重1.0，置信度0.9）
  • devops: 微服务（权重1.0，置信度0.6）

Calculation

计算过程

Microservices: (1.5 _ 0.8) + (1.0 _ 0.6) = 1.8 Monolith: (1.0 * 0.9) = 0.9
Microservices: 66.7% → CONSENSUS REACHED
微服务: (1.5 * 0.8) + (1.0 * 0.6) = 1.8 单体架构: (1.0 * 0.9) = 0.9
微服务: 66.7% → 达成共识

Decision

决策结果

Microservices, with modular monolith as migration path
采用微服务，以模块化单体架构作为迁移路径

Dissent Mitigation

不同意见缓解措施

Start with modular monolith, extract services incrementally to address developer's maintainability concerns.

</usage_example>
</examples>
从模块化单体架构开始，逐步拆分服务，以解决开发者对可维护性的担忧。

</usage_example>
</examples>

Rules

规则

  • Always require quorum before deciding
  • Weight votes by domain expertise
  • Document dissenting opinions for future reference
  • 决策前必须满足法定人数（quorum）要求
  • 基于领域专业度对投票进行加权
  • 记录不同意见以备未来参考

Related Workflow

相关工作流

This skill has a corresponding workflow for complex multi-agent scenarios:
  • Workflow: 
    .claude/workflows/consensus-voting-skill-workflow.md
  • When to use workflow: For critical multi-agent decisions requiring Byzantine fault-tolerant consensus with Queen/Worker topology (architectural decisions, security reviews, technology selection)
  • When to use skill directly: For simple voting scenarios or when integrating consensus into other workflows
该Skill对应一个适用于复杂多Agent场景的工作流：
  • 工作流（Workflow）: 
    .claude/workflows/consensus-voting-skill-workflow.md
  • 何时使用工作流: 针对需要拜占庭容错共识的关键多Agent决策场景（架构决策、安全评审、技术选型），采用Queen/Worker拓扑结构
  • 何时直接使用Skill: 适用于简单投票场景，或在其他工作流中集成共识功能时

Workflow Integration

工作流集成

This skill enables decision-making in multi-agent orchestration:
Router Decision: 
.claude/workflows/core/router-decision.md
  • Router spawns multiple reviewers, then uses consensus to resolve conflicts
  • Planning Orchestration Matrix triggers consensus voting for review phases
Artifact Lifecycle: 
.claude/workflows/core/skill-lifecycle.md
  • Consensus voting determines artifact deprecation decisions
  • Multiple maintainers vote on breaking changes
Related Workflows:
  • swarm-coordination
    skill for parallel agent spawning before voting
  • Enterprise workflows use consensus for design reviews
  • Security reviews in 
    .claude/workflows/enterprise/
    require security-architect consensus
该Skill支持多Agent编排中的决策制定：
路由决策（Router Decision）: 
.claude/workflows/core/router-decision.md
  • 路由（Router）生成多个评审者，随后使用共识机制解决冲突
  • 规划编排矩阵在评审阶段触发共识投票
工件生命周期（Artifact Lifecycle）: 
.claude/workflows/core/skill-lifecycle.md
  • 共识投票决定工件的弃用决策
  • 多位维护者对破坏性变更进行投票
相关工作流:
  • swarm-coordination
    Skill用于投票前的并行Agent生成
  • 企业工作流使用共识机制进行设计评审
  • .claude/workflows/enterprise/
    中的安全评审需经过security-architect共识

Memory Protocol (MANDATORY)

内存协议（MANDATORY）

Before starting:
bash
cat .claude/context/memory/learnings.md
After completing:
  • New pattern -> 
    .claude/context/memory/learnings.md
  • Issue found -> 
    .claude/context/memory/issues.md
  • Decision made -> 
    .claude/context/memory/decisions.md
ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.
开始前：
bash
cat .claude/context/memory/learnings.md
完成后：
  • 新模式 -> 
    .claude/context/memory/learnings.md
  • 发现问题 -> 
    .claude/context/memory/issues.md
  • 已制定决策 -> 
    .claude/context/memory/decisions.md
假设存在中断：你的上下文可能会重置。若未记录在内存中，则视为未发生。