| name | game-theoretic-council |
| description | Run a council review as a game-theoretic decision process: players, incentives, strategies, payoffs, dominated options, stability claims, mechanisms, and verification tests. |
| version | 1.0.0 |
| author | Cairn |
| license | MIT |
| metadata | {"hermes":{"tags":["strategy","council","game-theory","decision-making","mechanism-design","multi-agent","delegation","governance"],"related_skills":[]}} |
Game-Theoretic Council
Use this skill when a decision needs structured multi-perspective review and a test of whether the recommendation survives incentives.
The council pattern is useful because different roles notice different failure modes. Game theory is useful because consensus is not stability. A recommendation is only strong when it still works after each relevant actor follows their own incentives, constraints, and information.
Trigger conditions
Load this skill for:
- product, roadmap, positioning, or prioritization decisions;
- multi-agent, delegation, profile, team, or governance design;
- authority, permissioning, safety, or approval-boundary choices;
- adversarial, abuse, or red-team analysis;
- stakeholder conflict, bargaining, or coordination problems;
- expensive, irreversible, ambiguous, or high-trust decisions;
- council-style reviews that risk becoming a list of opinions instead of a decision model.
Do not use it for simple factual lookup or routine execution when the next step is obvious and reversible.
Core rule
Council proposes and critiques. Game theory decides whether the recommendation survives incentives.
A valid review names:
- the decision question;
- players and incentives;
- candidate strategies;
- payoff dimensions;
- information asymmetries;
- likely counter-moves;
- dominated options;
- equilibrium or stability claim;
- mechanisms that make the desired behavior stable;
- verification tests and stop conditions.
Fast path
Use this shape when time is limited:
# Game-Theoretic Council: <decision>
## Decision
## Players and incentives
## Candidate strategies
## Dominated options
## Stability claim
## Recommendation
## Verification tests
Full process
1. Frame the decision
State the decision as a concrete question.
Good:
Should this system use direct live mutation or a reviewed ChangeSet workflow?
Bad:
What is the best architecture?
2. Identify players
Include everyone who can act, benefit, lose, exploit, maintain, inherit, constrain, or verify the decision.
Common player classes:
- user, owner, or principal;
- assistant, operator, or delegated agent;
- future maintainers;
- reviewers and verifiers;
- customers or downstream users;
- external competitors or baselines;
- attackers, abusers, or misuse cases;
- infrastructure, budget, policy, and time constraints.
For each player, name incentives and powers.
players:
- name: owner
incentives: [useful outcome, low risk, low maintenance burden]
powers: [approve scope, accept risk, stop work]
- name: delegated_agent
incentives: [complete assigned task, appear successful]
powers: [write files, call tools within scope]
- name: verifier
incentives: [catch false claims, preserve trust]
powers: [block completion, demand proof]
3. Define candidate strategies
Name the real available moves. Include tempting bad options because they expose dominated-strategy checks.
strategies:
- do_nothing
- direct_live_mutation
- reviewed_changeset_workflow
- fully_autonomous_execution
4. Choose payoff dimensions
Use multiple dimensions. Avoid one blended score too early.
Useful default dimensions:
| Dimension | Meaning |
|---|
| user_value | How much the strategy helps the intended user. |
| strategic_value | Whether it creates durable advantage or clarity. |
| safety | Whether it prevents harm, drift, misuse, or false success. |
| implementation_cost | Build and maintenance burden. |
| reversibility | Whether mistakes can be undone. |
| auditability | Whether future readers can reconstruct what happened. |
| delegation_correctness | Whether authority and responsibility stay aligned. |
| long_term_value | Whether the choice compounds across future work. |
Scores are scaffolding, not proof. Explain the score or omit it.
5. Classify the game
Use the model that fits. Do not force the wrong one.
| Game type | Use when |
|---|
| Principal-agent | One actor delegates work or authority to another. |
| Repeated game | Trust, maintenance, reputation, or future interactions matter. |
| Mechanism design | Rules/defaults must make desired behavior easier than bad behavior. |
| Coordination game | Multiple actors need compatible choices or shared state. |
| Bargaining / coalition | Stakeholders have partially aligned interests and possible vetoes. |
| Bayesian game | Players have incomplete or private information. |
| Sequential / Stackelberg | One actor moves first and others respond. |
| Zero-sum / minimax | Security, abuse, exploitation, or direct adversaries dominate. |
6. Run council roles
Use only roles that materially help. Five sharp roles are better than twelve shallow personas.
Proposer
- Best candidate strategy.
- Intended payoff.
- Assumptions required.
- What success looks like.
Red Team / Adversary
- Likely exploit or counter-move.
- How the plan fails if actors optimize locally.
- Worst credible outcome.
- Mitigation or stop condition.
Mechanism Designer
- Desired behavior.
- Current incentives.
- Where incentives diverge from desired behavior.
- Rules, defaults, proofs, costs, approvals, or rewards that realign behavior.
Principal-Agent Analyst
- Principal.
- Agent.
- Delegated authority.
- Information asymmetry.
- Monitoring or proof requirement.
- Whether the agent can fake success.
Repeated-Game Analyst
- One-shot payoff.
- Long-term payoff.
- Trust consequence.
- Retaliation, decay, or compounding effects.
Coordination Analyst
- Required shared state.
- Handoff risks.
- Bottlenecks.
- Compatibility constraints.
- Failure if one participant defects, stalls, or lags.
Verifier / Empiricist
- Claims that must be proven.
- Observable tests.
- Required logs, diffs, artifacts, measurements, or user-visible proof.
- What would falsify the recommendation.
Arbiter
- Removes dominated strategies.
- States the equilibrium or stability claim.
- Selects recommendation, fallback, and stop conditions.
7. Eliminate dominated strategies
A strategy is dominated when another available strategy is better on every load-bearing dimension, or better on the dimensions that matter most with no unacceptable cost.
State eliminations directly:
- `direct_live_mutation` is dominated for this case because `reviewed_changeset_workflow` preserves user value while improving reversibility, auditability, and delegation correctness.
8. State the stability claim
Ask:
If each player behaves according to their incentives, does this recommendation still work?
A good stability claim names the incentives and the mechanism that makes the desired outcome stable.
Example:
The reviewed ChangeSet workflow is stable because users get visible control, builders get a clear implementation target, reviewers get diffs and rollback proof, and delegated agents cannot claim success without testable artifacts.
9. Recommend mechanisms
The output should include mechanism changes, not just opinions.
Useful mechanism types:
- explicit approval gates;
- reversible ChangeSets;
- diff-first workflows;
- audit trails;
- capability and risk labels;
- independent verification;
- role separation between builder and critic;
- default-safe UI or CLI paths;
- staged rollouts;
- cost visibility;
- authority scopes;
- stop conditions.
10. Define verification tests
Every important claim needs a proof path.
Examples:
- Inspect diffs before and after a proposed ChangeSet.
- Run a rollback proof in a disposable environment.
- Compare behavior against the current baseline.
- Have a critic try to falsify the recommendation.
- Produce user-visible proof for UI or workflow claims.
- Confirm no live mutation occurred outside the declared authority boundary.
Full output template
# Game-Theoretic Council Review: <decision>
## 1. Decision
## 2. Players and incentives
| Player | Incentives | Powers | Risks introduced |
|---|---|---|---|
## 3. Candidate strategies
## 4. Payoff matrix
| Strategy | User value | Strategic value | Safety | Cost | Reversibility | Auditability | Long-term value |
|---|---:|---:|---:|---:|---:|---:|---:|
## 5. Game type
## 6. Council findings
### Proposer
### Red Team
### Mechanism Designer
### Principal-Agent Analyst
### Repeated-Game Analyst
### Coordination Analyst
### Verifier
### Arbiter
## 7. Dominated strategies
## 8. Equilibrium / stability claim
## 9. Recommendation
Primary move:
Fallback:
Stop conditions:
## 10. Mechanisms to implement
## 11. Verification tests
Pitfalls
- Do not let roles become decorative personas. Each role must produce a decision-relevant claim.
- Do not mistake consensus for stability.
- Do not hide value judgments inside fake precision.
- Do not call something an equilibrium unless players, strategies, incentives, and response behavior are visible.
- Do not recommend mechanisms without verification tests.
- Do not over-model simple choices. If the answer is obvious and reversible, act.
Quality bar
A good game-theoretic council review should make the decision easier to audit later. A future reader should be able to see:
- why the selected strategy beat alternatives;
- which incentives could break it;
- which mechanisms make it stable;
- what proof would show it worked;
- what signal would make the reviewer change course.
