Byzantine consensus voting for multi-agent decision making. Implements voting protocols, conflict resolution, and agreement algorithms for reaching consensus among multiple agents.
Sign in to like and favorite skills
name: consensus-voting description: Byzantine consensus voting for multi-agent decision making. Implements voting protocols, conflict resolution, and agreement algorithms for reaching consensus among multiple agents. version: 1.0 model: sonnet invoked_by: both user_invocable: true tools: [Read, Write, Edit, Bash, Glob, Grep] best_practices:
Set up the voting session:
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
Gather agent recommendations:
## Vote Collection ### database-architect (weight: 2.0) - Vote: PostgreSQL - Rationale: Strong ACID guarantees, mature ecosystem - Confidence: 0.9 ### security-architect (weight: 1.0) - Vote: PostgreSQL - Rationale: Better encryption at rest, audit logging - Confidence: 0.8 ### devops (weight: 1.5) - Vote: DynamoDB - Rationale: Managed service, auto-scaling - Confidence: 0.7
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
When no consensus is reached:
Strategy 1: Expert Override
Strategy 2: Discussion Round
Strategy 3: Escalation
Record the final decision:
## Decision Record ### Topic Which database to use for the new service ### Decision PostgreSQL ### Voting Summary - PostgreSQL: 57.8% (2 votes) - DynamoDB: 23.3% (1 vote) - Consensus: NOT REACHED (below 60% threshold) ### Resolution Method Expert override - database-architect (domain expert) had 0.9 confidence in PostgreSQL ### Dissenting Opinion DevOps preferred DynamoDB for operational simplicity. Mitigation: Will use managed PostgreSQL (RDS) to reduce operational burden. ### Decision Date 2026-01-23
</execution_process>
<best_practices>
</best_practices>
The architect wants microservices but the developer prefers monolith. Resolve this conflict.
Voting Process:
## 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) ### Calculation Microservices: (1.5 _ 0.8) + (1.0 _ 0.6) = 1.8 Monolith: (1.0 \* 0.9) = 0.9 Microservices: 66.7% → CONSENSUS REACHED ### 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>
This skill has a corresponding workflow for complex multi-agent scenarios:
.claude/workflows/consensus-voting-skill-workflow.mdThis skill enables decision-making in multi-agent orchestration:
Router Decision:
.claude/workflows/core/router-decision.mdArtifact Lifecycle:
.claude/workflows/core/skill-lifecycle.mdRelated Workflows:
swarm-coordination.claude/workflows/enterprise/Before starting:
cat .claude/context/memory/learnings.md
After completing:
.claude/context/memory/learnings.md.claude/context/memory/issues.md.claude/context/memory/decisions.mdASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.