Update to Simulator.Company

{
  "description": "Simulator.Company behaviour simulation specialist (\"what if\" on a graph). Use when the user wants to simulate, forecast or compare scenarios on a layer: describe how actors behave, change parameters (price, capacity, delivery time, growth, AI share), play model time forward and compare metrics. Any graph works — a company, a process, infrastructure, a supply chain — and accounts can hold any quantity (money, items, hours, slots).\nTrigger on any of these intents: — \"what if\", \"simulate\", \"forecast\", \"scenario\", \"compare scenarios\", \"how many will\n  we finish\", \"where is the bottleneck\", \"what will it cost in 3 months\".\n— \"симуляция\", \"смоделируй\", \"прогони симуляцию\", \"что будет если\", \"прогноз\",\n  \"сравни сценарии\", \"проверь модель\", \"симуляція\", \"змоделюй\", \"що буде якщо\".\n— the user points at a behaviour model (`model.yaml`, `scenarios.yaml`) or a layer YAML\n  file and asks to run or check it. Use these tools for that, not other simulation CLIs.\nTools: simulationCheck, simulationRun, simulationSnapshot (read-only; nothing is written to Simulator).\n",
  "included_files": [],
  "name": "simulator-simulate",
  "skill_md_contents": "---\nname: simulator-simulate\ndescription: >\n  Simulator.Company behaviour simulation specialist (\"what if\" on a graph). Use when the\n  user wants to simulate, forecast or compare scenarios on a layer: describe how actors\n  behave, change parameters (price, capacity, delivery time, growth, AI share), play model\n  time forward and compare metrics. Any graph works — a company, a process, infrastructure,\n  a supply chain — and accounts can hold any quantity (money, items, hours, slots).\n\n  Trigger on any of these intents:\n  — \"what if\", \"simulate\", \"forecast\", \"scenario\", \"compare scenarios\", \"how many will\n    we finish\", \"where is the bottleneck\", \"what will it cost in 3 months\".\n  — \"симуляция\", \"смоделируй\", \"прогони симуляцию\", \"что будет если\", \"прогноз\",\n    \"сравни сценарии\", \"проверь модель\", \"симуляція\", \"змоделюй\", \"що буде якщо\".\n  — the user points at a behaviour model (`model.yaml`, `scenarios.yaml`) or a layer YAML\n    file and asks to run or check it. Use these tools for that, not other simulation CLIs.\n  Tools: simulationCheck, simulationRun, simulationSnapshot (read-only; nothing is written\n  to Simulator).\n---\n\n# Simulate a Simulator graph\n\nThe simulation engine runs inside this MCP server. It reads a layer (actors, links, account\nvalues), runs behaviour rules in model time for each scenario and returns metrics. It never\nwrites to Simulator: the source layer is only read.\n\nFormat of models and scenarios: `$CLAUDE_PLUGIN_ROOT/docs/simulation/model-format.md` — read\nit before writing a model. Worked examples: `$CLAUDE_PLUGIN_ROOT/docs/simulation/examples/`.\n\n## 1. Pick the graph — always ask\n\nIf a tool answers \"not authenticated\", call `login` and repeat the call.\n\n- If the UI context has `activeLayer`, offer it first; otherwise help the user find a layer\n  (`getLayerActorsPaginated`, `layerStats`) and confirm which one.\n- Look at what is there before modelling: `simulationSnapshot(layerId, period?)` writes\n  `<layerId>.sim.yaml` with every actor, link and account value the simulation will see.\n- Account values that accumulate over time (bills, turnover) need `period` (e.g. `30d`):\n  values become the turnover of the last period. Check for accounts that are breakdowns of\n  the same total (by service, region, operation): summing them counts one bill many times.\n\n## 2. Write the model with the user\n\nAsk only what changes the result: which actors behave and how, what the scenarios change,\nthe horizon, what to measure. Show the rules in plain words before running, and label\nassumptions (durations, probabilities, growth rates) as assumptions.\n\nA model is YAML (spec §5): `value_types`, `refs`, `params`, `horizon`, `initial_events`,\n`behaviors.<actor type>.<event>: [actions]`, `metrics`, `goals`, optional helper `actors`\n(people or resources that are not on the graph). Actor types are form titles.\n\nRules of thumb:\n- Money and other quantities that only move between actors: `conserved: true` and `transfer`.\n  Things that only grow (hours worked, missed sales): not conserved, `add`.\n- Capacity (people, machines, slots): an integer conserved account on a resource actor plus\n  `enqueue` / `release`.\n- Processes drawn as graphs: steps are actors, transitions are links; an application walks\n  with `pick(where(actor(self.at).children(), …))` (see examples/process_flow).\n- Never write a key named `on:` (YAML reads it as true); use `actor:`.\n\n## 3. Check, then run\n\n    simulationCheck(model, scenarios, layerId | graphPath)\n\n`simulationRun` checks the model too and refuses a model with errors. Warnings (an event\nnobody handles, a param typo) usually mean the model does not do what the user thinks.\n\n    simulationRun(model, scenarios, layerId, period?, scenario?, runs?, goals?, logEvents?)\n\n- The model has randomness (`rand()`, `pick`, `chance`, a `decide` without a `rule`): never\n  report a single run. Use `runs: 100` and report the median, the 10–90 % range and the share\n  of runs meeting each goal.\n- These numbers cover completed runs only (`runs completed/total` in the table). When runs\n  failed or stopped before the horizon (`stopped_by_time`, `stopped_by_limit`), say how many\n  and why (the lines under the table): a scenario that stops early is not cheaper or faster,\n  it is unfinished. Raise `timeLimit` or shorten the horizon rather than compare it.\n- A warning that the snapshot was written by v2.9.0 means its numbers are text: re-take it\n  with `simulationSnapshot(layerId, overwrite: true)` before trusting any result.\n- No randomness: one run is exact; say so.\n- `logEvents: 30` returns the first processed events — use it to explain why a result\n  happened.\n\n## 4. Explain\n\n- Lead with the answer, then the comparison table. Name the scenario and metric behind\n  every number; separate results from assumptions.\n- A range from `runs` is spread over the model's random outcomes, not a confidence interval\n  for the real world.\n- The engine computes the consequences of the rules exactly (decimal arithmetic, conserved\n  totals checked on every step); whether the rules match reality is a separate question,\n  best answered by comparing with history.\n"
}