Game Theory Engine

All input is plain English. You extract structure from natural language. The user (or calling agent) provides:

1. The decision — What choice needs to be made?
2. The players — Who are the actors? (including the decision-maker)
3. The incentives — What does each player want? What do they actually respond to?
4. The constraints — Time, money, relationships, information, irreversibility?
5. The uncertainty — What don't we know? What could change?

If any of these are missing, infer what you can from context and flag what you assumed. Don't interrogate the user for perfect inputs — this engine should work with messy, real-world descriptions. Extract the formal structure yourself.

When another AI agent is calling this skill, expect the problem to arrive as a single block of text. Parse it without asking follow-up questions unless the decision itself is genuinely ambiguous (not just underspecified — underspecified is fine, ambiguous is not).

Execution Modes

The engine auto-selects a mode based on problem complexity. The calling agent can override by stating the mode explicitly.

The mode determines how much machinery to deploy — not how seriously to take the problem. A snap-mode analysis of "should I take this job offer" can be life-changing; it's snap because the structure is simple, not because it doesn't matter.

Phase 1: Problem Formalisation

Transform the plain-English input into a typed game structure.

1a. Game Classification

Read references/frameworks.md and classify the game:

• Game type: cooperative vs non-cooperative, simultaneous vs sequential, one-shot vs repeated
• Information structure: complete vs incomplete, perfect vs imperfect
• Applicable solution concepts: dominant strategy, Nash equilibrium, subgame perfect equilibrium, Bayesian Nash, mechanism design

Pick the simplest framework that captures the essential dynamics. Don't reach for Bayesian games when a simple payoff matrix will do. The framework is a tool, not a display of sophistication.

1b. Player Model

For each player, construct:

