plugins/bravos-simulation-tactics/skills/using-simulation-tactics/SKILL.md
Router skill - analyze requirements and direct to appropriate tactics
npx skillsauth add tachyon-beep/skillpacks using-simulation-tacticsInstall 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.
This is the PRIMARY ROUTER META-SKILL for the simulation-tactics skillpack. It teaches you how to:
This skill does NOT teach simulation implementation details. It teaches DECISION MAKING: which skill to use, when, and why.
Use this meta-skill when:
IMPORTANT: All reference sheets are located in the SAME DIRECTORY as this SKILL.md file.
When this skill is loaded from:
skills/using-simulation-tactics/SKILL.md
Reference sheets like physics-simulation-patterns.md are at:
skills/using-simulation-tactics/physics-simulation-patterns.md
NOT at:
skills/physics-simulation-patterns.md ← WRONG PATH
Before routing, understand what each skill provides:
What it teaches: The fundamental trade-off between full simulation and approximation/faking When to route: ALWAYS FIRST - determines if you even need simulation Key question: "Do I simulate this, fake it, or use a hybrid approach?"
What it teaches: Rigid bodies, vehicles, cloth, fluids, integration methods When to route: Need realistic physics for vehicles, ragdolls, destructibles, or fluid dynamics Key question: "Does this need real-time physics simulation?"
What it teaches: FSM, behavior trees, utility AI, GOAP, agent behaviors When to route: Need intelligent agent behavior (enemies, NPCs, units) Key question: "Do agents need to make decisions and act autonomously?"
What it teaches: A*, navmesh, flow fields, traffic simulation, congestion When to route: Need agents to navigate environments or simulate traffic Key question: "Do entities need to find paths or simulate traffic flow?"
What it teaches: Supply/demand, markets, trade networks, price discovery When to route: Need economic systems (trading, markets, resources) Key question: "Does the game involve trade, economy, or resource markets?"
What it teaches: Predator-prey dynamics, food chains, population control When to route: Need living ecosystems with wildlife populations Key question: "Do I need animals/plants that breed, eat, and die naturally?"
What it teaches: Boids, formations, social forces, LOD for crowds When to route: Need large groups moving together (crowds, flocks, armies) Key question: "Do I need many entities moving as a coordinated group?"
What it teaches: Day/night cycles, weather systems, seasonal effects When to route: Need atmospheric effects or time-based gameplay Key question: "Does the game need time progression or weather?"
What it teaches: Profiling, spatial partitioning, LOD, time-slicing, caching When to route: Performance problems with existing simulation Key question: "Is my simulation too slow?"
What it teaches: Systematic debugging, desync detection, determinism, chaos prevention When to route: Simulation behaves incorrectly, chaotically, or unpredictably Key question: "Is my simulation broken, desyncing, or chaotic?"
Follow this decision tree for ALL simulation tasks:
┌─────────────────────────────────────────────────────────────┐
│ STEP 1: ALWAYS START HERE │
│ ═══════════════════════════════════════════════════════════ │
│ Route to: simulation-vs-faking │
│ │
│ Questions to ask: │
│ • Do I need to simulate this at all? │
│ • What level of detail is required? │
│ • What can I fake or approximate? │
│ • Where is the player's attention focused? │
│ │
│ This prevents the #1 mistake: over-engineering systems │
│ that could be faked. │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ STEP 2: ROUTE TO SPECIFIC SIMULATION TYPE(S) │
│ ═══════════════════════════════════════════════════════════ │
│ Identify which simulation domains apply: │
│ │
│ Physics domain → physics-simulation-patterns │
│ AI domain → ai-and-agent-simulation │
│ Pathfinding domain → traffic-and-pathfinding │
│ Economy domain → economic-simulation-patterns │
│ Ecosystem domain → ecosystem-simulation │
│ Crowds domain → crowd-simulation │
│ Atmosphere domain → weather-and-time │
│ │
│ Multiple domains? Route to ALL applicable skills. │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ STEP 3: IF PERFORMANCE ISSUES ARISE │
│ ═══════════════════════════════════════════════════════════ │
│ Route to: performance-optimization-for-sims │
│ │
│ Triggers: │
│ • Frame rate drops below 60 FPS │
│ • Profiler shows simulation bottleneck │
│ • Agent count causes slowdown │
│ • Simulation gets expensive at scale │
│ │
│ WARNING: Don't route here prematurely! │
│ Premature optimization wastes time. │
└─────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────┐
│ STEP 4: IF BUGS/CHAOS OCCUR │
│ ═══════════════════════════════════════════════════════════ │
│ Route to: debugging-simulation-chaos │
│ │
│ Triggers: │
│ • Simulation behaves chaotically/unpredictably │
│ • Multiplayer desyncs │
│ • Physics explosions or NaN values │
│ • Agents stuck or behaving erratically │
│ • Systems producing nonsensical results │
│ │
│ This is a REACTIVE skill - only use when broken. │
└─────────────────────────────────────────────────────────────┘
Principle 1: simulation-vs-faking is ALWAYS step 1
Principle 2: Multiple domains are common
Principle 3: Optimization comes AFTER implementation
Principle 4: Debugging is reactive, not proactive
| User Need | Primary Skill | Secondary Skills | Also Consider | |-----------|---------------|------------------|---------------| | Vehicle physics | physics-simulation-patterns | - | performance-optimization (if many vehicles) | | City traffic | traffic-and-pathfinding | simulation-vs-faking | performance-optimization (scale to 10k) | | NPC AI | ai-and-agent-simulation | simulation-vs-faking | traffic-and-pathfinding (if NPCs move) | | RTS units | ai-and-agent-simulation, traffic-and-pathfinding | crowd-simulation (formations) | performance-optimization (1000+ units) | | Trading system | economic-simulation-patterns | simulation-vs-faking | ai-and-agent-simulation (NPC traders) | | Wildlife/hunting | ecosystem-simulation | ai-and-agent-simulation | simulation-vs-faking (detail level) | | Crowds | crowd-simulation | simulation-vs-faking | performance-optimization (scale) | | Day/night | weather-and-time | simulation-vs-faking | - | | Weather effects | weather-and-time | physics-simulation-patterns (wind) | - | | Pathfinding | traffic-and-pathfinding | simulation-vs-faking | performance-optimization (many agents) | | Flocking birds | crowd-simulation | simulation-vs-faking | performance-optimization (LOD) | | Ragdolls | physics-simulation-patterns | - | debugging-simulation-chaos (stability) | | Performance issue | performance-optimization-for-sims | (original implementation skill) | debugging-simulation-chaos (if bug) | | Physics explodes | debugging-simulation-chaos | physics-simulation-patterns | - | | Ecosystem collapse | debugging-simulation-chaos | ecosystem-simulation | - | | Multiplayer desync | debugging-simulation-chaos | (any affected skills) | - |
Use this flowchart for quick routing decisions:
START: User describes simulation need
↓
[Is this DEFINITELY about simulation?]
├─ No → Don't use simulation-tactics at all
└─ Yes → Continue
↓
[Route to: simulation-vs-faking]
"Do I simulate, fake, or hybrid?"
↓
[Identify domain(s)]
├─ Physics? → physics-simulation-patterns
├─ AI/Agents? → ai-and-agent-simulation
├─ Pathfinding? → traffic-and-pathfinding
├─ Economy? → economic-simulation-patterns
├─ Ecosystem? → ecosystem-simulation
├─ Crowds? → crowd-simulation
└─ Weather/Time? → weather-and-time
↓
[Is simulation ALREADY implemented?]
├─ No → Use identified skill(s) to implement
└─ Yes → Continue
↓
[Is there a PERFORMANCE problem?]
├─ Yes → performance-optimization-for-sims
└─ No → Continue
↓
[Is there a BUG/CHAOS problem?]
├─ Yes → debugging-simulation-chaos
└─ No → Implementation complete!
These are the mistakes that waste the most time. Learn to recognize them.
Symptom: Over-engineered simulation that could have been faked
Example:
Fix: ALWAYS route to simulation-vs-faking first. Ask "Will player notice if I fake this?"
Cost of mistake: Weeks of wasted work, ongoing performance burden
Symptom: Routing to performance-optimization-for-sims before implementation is complete
Example:
Fix: Profile first, optimize later. Only route to performance-optimization-for-sims when:
Cost of mistake: Wasted time optimizing code that might change, or optimizing the wrong thing
Symptom: Trying to fix bugs by changing random things, routing to implementation skills instead of debugging-simulation-chaos
Example:
Fix: When simulation is broken, ALWAYS route to debugging-simulation-chaos first. Identify root cause before attempting fixes.
Cost of mistake: Bug persists, or you "fix" symptom without addressing cause
Symptom: Using ai-and-agent-simulation when you need traffic-and-pathfinding, etc.
Example:
Fix: Understand what each skill covers. Pathfinding is NOT AI. Physics is NOT movement. Crowds are NOT flocking AI.
Cost of mistake: Learning wrong techniques for your problem
Symptom: Building dependent system before foundation
Example:
Fix: Follow the dependency order in multi-skill workflows. Foundation first, then dependent systems.
Cost of mistake: Rework when foundation changes breaks dependent systems
Symptom: Building single-player simulation without considering multiplayer needs
Example:
Fix: If multiplayer is planned, route to debugging-simulation-chaos early to learn determinism requirements.
Cost of mistake: Complete rewrite to fix desyncs
Symptom: Trying to use every skill when only 1-2 are needed
Example:
Fix: Route to ONLY the skills you actually need. More skills = more complexity.
Cost of mistake: Wasted time learning and implementing unnecessary systems
For detailed examples and workflows, see:
After routing, load the appropriate specialist skill for detailed guidance:
Now route confidently to the specific skills you need!
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.
development
Use when designing or critiquing the structure of a staged procedure — a wizard, configuration flow, troubleshooting tree, training curriculum, multi-stage approval pipeline, decision pipeline, or any decomposition of expert work into composable stages. Use for both producer work (build the decomposition) and critic work (audit a proposed decomposition). Use when reasoning about capacity, bottlenecks, or soundness of a procedural flow. Do not use for implementation-plan critique of code changes (use `/axiom-planning` instead), for execution-time dynamics (use `/simulation-foundations`), or for rendering an already-designed procedure as docs or UI (use `/technical-writer` or `/ux-designer`).
testing
Use when the user wants to draft fiction or creative nonfiction prose, get craft critique on prose they have written, or plan story structure, outline, or premise. Workshop-voiced. Three explicit modes (draft, critique, plan) and the router will refuse to begin work without a declared mode.