Update to Sparkore Core

{
  "description": "Use for the receiving project's balance modeling, audits, calibration, scenario comparison, pass generation, or validation across Weapon, Hero, Equipment, Enemy, progression, economy, and player-loadout power.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 230
    }
  ],
  "name": "balance-analysis",
  "skill_md_contents": "---\nname: balance-analysis\ndescription: Use for the receiving project's balance modeling, audits, calibration, scenario comparison, pass generation, or validation across Weapon, Hero, Equipment, Enemy, progression, economy, and player-loadout power.\n---\n\n# Balance Analysis Skill\n\nApply the [receiving-project contract](../../references/project-context.md). Resolve the actual game systems, configuration owner, active balance phase, and promotion gates from the project; the domains listed in the description are examples.\n\n## Goal\nProduce traceable, non-destructive balance decisions from explicit scenarios, formulas, assumptions, evidence tiers, and exit gates without confusing configured values, model outputs, runtime behavior, and final accepted balance.\n\n## Trigger\nUse for balance design/modeling, quantitative audits, pass comparisons, calibration, target budgets, TTK/DPS analysis, or validation. Activate `knowledge-steward` when durable KB state changes and `runtime-audit` when code/runtime semantics must be verified.\n\n## Authority boundaries\n- Balance process, methodology, accepted design intent, exit gates → canonical balance docs/roadmap.\n- Structured config and live numeric values → the project's designated live configuration, Sheets, or CSV (for example, a project may use `BlueprintData`).\n- Experimental calculations/workbooks → designated balance workbooks; they are evidence/work artifacts, not automatic canonical truth.\n- Implemented runtime behavior → the designated repository/runtime evidence.\n- Playtest observations → designated playtest logs.\n- Production outcomes → the project's designated analytics source.\n\n## Core loop\n1. Define the exact balance question, player experience, scenario, and metric.\n2. Lock the test boundary; avoid changing unrelated variable families at the same time.\n3. State formulas, units, assumptions, expected ranges, confidence, and provisional dependencies.\n4. Preserve accepted sources; create non-destructive variants/passes for experiments.\n5. Validate data integrity before interpreting outputs.\n6. Use the highest available evidence tier: config/formula → code/runtime semantics → controlled test → loadout/encounter test → structured playtest → production telemetry.\n7. Compare model with evidence and separate model error, implementation error, and tuning error.\n8. Decide: accept, revise, reject, or keep temporary.\n9. Promote structured values only after the relevant exit gate is explicitly accepted.\n10. Persist durable methodology/decisions and update compact context/working state without copying whole workbooks into the KB.\n\n## Scenario discipline\n- Never present a scalar as final Player/Hero/Equipment Power unless that model is explicitly assigned and accepted.\n- Preserve scenario names and reference fixtures so comparisons remain reproducible.\n- State occupied-cell/spatial assumptions when backpack opportunity cost matters.\n- Separate direct stat contribution from ability/passive/behavior realization when evidence differs.\n- Label inherited provisional baselines; downstream calculations do not upgrade their evidence quality automatically.\n\n## Output discipline\nA canonical balance artifact should make clear: question, scope/exclusions, source ownership, scenario fixtures, formulas/evaluation order, assumptions/confidence, evidence tier, findings, accepted decision or temporary decision, exit/revisit trigger, and links to numeric workbooks/config.\n\nLarge matrices and live numeric tables stay in their owned workbook/config. The KB stores interpretation, methodology, constraints, and accepted decisions.\n\n## Current project process\nFollow the receiving project's active balance roadmap, deferred gates, evidence ladder, and non-destructive-pass rules. The source project's `Game Balance Roadmap.md`, numeric fixtures, and M4/M5 milestones remain project-owned; they are not prerequisites or default state for another game.\n"
}