# Skills Skills are behavioral guides injected into the agent's current context. Unlike agents (which spin up an isolated subprocess with their own turns), skills tell the agent how to approach a specific task inline — no separate context needed. ## Structure Each skill lives in its own directory under `skills/` with a `SKILL.md` file: ``` skills/ ├── stability-analysis/SKILL.md ├── motor-selection/SKILL.md ├── design-for-additive-manufacturing/SKILL.md ├── generate-structures/SKILL.md ├── modify-structures/SKILL.md ├── print-preparation/SKILL.md └── mass-calibration/SKILL.md ``` ## SKILL.md Format Skills follow the format established by [obra/superpowers](https://github.com/obra/superpowers): ```markdown --- name: skill-name description: One-line trigger description — shown in skill index --- # Skill Title ## Overview Brief summary and core principle. ## When to Use Clear trigger conditions. ## Steps Step-by-step process. ## Red Flags What to stop and check when things go wrong. ## Quick Reference Summary table or checklist. ``` The `description` frontmatter field is what appears in the skill index shown to the agent. Make it specific enough to trigger the right skill at the right time. ## Loading into Context ### Gemini CLI Skills are loaded via `@` includes in `GEMINI.md`: ```markdown @./skills/stability-analysis/SKILL.md @./skills/motor-selection/SKILL.md @./skills/design-for-additive-manufacturing/SKILL.md @./skills/generate-structures/SKILL.md @./skills/modify-structures/SKILL.md @./skills/print-preparation/SKILL.md @./skills/mass-calibration/SKILL.md ``` Gemini CLI resolves each `@` path and injects the file content into the agent's context at session start. This means all seven skills are always available without the agent needing to call a tool. ### Claude Code Claude Code loads skills declared in the plugin manifest (`.claude-plugin/plugin.json`). All seven skills are registered and available to the agent automatically when the plugin is installed. ## Available Skills ### stability-analysis **Trigger:** `min_stability_cal` outside 1.0–1.5, or null after simulation. Guides the agent through diagnosing and fixing stability issues — reading CP/CG from `openrocket_component` (action="read"), computing stability manually when null, and applying targeted fixes (fin resizing, mass repositioning) one change at a time. ### motor-selection **Trigger:** User wants motor recommendations, or initial motor selection for a design. Covers estimating required impulse from target apogee, querying the motor database with the right filters, checking thrust-to-weight ratio off the launch rod, and simulating candidates before committing. ### design-for-additive-manufacturing **Trigger:** CAD phase begins and the chosen manufacturing method is additive (FDM or SLA). Translates the OpenRocket logical component tree into a physical parts manifest (`gui/component_tree.json`) tailored for 3D printing. Makes per-component fate decisions: which OR components become printed parts, which are fused into adjacent parts, which are purchased off-the-shelf, and which are skipped entirely. Applies AM-specific geometry patterns like local wall thickening (replacing separate centering rings), integrated fins (with root fillets clamped to `min(thickness/2 * 0.9, 3 mm)` to avoid OCC failures), and integral aft shoulders (replacing separate couplers). Red flags include missing TubeCouplers between body tube sections (produces flat-ended tubes that can't assemble), infeasible fillet radii, and wall thickness below 1.5 mm. ### generate-structures **Trigger:** A `gui/component_tree.json` exists and needs Pass 1 (base geometry) via cadsmith. The **Pass 1 CAD execution skill**. Reads the parts manifest, writes one parametric Python script per part to `cadsmith/source/`, executes each via `cadsmith_run_script` to produce STEP files in `cadsmith/step/`, then generates `gui/assembly.json` for the 3D viewer via `cadsmith_assembly`. Documents build123d API patterns (hollow tube, revolve, polar array, fused extrusion) and the canonical script structure with portable relative paths. Includes an **iterative build-check loop** — multi-feature parts are built one feature at a time, rendered and verified after each operation, so orientation bugs (wrong extrude direction, shoulder on wrong end, flipped fin sweep) are caught immediately instead of at the end. Covers all 6 OpenRocket nose cone shapes (conical, ogive, ellipsoid, parabolic, power, haack) with profile formulas, and documents the fin root fillet pattern (1 mm root inset, OCC seam edge exclusion, fillet radius clamping). Render labels use part-local coordinates (not rocket fore/aft) to avoid misinterpretation. ### modify-structures **Trigger:** `generate-structures` (Pass 1) has completed and at least one part has a non-empty `modifications` list in the manifest. The **Pass 2 CAD execution skill** — applies detail features (radial heat-set holes, through-hole clearance, pockets, vents, camera mounts) to the base STEP files produced by Pass 1. Reads each part's `modifications` list, imports the existing base STEP, applies operations in order, and overwrites the STEP in place. Does not regenerate base geometry — if a modification would require changing the shell, update the manifest's `features` block and re-run Pass 1. Skipped entirely when every part's `modifications` list is empty (the default for a freshly generated DFAM manifest, since retention defaults to `"none"`). Documents modification recipes for `radial_holes`, `radial_through_holes`, and reserves placeholders for future kinds (`rectangular_pocket`, `cylindrical_pocket`, `rail_button_mount`). ### print-preparation **Trigger:** STEP files are ready, user wants to prepare parts for printing. Covers per-part print orientation, infill settings, material selection (PETG vs PLA), and calling `prusaslicer_slice`. Includes guidance on avoiding common mistakes like printing body tubes flat or using full infill on nose cones. After every part is sliced, hands off to `mass-calibration` to feed real filament weights back into the simulation. ### mass-calibration **Trigger:** STEP files have been sliced, `filament_used_g` values are available, and the design needs to be re-verified before committing to a build. Closes the simulation → CAD → slicer loop. Printed PLA/PETG parts routinely weigh 2–4× the OpenRocket material defaults (usually cardboard), so a design that simulated stable with defaults can become unstable once built. The skill walks through collecting measured weights per printed part, applying each as an `override_mass_kg` via `openrocket_component` update (dividing grams by 1000), re-running `openrocket_simulate`, and comparing baseline vs. calibrated stability. Documents the kg-vs-g gotcha, the OpenRocket persistence quirk around disabled overrides, and common fixes when calibration pushes stability out of range. ## RAG Hookpoints Six skills include an optional `rag_reference(action="search", collection="", ...)` query before falling back to their static heuristic. The goal is to enrich generic rules with real-world data when available. | Skill | Collection | When | |-------|-----------|------| | `stability-analysis` | `stability_notes` | Before generic diagnosis | | `motor-selection` | `motor_reviews` | Before simulating candidates | | `design-for-additive-manufacturing` | `cad_examples` | Before finalising the manifest on non-standard designs | | `generate-structures` | `cad_examples` | For feature types or build123d patterns not in the inline recipe table | | `modify-structures` | `cad_examples` | For modification kinds not in the recipe reference | | `print-preparation` | `print_gotchas` | For unusual parts (thin walls, overhangs, bridges) | **Graceful-empty contract:** every hookpoint proceeds silently if the collection is empty or not indexed. Collections are populated via `rag_reference(action="index", ...)` — until indexed, the skill's built-in heuristic is the fallback. `mass-calibration` has no hookpoint because it's a purely numeric operation. ## Skills vs Agents | | Skills | Agents | |---|--------|--------| | Context | Injected into current session | Isolated subprocess | | Turns | Inline — no separate turn budget | Own `max_turns` budget | | Best for | Focused decisions and workflows | Long multi-step pipelines | | Invocation | Always in context via plugin manifest | Explicitly delegated to | The three domain agents (`openrocket`, `cadsmith`, `prusaslicer`) handle full pipeline phases. Skills handle specific decisions that come up within a session — stability diagnosis, motor selection, dimension translation, or slice settings.