agentleFS
YougLin-devYougLin-dev/Aha-Loop/.agents/skills/god-consensus/SKILL.md

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.

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
  1. Distinctive:

    Use this skill when:

    line 14
  2. Distinctive:

    Before proposing, gather evidence and formulate your rationale:

    line 45
  3. Distinctive:

    Check if it's already being addressed

    line 126
  4. Distinctive:

    Always add a comment explaining your vote:

    line 159
  5. Distinctive:

    When members disagree significantly:

    line 200
  6. Distinctive:

    Look for common ground

    line 210
  7. Distinctive:

    If consensus cannot be reached:

    line 223
  8. Distinctive:

    Wait for more information

    line 226
  9. Distinctive:

    Default action if no consensus

    line 235
  10. Distinctive:

    Document the action immediately

    line 257
  11. Very specific:

    All decisions are recorded in .god/council/decisions/ with this structure:

    line 315
  12. Distinctive:

    If Rejected: Document why and any alternatives

    line 345
  13. Distinctive:

    Notify Stakeholders: If relevant to execution layer

    line 347

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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_ID

Step 3: Create the Proposal

./scripts/god/council.sh propose YOUR_ID "TYPE" "DESCRIPTION" "RATIONALE"

Proposal Types:

  • intervention - Active intervention in execution
  • repair - Fix or repair action
  • policy_change - Change to rules or configuration
  • termination - Stop project execution
  • rollback - 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_ID

Voting 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:

  1. Is the problem real?
    • Verify the evidence
    • Check if it's already being addressed
  2. Is the solution appropriate?
    • Will it solve the problem?
    • Are there better alternatives?
    • What are the side effects?
  3. 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_ID

Vote Options:

  • approve - Support the proposal
  • reject - Oppose the proposal
  • abstain - 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:

  1. Initiate Discussion Session
    ./scripts/god/council.sh session-start "Resolving: PROPOSAL_TOPIC"
  2. Each Member States Position
    • Present full reasoning
    • Listen to others' concerns
    • Look for common ground
  3. Seek Compromise
    • Modify the proposal
    • Add conditions
    • Split into smaller decisions
  4. Re-vote if Needed
    • Create amended proposal
    • Vote again

Deadlock Resolution

If consensus cannot be reached:

  1. Defer Decision
    • Wait for more information
    • Set review deadline
  2. Escalate Scope
    • Break into smaller decisions
    • Address sub-issues separately
  3. 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

  1. Declare Emergency
    ./scripts/god/awakener.sh critical "REASON"
  2. Take Immediate Action
    • One member can act alone
    • Document the action immediately
  3. 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:

  1. If Approved: Execute the proposed action
  2. If Rejected: Document why and any alternatives
  3. Update Timeline: Log the decision event
  4. 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.json

Download now (ZIP)

Does 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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.