god-consensus
Skill181 starsChanged 9 months agoMITView on GitHub
Guides God Committee members through consensus-building for collective decisions. Use for proposals, voting, and disagreement resolution. Triggers on: consensus, voting, proposal, committee decision.
In this repository16 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- architectSkill
- doc-reviewSkill
- god-interventionSkill
- god-memberSkill
- observabilitySkill
- parallel-exploreSkill
- plan-reviewSkill
- prd-converterSkill
- prdSkill
- researchSkill
- roadmapSkill
- skill-creatorSkill
- vision-builderSkill
- visionSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
13 rules. About 0 are common, 12 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈12
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Use this skill when:
- Distinctive: line 45
Before proposing, gather evidence and formulate your rationale:
- Distinctive: line 126
Check if it's already being addressed
- Distinctive: line 159
Always add a comment explaining your vote:
- Distinctive: line 200
When members disagree significantly:
- Distinctive: line 210
Look for common ground
- Distinctive: line 223
If consensus cannot be reached:
- Distinctive: line 226
Wait for more information
- Distinctive: line 235
Default action if no consensus
- Distinctive: line 257
Document the action immediately
- Very specific: line 315
All decisions are recorded in .god/council/decisions/ with this structure:
- Distinctive: line 345
If Rejected: Document why and any alternatives
- Distinctive: line 347
Notify Stakeholders: If relevant to execution layer
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
God Committee Consensus Skill
Purpose
This skill guides God Committee members through the consensus-building process for making collective decisions.
When to Use This Skill
Use this skill when:
- Proposing a significant change or intervention
- Voting on another member's proposal
- Resolving disagreements between members
- Making decisions that require consensus per configuration
Consensus Requirements
Actions Requiring Consensus
Per .god/config.json, these actions require consensus:
- Termination: Stopping the entire project
- Major Rollback: Rolling back multiple commits or PRDs
- Skill Deletion: Removing existing skills
Actions Allowing Solo Decision
- Minor fixes and repairs
- Observation and documentation
- Pausing for investigation
- Sending alerts and notifications
Quorum Rules
- Standard Quorum: 2 out of 3 members must agree
- Emergency Quorum: 1 member can act alone in critical situations
Creating a Proposal
Step 1: Prepare Your Case
Before proposing, gather evidence and formulate your rationale:
## Proposal Preparation
### Issue Identified
[Clear description of the problem]
### Evidence
- [Log entry/observation 1]
- [Log entry/observation 2]
- [Metric or data point]
### Proposed Action
[Specific action to take]
### Expected Outcome
[What success looks like]
### Risks
[Potential downsides]
### Alternatives Considered
[Other options and why not chosen]Step 2: Acquire Speaking Rights
./scripts/god/council.sh lock YOUR_IDStep 3: Create the Proposal
./scripts/god/council.sh propose YOUR_ID "TYPE" "DESCRIPTION" "RATIONALE"Proposal Types:
intervention- Active intervention in executionrepair- Fix or repair actionpolicy_change- Change to rules or configurationtermination- Stop project executionrollback- Revert to previous state
Example:
./scripts/god/council.sh propose alpha "intervention" \
"Pause PRD execution to fix failing tests" \
"Test coverage dropped 15% in last 3 stories. Need to address before proceeding."Step 4: Notify Members
The proposal system automatically notifies all members. The message will be in their inboxes.
Step 5: Release Speaking Rights
./scripts/god/council.sh unlock YOUR_IDVoting on Proposals
Step 1: Review the Proposal
# Check pending decisions
./scripts/god/council.sh status
# Read the specific proposal
cat .god/council/decisions/DECISION_ID.json | jq '.'Step 2: Analyze the Proposal
Consider these questions:
- Is the problem real?
- Verify the evidence
- Check if it's already being addressed
- Is the solution appropriate?
- Will it solve the problem?
- Are there better alternatives?
- What are the side effects?
- Is it timely?
- Is immediate action needed?
- Can we wait for more information?
Step 3: Cast Your Vote
./scripts/god/council.sh lock YOUR_ID
./scripts/god/council.sh vote YOUR_ID "DECISION_ID" "VOTE" "COMMENT"
./scripts/god/council.sh unlock YOUR_IDVote Options:
approve- Support the proposalreject- Oppose the proposalabstain- Neither support nor oppose
Example:
./scripts/god/council.sh vote beta "decision-20260129150000" "approve" \
"Agree with the assessment. Tests should be fixed before proceeding."Step 4: Document Your Reasoning
Always add a comment explaining your vote:
## Vote: [APPROVE/REJECT/ABSTAIN]
### Reasoning
[Why you voted this way]
### Conditions (if any)
[Conditions for your support]
### Alternative Suggestion (if rejecting)
[What you'd propose instead]Reaching Consensus
Unanimous Agreement
Ideal scenario - all members agree:
Alpha: approve
Beta: approve
Gamma: approve
Result: APPROVED (unanimous)Majority Agreement
Quorum reached with majority:
Alpha: approve
Beta: approve
Gamma: reject
Result: APPROVED (2/3 majority)Split Decision
When members disagree significantly:
- Initiate Discussion Session
./scripts/god/council.sh session-start "Resolving: PROPOSAL_TOPIC" - Each Member States Position
- Present full reasoning
- Listen to others' concerns
- Look for common ground
- Seek Compromise
- Modify the proposal
- Add conditions
- Split into smaller decisions
- Re-vote if Needed
- Create amended proposal
- Vote again
Deadlock Resolution
If consensus cannot be reached:
- Defer Decision
- Wait for more information
- Set review deadline
- Escalate Scope
- Break into smaller decisions
- Address sub-issues separately
- Time-box Discussion
- Set deadline for decision
- Default action if no consensus
Emergency Consensus
In critical situations, expedited consensus is allowed:
Emergency Criteria
- System crash or imminent failure
- Security breach
- Data loss risk
- Infinite loop/resource exhaustion
Emergency Protocol
- Declare Emergency
./scripts/god/awakener.sh critical "REASON" - Take Immediate Action
- One member can act alone
- Document the action immediately
- Post-Action Review
- Inform other members ASAP
- Document full rationale
- Get retroactive approval
Emergency Action Template
## Emergency Action Report
### Timestamp
[When action was taken]
### Acting Member
[Who took the action]
### Situation
[What triggered the emergency]
### Action Taken
[What was done]
### Justification
[Why immediate action was needed]
### Outcome
[Result of the action]
### Post-Action Votes
- Alpha: [pending/approved/rejected]
- Beta: [pending/approved/rejected]
- Gamma: [pending/approved/rejected]Consensus Best Practices
Do
- ✅ Present clear evidence
- ✅ Consider all perspectives
- ✅ Propose specific, actionable items
- ✅ Accept compromise when reasonable
- ✅ Document all reasoning
- ✅ Respect deadlines
Don't
- ❌ Vote without reviewing the proposal
- ❌ Reject without suggesting alternatives
- ❌ Take solo action when consensus is required
- ❌ Ignore minority opinions
- ❌ Let proposals languish without voting
- ❌ Make personal attacks
Decision Record
All decisions are recorded in .god/council/decisions/ with this structure:
{
"decisionId": "decision-20260129150000",
"type": "intervention",
"status": "decided",
"createdAt": "2026-01-29T15:00:00Z",
"decidedAt": "2026-01-29T15:30:00Z",
"proposal": {
"author": "alpha",
"description": "...",
"rationale": "..."
},
"votes": {
"alpha": {"vote": "approve", "comment": "...", "timestamp": "..."},
"beta": {"vote": "approve", "comment": "...", "timestamp": "..."},
"gamma": {"vote": "abstain", "comment": "...", "timestamp": "..."}
},
"quorum": 2,
"result": "approved",
"executedAt": "2026-01-29T15:35:00Z"
}After Consensus
Once a decision is reached:
- If Approved: Execute the proposed action
- If Rejected: Document why and any alternatives
- Update Timeline: Log the decision event
- Notify Stakeholders: If relevant to execution layer
# After approved decision
./scripts/god/observer.sh event "decision" "Proposal approved: DESCRIPTION"
# Execute the action
[perform the approved action]
# Mark as executed
jq '.executedAt = "'"$(date -u +%Y-%m-%dT%H:%M:%SZ)"'"' \
.god/council/decisions/DECISION_ID.json > tmp && mv tmp .god/council/decisions/DECISION_ID.jsonDoes it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

