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."

Run fix/refactor work with parallel subagents split into non-overlapping file batches; agents never build or test — the coordinator verifies once at the end. Use for multi-finding fix sweeps (review reports, audits, migrations).

How to AUTHOR a `.usda` asset from scratch for LunCoSim — geometry, materials, physics, behaviour, tunable parameters, and getting it into the spawn catalog. USE THIS SKILL when the user asks to "build/model/make a <thing>" as a reusable asset: a habitat, a lander, a rover part, an antenna, a porthole, a tank; or says "add a material/shader to it", "make it collide", "give it physics", "make it spawnable", "expose that as a slider", "put a hole in it", "make this parametric". For the agent mid-code: writing `def Xform`/`def Mesh`/`def NurbsPatch`, `apiSchemas`, `material:binding`, `trimCurve:*`, `customData {min,max}`, `lunco:program:*`, `lunco:spawnable`. This is the AUTHORING side. To assemble a scene from assets that already exist use build-usd-scene; to drive the running app use test-via-api. Project-specific and non-obvious: `xformOpOrder` is MANDATORY (without it every `xformOp:*` is ignored and the prim sits at identity), `uRange`/`vRange` are never read, `customData` has no `doc` key, a scalar `

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.

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 a `LunCoProgram` prim.) These rules are project-specific: rhai `fn`s are pure (they ca

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, a `LunCoProgram` prim, 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-

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`, a `LunCoProgram` prim per domain, native USD connections, `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 program prim with its own `.mo`

How USD becomes the running 3D world in LunCoSim, and how to extend that translation. USE THIS SKILL whenever you are working ON the USD layer itself rather than authoring a scene with it: "add support for <USD prim type / new attribute>", "my attribute is being ignored", "the edit saved but nothing moved on screen", "why didn't my change undo / persist / replicate?", "how does a prim become an entity?", "where do I read this attribute?", "should this be a `lunco:` attribute or a standard schema?", or any time you're about to add a field to a prim, touch `lunco-usd*`, or write ECS state that ought to live in the document. Also trigger when tempted to "just set the component directly" or to accept a second spelling of an attribute so a file loads. (For AUTHORING scenes over the API — spawn/move/load — use `build-usd-scene` instead. This skill is the machinery underneath it.)

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

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.