plugins/yzmir-simulation-foundations/skills/using-simulation-foundations/SKILL.md
Router for simulation math - ODEs, state-space, stability, control, numerics, chaos, stochastic
npx skillsauth add tachyon-beep/skillpacks using-simulation-foundationsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Your entry point to mathematical simulation foundations. This skill routes you to the right combination of mathematical skills for your game simulation challenge.
This is a meta-skill that:
You should use this skill: When building any simulation system that needs mathematical rigor.
IMPORTANT: All reference sheets are located in the SAME DIRECTORY as this SKILL.md file.
When this skill is loaded from:
skills/using-simulation-foundations/SKILL.md
Reference sheets like differential-equations-for-games.md are at:
skills/using-simulation-foundations/differential-equations-for-games.md
NOT at:
skills/differential-equations-for-games.md ← WRONG PATH
When you see a link like [differential-equations-for-games.md](differential-equations-for-games.md), read the file from the same directory as this SKILL.md.
Empirical Tuning: Trial-and-error adjustment of magic numbers
Mathematical Foundation: Formulate systems using theory
✅ Use simulation-foundations when:
❌ Don't use simulation-foundations when:
When to use: ANY continuous dynamics (population, physics, resources) Teaches: Formulating and solving ODEs for game systems Examples: Lotka-Volterra ecosystems, spring-damper camera, resource regeneration Time: 2.5-3.5 hours Key insight: Systems with rates of change need ODEs
When to use: Complex systems with many interacting variables Teaches: Representing game state mathematically, reachability analysis Examples: Fighting game frame data, RTS tech trees, puzzle solvability Time: 2.5-3.5 hours Key insight: Explicit state representation enables analysis
When to use: Need to prevent crashes, explosions, extinctions Teaches: Equilibrium points, eigenvalue analysis, Lyapunov functions Examples: Ecosystem balance, economy stability, physics robustness Time: 3-4 hours Key insight: Analyze stability BEFORE shipping
When to use: Smooth tracking, adaptive systems, disturbance rejection Teaches: PID controllers for game systems Examples: Camera smoothing, AI pursuit, dynamic difficulty Time: 2-3 hours Key insight: PID replaces magic numbers with physics
When to use: Implementing continuous systems in discrete timesteps Teaches: Euler, Runge-Kutta, symplectic integrators Examples: Physics engines, cloth, orbital mechanics Time: 2.5-3.5 hours Key insight: Integration method affects stability
When to use: Choosing model type (continuous ODEs vs discrete events) Teaches: When to use continuous, discrete, or hybrid Examples: Turn-based vs real-time, cellular automata, quantized resources Time: 2-2.5 hours Key insight: Wrong choice costs 10× performance OR 100× accuracy
When to use: Multiplayer desyncs, determinism requirements, sensitivity analysis Teaches: Butterfly effect, Lyapunov exponents, deterministic chaos Examples: Weather systems, multiplayer lockstep, proc-gen stability Time: 2-3 hours Key insight: Deterministic ≠ predictable
When to use: Random processes, loot systems, AI uncertainty Teaches: Probability distributions, Monte Carlo, stochastic differential equations Examples: Loot drops, crit systems, procedural generation Time: 2-3 hours Key insight: Naive randomness creates exploits
START: What are you building?
├─ ECOSYSTEM / POPULATION SIMULATION
│ ├─ Formulate dynamics → differential-equations-for-games
│ ├─ Prevent extinction/explosion → stability-analysis
│ ├─ Implement simulation → numerical-methods
│ └─ Random events? → stochastic-simulation
│
├─ PHYSICS SIMULATION
│ ├─ Formulate forces → differential-equations-for-games
│ ├─ Choose integrator → numerical-methods
│ ├─ Prevent explosions → stability-analysis
│ ├─ Multiplayer determinism? → chaos-and-sensitivity
│ └─ Real-time vs turn-based? → continuous-vs-discrete
│
├─ ECONOMY / RESOURCE SYSTEM
│ ├─ Formulate flows → differential-equations-for-games
│ ├─ Prevent inflation/deflation → stability-analysis
│ ├─ Discrete vs continuous? → continuous-vs-discrete
│ └─ Market randomness? → stochastic-simulation
│
├─ AI / CONTROL SYSTEM
│ ├─ Smooth behavior → feedback-control-theory
│ ├─ State machine analysis → state-space-modeling
│ ├─ Decision uncertainty → stochastic-simulation
│ └─ Prevent oscillation → stability-analysis
│
├─ MULTIPLAYER / DETERMINISM
│ ├─ Understand desync sources → chaos-and-sensitivity
│ ├─ Choose precision → numerical-methods
│ ├─ Discrete events? → continuous-vs-discrete
│ └─ State validation → state-space-modeling
│
└─ LOOT / RANDOMNESS SYSTEM
├─ Choose distributions → stochastic-simulation
├─ Prevent exploits → stochastic-simulation (anti-patterns)
├─ Pity systems → feedback-control-theory (setpoint tracking)
└─ Long-term balance → stability-analysis
Primary: differential-equations-for-games (Lotka-Volterra) Secondary: stability-analysis (prevent extinction), numerical-methods (RK4 integration) Optional: stochastic-simulation (random migration events) Time: 6-10 hours
Primary: differential-equations-for-games (spring-mass-damper) Secondary: numerical-methods (semi-implicit Euler), stability-analysis (prevent explosion) Optional: chaos-and-sensitivity (multiplayer physics) Time: 5-8 hours
Primary: differential-equations-for-games (resource flows) Secondary: stability-analysis (equilibrium analysis), continuous-vs-discrete (discrete items) Optional: stochastic-simulation (market fluctuations) Time: 6-9 hours
Primary: feedback-control-theory (PID camera) Secondary: differential-equations-for-games (spring-damper alternative) Optional: None (focused problem) Time: 2-4 hours
Primary: feedback-control-theory (intensity tracking) Secondary: differential-equations-for-games (smooth intensity changes) Optional: stochastic-simulation (spawn randomness) Time: 4-6 hours
Primary: state-space-modeling (state transitions) Secondary: None (discrete system) Optional: chaos-and-sensitivity (combo sensitivity to timing) Time: 3-5 hours
Primary: chaos-and-sensitivity (understand floating-point sensitivity) Secondary: numerical-methods (fixed-point arithmetic), continuous-vs-discrete (deterministic events) Optional: state-space-modeling (state validation) Time: 5-8 hours
Primary: numerical-methods (symplectic integrators for energy conservation) Secondary: differential-equations-for-games (Newton's gravity), chaos-and-sensitivity (three-body problem) Optional: None (focused on accuracy) Time: 6-10 hours
Primary: stochastic-simulation (probability distributions, pity systems) Secondary: None (focused problem) Optional: feedback-control-theory (pity timer as PID) Time: 3-5 hours
Primary: numerical-methods (Verlet integration, constraints) Secondary: differential-equations-for-games (spring forces), stability-analysis (prevent blow-up) Optional: None (standard cloth physics) Time: 5-8 hours
Primary: continuous-vs-discrete (choose discrete model) Secondary: state-space-modeling (action resolution), stochastic-simulation (hit/crit rolls) Optional: None (discrete system) Time: 4-6 hours
Primary: differential-equations-for-games (smooth weather transitions) Secondary: stochastic-simulation (random weather events), chaos-and-sensitivity (Lorenz attractor) Optional: numerical-methods (weather integration) Time: 5-8 hours
Primary: stability-analysis (currency sink/faucet equilibrium) Secondary: differential-equations-for-games (flow equations), stochastic-simulation (drop rates) Optional: continuous-vs-discrete (discrete items, continuous flows) Time: 6-9 hours
Primary: differential-equations-for-games (spring-damper suspension) Secondary: feedback-control-theory (PID for stability), numerical-methods (fast integration) Optional: stability-analysis (prevent oscillation) Time: 5-8 hours
Primary: state-space-modeling (reachability analysis) Secondary: None (graph search problem) Optional: chaos-and-sensitivity (sensitivity to initial state) Time: 3-5 hours
Skills in sequence:
Total time: 10-14 hours Result: Stable ecosystem with predictable long-term behavior
Skills in sequence:
Total time: 10-14 hours (12-17 with multiplayer) Result: Stable, deterministic physics at 60 FPS
Skills in sequence:
Total time: 10-13 hours Result: Self-regulating economy with predictable equilibrium
Skills in sequence:
Total time: 2-7 hours (depending on complexity) Result: Smooth, adaptive AI behavior
Skills in sequence:
Total time: 9-12.5 hours Result: Zero desyncs in multiplayer
simulation-tactics = HOW to implement simulation-foundations = WHY it works mathematically
Cross-references TO simulation-foundations:
Cross-references FROM simulation-foundations:
Cross-references:
Goal: Predator-prey system that doesn't crash
Steps:
Result: Ecosystem oscillates stably, no extinction
Goal: Uncharted-style camera follow
Steps:
Result: Smooth camera with no overshoot
Goal: Diablo-style loot with pity timer
Steps:
Result: Loot system with guaranteed legendary every 90 pulls
Problem: Shipping systems without analyzing equilibrium
Symptom: Game works fine for 10 hours, crashes at hour 100 (population explosion)
Fix: ALWAYS use stability-analysis for systems with feedback loops
Problem: Using explicit Euler for stiff systems
Symptom: Physics explodes at high framerates or with strong springs
Fix: Use numerical-methods decision framework (semi-implicit for physics)
Problem: Identical code on two machines, assuming identical results
Symptom: Multiplayer desyncs after 5+ minutes
Fix: Read chaos-and-sensitivity, understand floating-point divergence
Problem: Using uniform random for everything
Symptom: Players exploit patterns, loot feels unfair
Fix: Use stochastic-simulation to choose proper distributions
Problem: Using ODEs for turn-based combat
Symptom: 100× CPU overhead for no benefit
Fix: Read continuous-vs-discrete, use difference equations
Predictability:
Performance:
Robustness:
Maintainability:
The Golden Rule:
"Formulate first, tune second. Math predicts, empiricism confirms."
You should be able to: formulate systems as differential equations, analyze stability before shipping, choose correct numerical integrators, design PID controllers, understand deterministic chaos, apply proper probability distributions, prevent catastrophic failures, and debug simulations systematically.
After routing, load the appropriate specialist skill for detailed guidance:
Go build simulations with mathematical rigor.
development
Use when **managing the delivery of work** rather than building it — running a project or a program, not writing its code. Use when a team is busy but outcomes are not landing, when "when will it be done" has no defensible answer, when status is green every week until it is suddenly red, when dependencies surprise you, when a RAID log is a graveyard, or when several projects must be coordinated toward one outcome (a program). Lean/agile-leaning, honest about where program scale needs predictive structure. Pairs with `/axiom-planning` (turning one workstream into an implementation plan) and `/axiom-sdlc-engineering` (process maturity, requirements traceability, formal governance). Do not load for writing code, picking an architecture, or designing a single feature.
tools
--- name: using-product-management description: Use when a Claude is taking **standing ownership** of a software product and driving it end-to-end across many sessions — discovery, strategy, specs, delivery orchestration, and value validation — deciding *what to build, why, for whom,* and *whether it worked*, with continuity, decision provenance, and an authority boundary that escalates anything irreversible or outward-facing to the human owner. Owns the product disciplines: opportunity assessme
tools
Use when designing, implementing, or auditing an MCP (Model Context Protocol) server — tool API design, idempotency under agent retry, structured error envelopes agents can recover from, schema versioning across model drift, transport reliability (stdio / HTTP), output-shape and pagination discipline, and choosing between tools / resources / prompts / sampling. Also use when an MCP server's tools confuse agents, return unstructured errors, deadlock under concurrent calls, double-execute under retry, or lose state across reconnects. Do not use for general REST/GraphQL API design (use `/web-backend`), for client-side prompt engineering or tool-loop design (use `/llm-specialist`), for general in-process plugin architecture (use `/system-architect`), or for cryptographic-provenance audit trails (use `/audit-pipelines`).
development
Use when running **SQLite or DuckDB inside an application process** as the durable store — not as a development convenience but as the production database. Use when scaling an SQLite layer that worked at low concurrency and is now hitting SQLITE_BUSY, WAL bloat, lock contention, schema-migration ceremony, or correctness gaps under multi-process writers. Use when introducing DuckDB as an OLAP complement to an OLTP SQLite store, or when picking between the two for a new component. Pairs with `/web-backend` (the API surface above the DB) and `/audit-pipelines` (when the DB is also the audit trail). Do not load for server databases (Postgres, MySQL), key-value stores, or ORM choice in isolation.