LunCoSim

Design and analyze satellite constellations and distributed space architectures. Use this skill for Walker constellation patterns, coverage analysis, inter-satellite links, orbital shell design, collision avoidance, spectrum coordination, and deorbit compliance. Trigger for "constellation," "Walker pattern," "coverage analysis," "orbital shell," "inter-satellite link," "ISL," "revisit time," "ground coverage," "mega-constellation," or "distributed architecture."

Perform parametric cost estimation and ROM (Rough Order of Magnitude) costing for space missions. Use this skill to generate lifecycle cost estimates using CERs, compare launch costs, estimate operations budgets, and support cost-driven trade studies. Trigger this for "cost estimate," "ROM cost," "mission cost," "launch cost," "cost model," "lifecycle cost," "operations cost," or whenever a trade study needs cost as a Figure of Merit.

Perform Environmental Control and Life Support System (ECLSS) sizing and analysis for crewed spacecraft, stations, and habitats. Use this skill to size O₂ generation, CO₂ removal, water recovery, thermal/humidity control, and habitable volume. Trigger for "life support," "ECLSS," "crew systems," "O2 generation," "CO2 scrubbing," "water recycling," "habitable volume," "cabin pressure," or "crew consumables."

Define Flight Software (FSW) architectures, C&DH hardware requirements, and modern DevOps practices for space. Use this skill to size processors, estimate memory, plan software tasking, design FDIR strategies, plan CI/CD pipelines, set up simulation-in-the-loop testing, and define automated test infrastructure. Trigger this for "FSW architecture," "processor sizing," "data handling," "FDIR design," "onboard computer selection," "CI/CD for flight software," "simulation in the loop," "DevOps for space," or "automated FSW testing."

Design and assess ground segment infrastructure for space missions. Use this skill to plan mission control centers, ground station networks, launch facility requirements, GSE design, and range safety. Trigger for "ground systems," "mission control," "ground station," "GSE," "ground support equipment," "launch pad," "range safety," "mission operations center," "telemetry tracking," or "ground segment."

Perform In-Situ Resource Utilization (ISRU) sizing and feasibility analysis. Use this skill to evaluate resource extraction from planetary regolith, propellant production from local materials, water ice mining, and closed-loop resource economics. Trigger for "ISRU," "in-situ resources," "regolith processing," "propellant production," "water ice extraction," "lunar mining," "Mars ISRU," "Sabatier reactor," or "oxygen from regolith."

Assess spacecraft manufacturability, production planning, and fabrication trades. Use this skill for Design for Manufacturing (DFM), Design for Assembly (DFA), make-vs-buy decisions, production rate analysis, and vertical integration trades. Trigger for "manufacturability," "DFM," "DFA," "production rate," "make or buy," "fabrication," "assembly sequence," or "vertical integration."

Analyze reusability of launch vehicles and spacecraft systems. Use this skill to size recovery hardware, estimate refurbishment costs, model reuse degradation, and calculate flight-rate economics. Trigger for "reusability," "landing propellant," "recovery system," "refurbishment," "turnaround time," "flight rate economics," "booster recovery," or "reuse degradation."

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.

Instructions for downloading the ai4space repository, useful when the user wants to start working with the lunar base model.

Instructions for checking the available guides in the ai4space repository and reading them.