lunco-sim

How to model a vehicle's behaviour in LunCoSim — making a spacecraft, lander, rover, or drone move, fly, drive, or land under its own control, and letting a person take over. USE THIS SKILL whenever the user asks, in plain words, things like: "how do I model this lander / rover?", "how do I make it fly (or drive, land, hover) itself?", "how do I add an autopilot / a control system / guidance / a GNC?", "how do I make it follow waypoints?", "how do I let the user take control?" or "why doesn't my controller / thruster respond?". Any request to model how a vehicle behaves under power, or to add/fix its self-driving or manual control, belongs here — the user will NOT know the internal terms. (For the agent mid-code, it also covers: a `.mo` control model, `lunco:simWires`, the `piloted` port, `external_throttle`, `possess`/`follow`, or a rumoca input that `set()` writes but that has no effect — and catch-yourself moments like putting control math in rhai, a bespoke mode flag, a self-wire, or reading the god-view

How to author and edit the 3D world in LunCoSim — load scenes, spawn objects, place/move/rotate them, and tune their properties, over the API. USE THIS SKILL whenever the user asks, in plain words, things like: "put a lander near that crater", "spawn a few rovers here", "load the Moon scene", "add some rocks / obstacles", "move / rotate / scale this", "set its colour / mass / material", "build a scene with X and Y", or "clear the scene and start over". Any request to assemble or edit what's IN the 3D world belongs here — the user won't say "USD" or "prim". (For the agent mid-code: `LoadScene` / `SpawnEntity` / `MoveEntity` / `SetObjectProperty`, an `entry_id` from the spawn catalog, a `.usda` file, coordinate placement, or "why did the gizmo grab the wrong thing?".) Project-specific and non-obvious: USD is the SOURCE OF TRUTH (projected to ECS — you edit the world by authoring it), the engine frame is fixed (Y-up, right-handed, −Z-forward, metres), `LoadScene` paths are relative to the assets root, spawnable

