Consensus Voting Skill

Step 1: Define Voting Parameters

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

Step 2: Collect Votes

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

Step 3: Calculate Consensus

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

Step 4: Resolve Conflicts

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

Step 5: Document Decision

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>

• Quorum Required: Don't decide without minimum participation

• Weight by Expertise: Domain experts get more influence

• Document Dissent: Record minority opinions for future reference

• Clear Thresholds: Define what constitutes consensus upfront

• Escalation Path: Have a process for unresolved conflicts

</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>

Rules

• Always require quorum before deciding

• Weight votes by domain expertise

• Document dissenting opinions for future reference

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

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

Iron Laws

• NEVER accept a decision without meeting minimum quorum — decisions made without quorum are illegitimate; if quorum is not met, postpone the decision or escalate to human intervention.

• ALWAYS weight votes by domain expertise — equal weights give a generalist developer the same influence as a domain expert; weight by expertise relevance to the decision domain.

• NEVER discard dissenting opinions — minority perspectives contain the most important signal about edge cases and risks; document all rationales, including the losing side.

• ALWAYS require re-vote with deliberation before escalating — a split vote without deliberation wastes the consensus mechanism; agents must share reasoning and vote again before escalating to human.

• NEVER allow abstentions in critical decisions — abstentions on high-stakes decisions mean agents are avoiding responsibility; all participants must vote on CRITICAL/UNANIMOUS-threshold decisions.

Anti-Patterns

Anti-Pattern Why It Fails Correct Approach

No quorum requirement Tiny group decides for all; illegitimate consensus Set minimum participation threshold per decision type

Equal weights for all agents Ignores domain expertise; reduces signal quality Weight by domain expertise relevance (1.0–2.0 range)

Discarding dissenting rationales Loses edge case awareness and risk signals Document all votes and rationales, majority and minority

Immediate escalation on split vote Skips deliberation that could resolve disagreement Require deliberation + re-vote before human escalation

Allowing abstentions on critical decisions Agents avoid accountability on hard decisions Require participation from all eligible voters on CRITICAL decisions

Memory Protocol (MANDATORY)

Before starting:

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.