consensus-voting
- Repo stars 39
- Author repo awesome-omni-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>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
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>
</examples>
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-coordinationskill for parallel agent spawning before voting- Enterprise workflows use consensus for design reviews
- Security reviews in
.claude/workflows/enterprise/require security-architect consensus
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.
- Fluxly category
- AI
- Author-declared agents
- No explicit declaration found; this is not inferred or tested compatibility
- Static check
- 92 / 100 · heuristic scan, not runtime safety proof
- Author / version / license
- @diegosouzapw · v1.0 · no license declared
- Fluxly token estimate
- Lean
- Fluxly setup estimate
- Guided setup
- External API key
- No requirement detected
- Detected OS requirements
- Unspecified
- Runtime requirements
- Unspecified
- Detected file/system behavior
-
- Read-only
- Shell exec
- Detected network behavior
- Local-only
- Install commands
- None (reference only)
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
The current SKILL.md does not define a fixed output example. Set up the voting session:
Gather agent recommendations:
Apply weighted voting:
When no consensus is reached: Strategy 1: Expert Override If domain expert has strong opinion (>0.8 confidence), defer to expert
Record the final decision:
# 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>
### 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)
- 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**
… Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.
sections -> Step 1: Define Voting Parameters → Step 2: Collect Votes → Vote Collection → database-architect (weight: 2.0) → security-architect (weight: 1.0) → devops (weight: 1.5)
terms -> Strategy 1: Expert Override · Strategy 2: Discussion Round · Strategy 3: Escalation · Quorum Required · Weight by Expertise · Document Dissent · Clear Thresholds · Escalation Path
files/cmd -> .claude/workflows/consensus-voting-skill-workflow.md · .claude/workflows/core/router-decision.md · .claude/workflows/core/skill-lifecycle.md · swarm-coordination · .claude/workflows/enterprise/ · .claude/context/memory/learnings.md · .claude/context/memory/issues.md · .claude/context/memory/decisions.md
body sha256 -> 8923e0936bc5
Decide Fit First
Design Intent
How To Use It
Boundaries And Review