Player: [name/role]
├── Stated preference: [what they say they want]
├── Revealed preference: [what their incentive structure actually rewards]
├── Power: [0.0-1.0 — ability to influence outcome]
├── Information: [what they know that others don't]
└── Outside option: [what happens if they walk away]

The gap between stated and revealed preference is where the interesting dynamics hide. A manager who "wants the best technical solution" but gets promoted based on shipping dates has a revealed preference for speed over quality. Model the revealed preference.

1c. Payoff Matrix

For each player × each option, estimate payoffs on a -10 to +10 scale across three dimensions:

• Material: money, career advancement, resources, workload
• Social: status, relationships, reputation, trust, political capital
• Temporal: time cost, optionality preserved or destroyed, reversibility

Compute a weighted composite score per cell. The weights depend on what the player's revealed preferences tell you they actually optimise for.

Present the matrix to the user/calling agent. This is the core data structure — everything downstream flows from it.

Phase 2: Simulation

Snap Mode (Analytical)

Solve directly:

1. Identify dominated strategies and eliminate them (IESDS)
2. Find Nash equilibria in the reduced game
3. If multiple equilibria exist, apply refinements: Pareto dominance first, then risk dominance
4. Report the solution with confidence

Standard Mode (Perturbation Analysis)

Run 3 perturbation rounds inline:

For each round:

1. Perturb one assumption — shift a player's revealed preference, change an information asymmetry, relax a constraint, introduce a new player or remove one
2. Re-solve the game under perturbation
3. Record whether the top option changed and why

After all rounds, classify each option:

• Robust: top-ranked in all perturbations
• Conditionally robust: top in most, flipped under specific conditions (name them)
• Fragile: frequently displaced

Deep Mode (Monte Carlo)

When hard data is available (probabilities, dollar amounts, historical frequencies), run the Python Monte Carlo engine:

SKILL_DIR="<path-to-this-skill>"
python3 "$SKILL_DIR/scripts/simulate.py" \
  --scenario '{"decision":"...","options":[...],"players":[...],"payoffs":{...},"uncertainties":[...]}' \
  --iterations 10000 \
  --output /tmp/gte_sim_output.json

Before invoking the script, write the scenario as inline JSON. The script accepts it via --scenario (JSON string) or --scenario-file (path).

The script returns:

• Expected value distribution per option (mean, median, std, 5th/95th percentile)
• Sensitivity analysis: which input variables most affect the ranking
• Probability that each option is optimal
• Convergence diagnostics

Read the output and integrate into the ranking. If the script is unavailable, fall back to Standard mode with a note that Monte Carlo was requested but couldn't be executed.

Phase 3: Option Ranking

This is the primary output. Structure it exactly as follows — both for human readability and machine parseability.

Present the ranking in two forms:

Human-Readable Ranking

For each option, from highest to lowest expected value:

### Rank [N]: [Option Name]
Expected Value: [X.X / 10]
Confidence: [High|Medium|Low] — [one-line justification]
Robustness: [Robust|Conditional|Fragile] — survived [N/M] perturbations
Practical impact: [2-3 sentences on what actually happens if you choose this]
Key risk: [the single biggest thing that could go wrong]
Key upside: [the single biggest thing that could go right]
Falsifier: [one observable event that would prove this ranking wrong]

Machine-Readable Ranking (JSON)

Immediately after the human ranking, output a fenced JSON block tagged game_theory_output:

{
  "engine_version": "1.0",
  "mode": "snap|standard|deep",
  "timestamp": "ISO-8601",
  "decision": "the core choice in one sentence",
  "game_classification": {
    "type": "cooperative|non_cooperative",
    "timing": "simultaneous|sequential",
    "information": "complete|incomplete",
    "repetition": "one_shot|repeated",
    "solution_concept": "dominant_strategy|nash|subgame_perfect|bayesian_nash"
  },
  "players": [
    {
      "id": "player_name",
      "stated_preference": "string",
      "revealed_preference": "string",
      "power": 0.0,
      "information_advantage": "string",
      "outside_option": "string"
    }
  ],
  "options": [
    {
      "rank": 1,
      "name": "option name",
      "expected_value": 7.5,
      "confidence": "high|medium|low",
      "confidence_reasoning": "string",
      "robustness": "robust|conditional|fragile",
      "perturbation_survival_rate": 1.0,
      "payoff_breakdown": {
        "material": 0.0,
        "social": 0.0,
        "temporal": 0.0
      },
      "practical_impact": "string",
      "key_risk": "string",
      "key_upside": "string",
      "falsifier": "string"
    }
  ],
  "payoff_matrix": {
    "player_id": {
      "option_name": {"material": 0, "social": 0, "temporal": 0, "composite": 0}
    }
  },
  "simulation_metadata": {
    "perturbation_rounds": 0,
    "monte_carlo_iterations": null,
    "convergence_score": null
  },
  "introspection_baseline": {}
}

The introspection_baseline field is populated in Phase 4.

Phase 4: Introspection Baseline

This is what makes the engine useful for self-improvement pipelines. After completing the analysis, run five diagnostic checks and package the results as a structured JSON baseline that upstream agents (autoresearcher, gap analysis) can consume.

Diagnostic Checks

1. Transitivity: Do the rankings obey A > B > C? Any violation is a logical inconsistency — flag it with the specific cycle.

2. Sensitivity: Did the top option change under perturbation? Score as fraction of rounds where rank-1 was stable.

3. Completeness: For every player, do we have both stated and revealed preferences? Missing = incomplete model.

4. Falsifiability: Does every ranked option have a concrete, observable falsifier? Vague falsifiers ("if things change") don't count.

5. Calibration: Is the confidence level consistent with the evidence? High confidence requires ≥3 independent supporting reasons and robustness to perturbation. If the evidence doesn't support the confidence, flag the gap.

6. Cognitive Bias Scan: Check the analysis for anchoring (over-weighting first information), availability bias (over-weighting vivid scenarios), status quo bias (under-weighting change options), sunk cost reasoning, and confirmation bias. Name any detected.

7. Information Entropy: How much does the ranking depend on unknown information? High entropy = the decision might not be ripe yet.

Baseline JSON Schema

Populate the introspection_baseline field with:

{
  "diagnostics": {
    "transitivity": {"pass": true, "violations": []},
    "sensitivity": {"pass": true, "stability_score": 1.0, "flipped_under": []},
    "completeness": {"pass": true, "missing": []},
    "falsifiability": {"pass": true, "weak_falsifiers": []},
    "calibration": {"pass": true, "overconfident": [], "underconfident": []},
    "cognitive_bias_scan": {"biases_detected": [], "mitigation_applied": []},
    "information_entropy": {"score": 0.0, "high_uncertainty_factors": []}
  },
  "overall_quality_score": 0.0,
  "quality_grade": "A|B|C|D|F",
  "confidence_adjustment": "none|downgrade_one|flag_unreliable",
  "gaps_for_upstream": [
    {
      "gap_type": "missing_information|weak_assumption|model_limitation|bias_risk",
      "description": "string",
      "impact_on_ranking": "none|minor|could_flip_ranking",
      "suggested_research": "string"
    }
  ],
  "assumptions_register": [
    {
      "assumption": "string",
      "confidence": "high|medium|low",
      "if_wrong": "string — what happens to the ranking"
    }
  ],
  "decision_readiness": {
    "ready": true,
    "blockers": [],
    "recommended_information_to_gather": []
  }
}

Quality Score Calculation

• Start at 10.0
• Each failed diagnostic: -1.5
• Each detected cognitive bias without mitigation: -1.0
• Information entropy > 0.7: -2.0
• Map to grade: A (≥8.5), B (≥7.0), C (≥5.5), D (≥4.0), F (<4.0)

Gaps for Upstream

This is the most important part of the baseline for the autoresearcher. Each gap is a specific, actionable research lead:

• missing_information: "We don't know X, and knowing it could change the ranking"
• weak_assumption: "We assumed X, but if it's wrong, option 2 overtakes option 1"
• model_limitation: "The model doesn't capture X dynamic, which matters here"
• bias_risk: "The analysis may be skewed by X bias — investigate further"

Write gaps as research briefs, not vague concerns. "The competitor's pricing strategy is unknown and the ranking is sensitive to it — research their last 3 pricing moves" is useful. "More research needed" is not.

Output Contract

Every invocation of this engine produces exactly two artefacts:

1. Human-readable analysis — the ranking with reasoning, presented conversationally with the payoff matrix and perturbation results

2. Machine-readable JSON — the game_theory_output block containing the full typed output including introspection baseline, enclosed in a fenced code block tagged game_theory_output

The JSON is the canonical output. The human-readable version is a rendering of the JSON for human consumption. If there's ever a conflict, the JSON wins.

Failure Modes to Avoid

• Over-engineering simple decisions. If someone asks "should I have pasta or sushi for dinner", don't build a 6-player Bayesian game. Use snap mode and be direct. The engine's value is in its rigour when rigour matters, not in applying heavy machinery everywhere.

• False precision. A payoff of 7.3 vs 7.1 is noise, not signal. Don't pretend decimal differences are meaningful when the inputs are qualitative estimates. Report confidence intervals, not point estimates, when uncertainty is high.

• Ignoring emotions and identity. "Rational" doesn't mean "ignoring feelings". Emotional payoffs are real payoffs — model them in the social dimension. A decision that's EV-optimal but makes you miserable has a real social/temporal cost.

• Skipping introspection. The baseline is not optional. It's what makes this engine compound in value over time via upstream gap analysis. Even in snap mode, run the diagnostics.

• Being slow. The primary consumers are AI agents running this multiple times per day. Snap mode should be genuinely fast. Don't pad output with preamble, caveats, or throat-clearing. Structure, rank, baseline, done.