How to author an interactive tutorial / guided lesson / onboarding flow in LunCoSim. USE THIS SKILL whenever the user asks, in plain words, things like: "make a tutorial that teaches X", "add a guided lesson for the rover / the Modelica workbench", "walk a new user through Y step by step", "add an onboarding flow / first-run experience", "spotlight this button and explain it", or "add an objectives checklist that advances as the user does things". Any request to teach a user how to do something in-app, guided, belongs here. (For the agent mid-code: a `mission(me)` / `objective(...)`, `coach_step`, `hint` / `spotlight`, `requires_event:"cmd:*"`, `register_tutorial`, `StartTutorial`, `TutorialProgress`, or a file under `assets/tutorials/`.) Project-specific and non-obvious: a tutorial IS a single `.rhai` scenario (no scene-vs-script split), objectives advance on REAL user actions (a `cmd:*` bus event or a `done` predicate — never a timer), the HUD auto-publishes from `mission(me)`, and adding one is two steps (

How to write a scenario in LunCoSim — a rhai program attached to an entity that senses the world and drives it every tick. USE THIS SKILL whenever the user asks, in plain words, things like: "make the rover patrol these waypoints", "drive it to X then Y", "have it react when it reaches / enters / sees something", "coordinate these two vehicles", "run this mission / sequence / timeline", "make it do X after N seconds", "spawn some rovers and have them survey the area", or "why isn't my script doing anything / holding its state?". Any request to orchestrate behaviour, missions, waypoints, reactions, or multi-entity coordination belongs here — the user will NOT say "scenario" or "rhai". (For the agent mid-code, it also covers: an `on_tick` / `on_event` / `on_start` hook, `RunScenario`, `nav_to` / `run_plan` / a sequencer step, `emit` / a `TelemetryEvent`, `this`-state that resets or reads empty, a `find`/`cmd`/`query` verb, or `lunco:script` on a prim.) These rules are project-specific: rhai `fn`s are pure (they

How to assemble a complete multi-domain mission in LunCoSim — a vehicle (or fleet) whose geometry, physics, subsystem dynamics (GNC / power / thermal), and behaviour all cosimulate together, packaged as a Twin. USE THIS SKILL whenever the user asks, in plain words, things like: "build the lander+rover mission", "wire this Modelica model to that USD body", "make a spacecraft with a battery and thermal model that interact", "set up a full scenario with vehicles + behaviour", "package this as a Twin", or "connect the GNC output to the thruster". Any request to compose more than one domain (USD + Modelica + cosim + rhai) into one running system belongs here. (For the agent mid-code: `twin.toml`, `lunco:modelicaModel`, `lunco:simWires`, a sub-prim-per-domain layout, `SimConnection` / port wiring, a `lunco:scenario` orchestration prim, or `SetPorts`/`SetModelInput` fighting each other.) Project-specific and non-obvious: a vehicle is a USD FILE (not a Rust struct), each physical domain is its OWN sub-prim with its o

How to OBSERVE a running LunCoSim without asking the user to look — read live state, telemetry ports, cosim/Modelica variables, and viewport screenshots over the API. USE THIS SKILL whenever you need to answer "is it actually moving / working?", "what's the battery / altitude / speed / temperature?", "read the <X> port", "watch these signals over time", "what are the current variable values?", "did the cosim chain (Modelica → physics) work?", "what's in the scene right now?", or "show me what it looks like". Also trigger when you catch yourself about to `tail -f` the log and poll for a value, sleep-loop waiting for something to change, or ask the user "can you check?". The move is always: list entities → read the ports/variables → (watch if you need a series) → screenshot to confirm. It's the READ-side complement to test-via-api (which drives + verifies) and build-usd-scene (which authors). Project-specific: entity `api_id`s come from `list_entities`, ports are name-addressed and huge unless filtered, telemet

Orientation for the LunCoSim workspace — how the repo is laid out, which binaries exist, and WHEN to run each. USE THIS SKILL whenever you need to get your bearings: "which app do I run for X?", "how do I launch the sim / workbench / server?", "where does <feature> live?", "what crate handles Y?", "is there a headless mode?", "how do I run it without a window?", or any moment you're about to grep the whole tree to find where something is. Also trigger when you catch yourself about to run a bare `cargo run` (ambiguous — needs a target), confusing `lunica` with the main simulator, reaching for `pkill`, or guessing an API port. It's project-specific: there is NO `apps/` dir (binaries live inside crates), `lunica` is the *Modelica* workbench (not the flagship sim), `sandbox` / `luncosim` / `sandbox-server` are three different entry points into overlapping stacks, and the canonical API port is 4101. Authoritative indexes: docs/apps/README.md (every binary) and docs/crates-index.md (every library crate, grouped by

How to verify lunica changes end-to-end without asking the user to click. Trigger whenever a UI flow needs verification — a new diagram, a fix to drill-in, a screenshot to confirm a regression, a smoke test of any reflect-registered Event command. The workbench exposes a small HTTP API on `--api PORT`; this skill is the runbook for driving it from curl, capturing screenshots, diagnosing failures, and adding new commands when the existing surface isn't enough. Also trigger when you catch yourself about to `pkill lunica`, write a temp `.rs` test binary to inspect rumoca state, chain a `sleep 30 && tail` poll, or ask the user "can you check the screenshot?". The right move is always: send a command, take a screenshot, read it, decide.

LunCoSim UI architecture and panel implementation patterns. Use this skill whenever working on any user interface for the LunCoSim solar system simulation — adding panels, building dashboards, creating inspectors, spawning UI, telemetry displays, docking layouts, themes, or anything involving egui, lunco-workbench, or Panel. Also use when the user mentions typed commands, WidgetSystem, or 3D world-space UI. Even if the request seems simple (like "add a button"), use this skill because the panel registration and command patterns are project-specific and not obvious from Bevy alone.

Recipe for running Modelica models and building experiments/graphs in lunica (LunCoSim), driven from the HTTP API with curl. Trigger whenever you need to: launch the workbench, open/compile a Modelica model, run it live (interactive realtime) or as a fast batch, sweep parameters across many runs, read simulation results/trajectories, poke runtime inputs, or plot and compare runs — without asking the user to click. Covers the `--api` launch, the `POST /api/commands` envelope, the command + query catalog, run bounds/solver semantics, and reading experiment results. Prefer curl over the MCP `mcp__lunco__*` tools — the MCP bridge is often unavailable; every MCP tool has a curl equivalent shown here.

LunCoSim's centralised theming system. Use this skill whenever you are about to write, touch, or review UI code that involves a color, spacing value, rounding, or egui visual style — in any panel, overlay, widget, gizmo label, or diagram. Trigger on any `Color32::from_rgb`, hex color, `ui.style_mut()`, `visuals.*`, `ctx.set_visuals`, "dark mode", "light mode", "accent color", "highlight", palette tweak, mention of Catppuccin, or work on a typed block-diagram editor (wire colours, class-kind badges). Also trigger when adding a new panel that needs colors, or when the user asks to "restyle", "retheme", or "make it match". The rules here are project-specific — defaults from egui or Bevy alone will lead you to hard-code colors, which violates the Tunability Mandate.