菜单
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).
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
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.)
| name | subagent-batches |
| description | 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). |
Workflow for executing many independent code changes (e.g. findings from a review report) with parallel subagents.
Prioritize first, run second. Read the source reports yourself, group findings, present the batch plan to the user, get agreement on scope BEFORE launching any fix agent. Deferred scopes (e.g. multiplayer/RBAC while focused on singleplayer) get a comment-only batch, not fixes.
Split work into lots with disjoint file ownership. Each agent gets an explicit list of files it owns and the instruction "other agents own other files — do not touch anything else." No two agents in flight may share a file. Group by file/crate proximity, not by finding severity — the lot boundary is the file set.
Agents never run builds or tests. Every agent prompt includes: "do NOT run cargo, tests, or builds of any kind; do not commit." The coordinator runs ONE cargo check -j=2 + one test pass at the very end, after all batches land (or when the user asks). This avoids N agents compiling the same workspace concurrently.
Launch each batch's agents in a single message (parallel tool calls). Batches are sequential rounds; agents within a batch are parallel.
New batches must avoid files owned by still-running agents. Track ownership; a finished agent's files are free for the next round.
Every fix-agent prompt contains:
-j=2).