-
Notifications
You must be signed in to change notification settings - Fork 1
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.
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
Skills follow the format established by obra/superpowers:
---
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.
Skills are loaded via @ includes in GEMINI.md:
@./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.mdGemini 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 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.
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.
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.
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.
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.
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).
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.
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.
Six skills include an optional rag_reference(action="search", collection="<name>", ...) 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 | 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.