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>

</capabilities>

<instructions>

<execution_process>

Step 1: Define Voting Parameters

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

```

Step 2: Collect Votes

Gather agent recommendations:

```markdown

Vote Collection

database-architect (weight: 2.0)

security-architect (weight: 1.0)

devops (weight: 1.5)

```

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

**Strategy 2: Discussion Round**

**Strategy 3: Escalation**

Step 5: Document Decision

Record the final decision:

```markdown

Decision Record

Topic

Which database to use for the new service

Decision

PostgreSQL

Voting Summary

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>

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

Voting: Architecture Style

Votes

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>

</examples>

Rules

Related Workflow

This skill has a corresponding workflow for complex multi-agent scenarios:

Workflow Integration

This skill enables decision-making in multi-agent orchestration:

**Router Decision:** `.claude/workflows/core/router-decision.md`

**Artifact Lifecycle:** `.claude/workflows/core/skill-lifecycle.md`

**Related Workflows:**

---

Memory Protocol (MANDATORY)

**Before starting:**

```bash

cat .claude/context/memory/learnings.md

```

**After completing:**

> ASSUME INTERRUPTION: Your context may reset. If it's not in memory, it didn't happen.