forgecad 0.10.2 → 0.10.4

package/dist-skill/docs/generated/viewport.md

@@ -79,7 +79,7 @@ return b;
 
 #### `scene(options: SceneOptions): void` — Configure the scene environment for the current script execution.
 
-Controls camera, named render views, guided journeys, lighting, background, fog, environment maps, post-processing, capture defaults, and the joint-control helper overlay (`jointOverlay` — axis arrows and arc indicators, renderer-only). Multiple `scene()` calls merge per-key — later values win — so configuration can be split across calls.
+Controls camera, named render views, guided journeys, lighting, background, fog, environment maps, capture defaults, and the joint-control helper overlay (`jointOverlay` — axis arrows and arc indicators, renderer-only). Multiple `scene()` calls merge per-key — later values win — so configuration can be split across calls.
 
 Two behavioral cliffs:
 
@@ -90,7 +90,7 @@ Named views are repeatable cameras checked in with the model code. Canonical sha
 
 Journeys are ordered `steps`, each focusing a returned object by name/tree path with an optional caption and camera. In the viewer they are opt-in (an Explore control; the camera does not move until started). Inspect resolved targets with `forgecad run --journeys`.
 
-Post-processing (`bloom`, `vignette`, `grain`) is browser-only; the CLI applies camera, lights, background, fog, and `toneMappingExposure` but skips shader effects.
+Post-processing is disabled for now while the browser EffectComposer flicker path is being rebuilt. Existing scripts that pass `postProcessing` continue running, but the option is not part of the active scene API.
 
 All numeric values accept `param()` expressions.
 
@@ -109,7 +109,6 @@ scene({
     { type: 'directional', position: [50, -30, 200], color: '#ffd60a', intensity: 1.2 },
   ],
   fog: { color: '#000814', near: 100, far: 450 },
-  postProcessing: { bloom: { intensity: param('bloom', 1.5, 0, 4) } },
   jointOverlay: { axisColor: '#13dfff', arcColor: '#ff7a1a' },
 });
 ```
@@ -120,7 +119,7 @@ scene({
 |--------|------|-------------|
 | `capture?` | `SceneCaptureConfig` | Default capture parameters for `forgecad capture` — CLI flags override these. |
 
-Also: `background?: string | SceneBackgroundGradient`, `camera?: SceneCameraConfig`, `views?: Record<string, SceneViewInputConfig>`, `journeys?: Record<string, SceneJourneyConfig>`, `lights?: SceneLightConfig[]`, `environment?: SceneEnvironmentConfig`, `fog?: SceneFogConfig`, `postProcessing?: ScenePostProcessingConfig`, `ground?: SceneGroundConfig`.
+Also: `background?: string | SceneBackgroundGradient`, `camera?: SceneCameraConfig`, `views?: Record<string, SceneViewInputConfig>`, `journeys?: Record<string, SceneJourneyConfig>`, `lights?: SceneLightConfig[]`, `environment?: SceneEnvironmentConfig`, `fog?: SceneFogConfig`, `ground?: SceneGroundConfig`.
 
 `SceneBackgroundGradient`: `{ top: string, bottom: string }`
 
@@ -174,14 +173,6 @@ Also: `type: SceneLightType`, `color?: string`, `intensity?: number`, `position?
 - `density?: number` — Exponential fog density (if set, uses FogExp2 instead of linear Fog)
 - Also: `color?: string`.
 
-`ScenePostProcessingConfig`: `{ bloom?: SceneBloomConfig, vignette?: SceneVignetteConfig, grain?: SceneGrainConfig, toneMappingExposure?: number }`
-
-`SceneBloomConfig`: `{ intensity?: number, threshold?: number, radius?: number }`
-
-`SceneVignetteConfig`: `{ darkness?: number, offset?: number }`
-
-`SceneGrainConfig`: `{ intensity?: number }`
-
 **`SceneGroundConfig`**
 
 | Option | Type | Description |

package/dist-skill/docs/guides/inspection-bundles.md

@@ -5,7 +5,7 @@ skill-order: 2
 
 # Inspection Bundles — Evidence Contract
 
-`forgecad inspect <family> <mode>` writes a deterministic bundle: evidence PNGs under `evidence/<type>/` plus a root `manifest.json`. **The manifest is the authoritative contract** — take file paths, encodings, per-view ranges, thresholds, tolerances, and identity maps from it; never hard-code bundle layout or infer object identity from object order. The PNGs are a visual index for locating findings, not standalone artifacts. Command tree, flags, and `--focus`/`--hide` filtering live in `docs/permanent/CLI.md` and `forgecad inspect evidence`; the inspection workflow lives in the `forgecad-render-inspect` skill. Model-authored `scene()` background, lights, fog, and exposure are ignored for inspection captures so evidence stays stable; named scene views remain available via `--view`.
+`forgecad inspect <family> <mode>` writes a deterministic bundle: evidence PNGs under `evidence/<type>/` plus a root `manifest.json`. **The manifest is the authoritative contract** — take file paths, encodings, per-view ranges, thresholds, tolerances, and identity maps from it; never hard-code bundle layout or infer object identity from object order. The PNGs are a visual index for locating findings, not standalone artifacts. Command tree, flags, and `--focus`/`--hide` filtering live in `docs/skill/CLI.md` and `forgecad inspect evidence`; the inspection workflow lives in the `forgecad-inspect-model` skill. Model-authored `scene()` background, lights, fog, and exposure are ignored for inspection captures so evidence stays stable; named scene views remain available via `--view`.
 
 Manifest evidence keys are evidence-oriented and stable for bundle readers: e.g. `fit interference` writes `manifest.evidence.collisions`, `physical components` writes `manifest.evidence.connectivity`.
 

package/dist-skill/library/README.md

@@ -8,16 +8,12 @@ forgecad skill install
 
 The installed skill names are namespaced to avoid collisions with a user's existing generic skills.
 
-- `forgecad-3d-reconstruction`
-- `forgecad-blockout-model`
-- `forgecad-component-model`
-- `forgecad-high-level-spec`
-- `forgecad-image-replicator`
-- `forgecad-lld`
-- `forgecad-make-a-model`
-- `forgecad-model-grader`
-- `forgecad-prepare-prompt`
-- `forgecad-project`
-- `forgecad-reconstruction-benchmark`
-- `forgecad-render-inspect`
-- `forgecad-visual-spec`
+- `forgecad-build-model`
+- `forgecad-design-spec`
+- `forgecad-grade-model`
+- `forgecad-image-prompt`
+- `forgecad-inspect-model`
+- `forgecad-project-sync`
+- `forgecad-reconstruct-cad-file`
+- `forgecad-reconstruct-from-images`
+- `forgecad-verify-mujoco`

package/dist-skill/library/{forgecad-make-a-model → forgecad-build-model}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: forgecad-make-a-model
-description: Create manufacture-realistic prototype ForgeCAD (.forge.js) models in the active CAD project. Handles file placement, invokes the forgecad skill for API guidance, and validates the result.
+name: forgecad-build-model
+description: Build or edit a manufacture-realistic `.forge.js` model in a project, then validate it with run, render, inspect, and export evidence.
 forgecad-public: true
 ---
 
-# Make a Model
+# Build Model
 
 Create new ForgeCAD models in the user's active ForgeCAD project.
 
@@ -79,7 +79,17 @@ For any mechanism (linkage, hinge, slider, suspension, gripper, drawer), the rig
 
 A mechanical script is not done when it merely looks assembled. Every visible piece needs a physical reason to be where it is: fused material, contact faces, a screw stack, a pin in a bore, a tab in a slot, a gasket on a land, a bearing in a seat, a cable in a channel, or a named intentional ghost.
 
-- Bespoke fixed assemblies: build each part in local coordinates, pick one root, place every touching part with `matchTo()`, verify each mate with `verify.connectorDistance`. Final `translate()` calls are not assembly contracts.
+For multi-part assemblies, the component model is mandatory:
+
+- Parts build at origin in their own local coordinates. They do not know final assembly-space offsets, sibling dimensions, or world placement.
+- A part's public interface is `shape` plus connectors and metadata, e.g. `return { shape, boltPattern, pinionZ }`. Declare mating faces with `.withConnectors({})`; axes point outward, with prismatic slide axes as the explicit exception.
+- The parent assembly chooses the root and positions every structural part through connectors, `connect()`, `match()`, or `matchTo()`. Final `translate()` calls are not assembly contracts.
+- Data flows down through `require('./part.forge.js', params)` overrides and up through returned metadata. Siblings never import each other; the parent routes shared decisions and measured outputs.
+- Default to one file for a project-specific assembly. Split only for cross-project reuse, independent subassemblies, or when a file grows past roughly 300 lines. Never create `shared-dims.js` just to coordinate siblings.
+
+Reject these shortcuts on sight: sibling `require()`, assembly-space coordinates inside a part, `translate()` used to position a structural assembly member, `console.log` + `if` validation instead of `verify.*`, and bare `connector.neutral()` outside a reusable component library with compatibility checks.
+
+- Bespoke fixed assemblies: build each part in local coordinates, pick one root, place every touching part with `matchTo()`, verify each mate with `verify.connectorDistance`.
 - Manual joint frames (`addFixed`/`addRevolute`/`addPrismatic` with a hand-built `frame:`) are scaffolding, not contracts. Before delivery, convert mating interfaces to connectors with `connect()`/`match()`, or prove the manual joint with `forgecad debug assembly --fail-on warning` and documented geometry.
 - A named part must not contain unintentional disconnected bodies: boolean-join manufactured features, model fasteners/seals as separate named parts, or add the receiving holes/lands that explain the separation.
 - Screws are not decoration: clearance/counterbore in the cover, receiving boss or through stack in the parent, material around both, axes aligned from one shared bolt pattern.
@@ -94,7 +104,7 @@ Treat `fillet()`/`chamfer()` as experimental (Manifold can be incorrect, OCCT sl
 
 ## Imported Parts (User-Supplied 3D Files)
 
-When the user supplies mesh or CAD files to design around (a motor, an off-the-shelf housing, a scanned part), the import IS a component of the assembly — keep it, don't rebuild it parametrically (rebuilding is `forgecad-3d-reconstruction`, a different request).
+When the user supplies mesh or CAD files to design around (a motor, an off-the-shelf housing, a scanned part), the import IS a component of the assembly — keep it, don't rebuild it parametrically (rebuilding is `forgecad-reconstruct-cad-file`, a different request).
 
 - Wrap each import in its own part file: `Import.mesh()` for STL/OBJ/3MF, `Import.step()` for STEP (OCCT backend), normalize scale and orientation, recenter to a sane local origin, then treat it exactly like a purchased part — connectors at its real mating features, positioned by the assembly via `matchTo()`.
 - Never trust units. Verify against a known dimension before mating anything: bbox via `forgecad run --details`, or `inspect section --ray` across a bore or face pair. For 3MF, account for every build item printed by `forgecad run` before flattening.
@@ -146,7 +156,7 @@ A manufacture-realistic model must yield a package a shop can consume, not just
 
 ## Render and Inspect Cadence
 
-**You are building blind unless you render.** `forgecad run` passing only means the code didn't crash — it cannot tell you a hole is misplaced, a rib pokes through a cover, or a part doesn't fit. Render from angles chosen for the model's actual geometry and read every PNG. For command syntax, evidence selection, and manifest reading, use the `forgecad-render-inspect` skill and the CLI docs — this skill fixes only the cadence and the gates.
+**You are building blind unless you render.** `forgecad run` passing only means the code didn't crash — it cannot tell you a hole is misplaced, a rib pokes through a cover, or a part doesn't fit. Render from angles chosen for the model's actual geometry and read every PNG. For command syntax, evidence selection, and manifest reading, use the `forgecad-inspect-model` skill and the CLI docs — this skill fixes only the cadence and the gates.
 
 Render after every feature addition, boolean cut, symmetric copy placement, and the last feature. Inspect after adding hidden geometry a surface render cannot prove, after adding or moving mating parts, ghosts, connectors, thin walls, or screw holes, and before delivery with thresholds set for the material/process.
 

package/dist-skill/library/forgecad-design-spec/SKILL.md

@@ -0,0 +1,132 @@
+---
+name: forgecad-design-spec
+description: Create a ForgeCAD design brief, HLD, or LLD before coding by walking through use, assembly, interfaces, decisions, and verification.
+forgecad-public: true
+---
+
+# Design Spec
+
+The design document — a git-committed, diff-reviewed markdown file — is the source of truth. Not the code, not the chat, not your head. You iterate it by commit-and-review, and the `git diff` is the review artifact.
+
+**Validate the design by mentally operating the thing, step by step.** Walk it as someone assembles, uses, or moves it. The step with no answer — *"how does the servo get inside the housing?"* — is the real design gap. A spec that reads complete on the page can still hide a hole that only surfaces when you try to put it together in your head. State each gap falsifiably: not "tolerances might be tight" but "the 12mm arm cantilevers under gripping load, may flex >0.5mm."
+
+**Every number has a reason; the narrative comes before the numbers.** Describe the object as if over the phone, then derive each value and show its math: `wallThickness = 2.4mm = 6 × 0.4mm nozzle`. The design is **implementation-blind** — shaped by the object, never by what the ForgeCAD API makes easy. **Manufacturing process is one of those reasons** — a design decision you weigh, never a default you inherit (never assume FDM/printing).
+
+**A vague request is a set of decisions you make honestly, not information to extract.** No placeholders ("appropriate motor"); choose a defensible value, show why, continue. The Decisions table fills only after user review, so the loop stays in the document.
+
+## Altitude — three phases, one document trail
+
+| Phase | When | Output |
+|-------|------|--------|
+| Intake | request is fuzzy / process unspecified | engineering brief + master prompt |
+| HLD | design is wrong in *approach*, alternatives exist | `<name>-hld.md` |
+| LLD | decisions locked, or a simple single-body part | `<name>-lld.md` |
+
+The HLD carries only decision-driving dimensions and genuinely-different alternatives; the LLD carries enough that someone builds from it alone. Speccing every tolerance in an HLD, or revisiting locked decisions in an LLD, is an altitude error — back up. Simple parts skip straight from HLD to code, or from a request to an LLD.
+
+---
+
+## Phase 1 — Intake (fuzzy request → concrete brief)
+
+Use when the user wants something physically real but the ask is vague ("make me a robot gripper", "make it production ready", "pick sensible numbers"). This phase owns intake; once the brief is concrete, continue to HLD or hand off to the `forgecad` skill.
+
+**Manufacturing is a design decision, not a default.** Derive the process stack from artifact family, load path, scale, safety expectations, material, production intent, and operating story — never assume printing/plastic. If the user names a process, honor it but warn when it is unsafe or dishonest for the duty. Family→process anchors live in `references/default-profiles.md`.
+
+**Default posture: manufacture-realistic prototype** — real materials, purchased-part boundaries, assembly logic, validation; no claims of production tooling or certification. Other postures only when justified: `production-realistic`, `printable`, `visual-CAD`, or a specific process posture (`sheet-metal`, `CNC-machined`, `laser-cut`, `welded-tube`, `injection-molded`, `cast`, `hybrid purchased-hardware`). Pick the posture honest for the artifact, not the easiest CAD surface.
+
+**Family-scoped numbers.** Every starter assumption is scoped to one artifact family; never reuse numbers across families.
+
+Workflow:
+1. **Normalize the ask** into plain mechanism language ("6 DOF gripper" → standalone gripper, wrist+gripper, or arm+gripper).
+2. **Build a specific operating story** — invented (non-famous) org, named program, prototype revision, review moment, mission pressure (pilot gate, demo date, investor milestone), and the generic failure mode to avoid. Prefer bold high-agency stories over modest lab exercises. Never assert the user works for a named real company; use real products only as public comparison anchors; never clone proprietary designs.
+3. **Classify the artifact family** (`references/default-profiles.md`); use the no-family-fits escape rather than forcing one. Rideables route to human-vehicles, never chassis.
+4. **Choose the process posture** per the taxonomy above.
+5. **Pick qualitative levers** — duty (`light`/`general`/`sturdy`), scale (`compact`/`medium`/`large`), cost (`cheapest`/`balanced`/`performance-first`) — and translate to family-scoped starter assumptions.
+6. **Close only critical gaps** — at most 3 grouped questions, always choice menus, never raw engineering inputs unless the architecture truly depends on them. Good: "light desk demo, useful hobby tool, or sturdier bench mechanism?" Bad: "What payload mass?"
+7. **Write the engineering brief**: artifact + family + normalized interpretation; operating story + production reason + test setting + failure mode to avoid; output posture; intended loads, size envelope, motion/DOF; process stack + material defaults; purchased-part (BOM) boundary; validation standard; variant policy (versions are selectable params, one rendered at a time); file organization (`main.forge.js` entry for multi-file); explicit uncertainty policy.
+8. **Emit one master prompt** — fill `references/master-prompt.md`; return the finished prompt, not notes about it. It must demand exactly `BUILD-READY` or `BEST-EFFORT BUILD CANDIDATE` (human-bearing furniture and rideables usually end the latter).
+
+Defaults if the user stays vague: `general-duty` / `medium` / `balanced`, invent the operating story, use family starter assumptions.
+
+---
+
+## Phase 2 — High-Level Design (HLD)
+
+Aligns user and agent on *what* to build before *how*. Brevity is a readability tool, not a metric — include whatever evidence, diagrams, and dimensions a good decision needs. Write the sections top to bottom; the order is the workflow.
+
+```markdown
+# [Name] — High-Level Design
+
+## Problem
+What must this do? Hard requirements (grip 40-90mm objects, fit a 60mm
+housing, use purchased bearings). State the problem without implying a
+solution. Unspecified process choice is an open design dimension.
+
+## Approach
+How it works conceptually. ASCII diagram of key elements and their
+spatial relationships — diagram labels stay in this markdown, never
+carried into CAD geometry unless the real artifact needs markings.
+
+## Key Interfaces
+Every point where this touches another part or the outside world:
+mating surfaces, shared dimensions, coordination points. These are the
+contracts that constrain the design.
+
+## Dictionary
+| Term | What it is |
+Define every domain term in plain words, with dimensions where relevant.
+Write for a developer without a mechanical-engineering background.
+
+## Alternatives
+| Option | Description | Tradeoff |
+2-3 genuinely different strategies, not minor variations. Mark one
+recommended and say why. If there is honestly one approach, say so.
+
+## Usage Guide
+Work backwards from how someone uses, assembles, or operates the thing,
+step by step. If a step doesn't make sense ("how does the servo get
+inside?"), flag it inline with ⚠️ and promote it to Concerns.
+
+## Concerns
+1. Numbered, falsifiably specific — a reviewer must be able to say "real
+   problem" or "fine, because…".
+
+## Decisions
+| # | Decision | Rationale |
+Filled ONLY after user review — never pre-decide. Each row resolves a
+concern or alternative.
+```
+
+Rules: if you're speccing every part, formula, and tolerance, you're writing an LLD — back up. If you can't draw it, you don't understand it yet.
+
+---
+
+## Phase 3 — Low-Level Design (LLD)
+
+Implements the HLD's locked Decisions table; it never revisits those decisions. Simple single-body parts skip the HLD and start here. Complex assemblies split into a numbered directory: overview, global constraints, per-component files, assembly, verification.
+
+An LLD is **narrative-first** (reads like describing the object over the phone), **authoritative** (the single source code implements), **implementation-blind**, and shows **every number's rationale**.
+
+Required structure:
+1. **Narrative** — what it is, how it behaves and interacts, why it exists. Concrete comparisons ("about the size of a deck of cards"); no ungrounded vague terms.
+2. **Technical** — typed parameter table (length / angle / count / boolean / choice / ratio / clearance — design-document vocabulary, not the runtime `Param.*` API), always with units (mm, degrees default) and a rationale for every default and range; derived dimensions shown as math; geometry and constraints, each constraint with a rationale.
+3. **Verification** — mandatory checklist: dimensional, functional, printability/process checks.
+
+Don'ts: never open with a parameter list (story before numbers), never leave a constraint implicit, never skip verification. Completeness gate before presenting: can someone build from this alone? Does it implement every HLD decision? Is every constraint explicit with a rationale?
+
+---
+
+## Review via git
+
+HLDs and LLDs iterate through git, not conversation:
+- **Commit every version.** No drafts floating in chat. After writing, commit and tell the user it's ready for review.
+- **Feedback arrives as file edits (inline comments, strikethroughs) or chat — check both.** Read `git diff`: the diff is the review artifact.
+- **Update, commit, repeat** until the Decisions table is filled and the user says "go."
+
+## Pipeline
+
+| Stage | This skill's phase | Output | Next |
+|-------|--------------------|--------|------|
+| Explore a fuzzy ask | Intake | engineering brief + master prompt | HLD |
+| Decide *what* to build | HLD | `*-hld.md` (Decisions filled) | LLD |
+| Detail *how* to build | LLD | `*-lld.md` | `forgecad-build-model` + `forgecad` → `.forge.js` |

package/dist-skill/library/{forgecad-prepare-prompt → forgecad-design-spec}/references/master-prompt.md

@@ -68,6 +68,6 @@ Required outputs:
 7. Bill of materials — manufactured, printed (if any), and purchased parts; per line: name, exact spec or part class, quantity, purpose, key dimensions/ratings; mirrored in-model with `bom()` so `forgecad export report` reproduces it.
 8. Assembly package — assembly order, jointing method, insert/bearing/pin usage, fastening notes, failure-prone steps.
 9. Validation package — motion range, likely collisions, stiffness/load risks, manufacturability, tolerance stacks, wear points; check printability only for printed parts; check moving designs through their operating range, not just at rest pose.
-10. ForgeCAD implementation package — the actual file structure; in a writable workspace, write the `.forge.js` files instead of stopping at prose, with `main.forge.js` as the runnable entry point for multi-file projects; `dim()` annotations on the dimensions a builder must hit, and the process-appropriate export proven to run (per the forgecad-make-a-model Manufacturing Outputs bar).
+10. ForgeCAD implementation package — the actual file structure; in a writable workspace, write the `.forge.js` files instead of stopping at prose, with `main.forge.js` as the runnable entry point for multi-file projects; `dim()` annotations on the dimensions a builder must hit, and the process-appropriate export proven to run (per the forgecad-build-model Manufacturing Outputs bar).
 11. Final verdict — end with exactly one of `BUILD-READY` or `BEST-EFFORT BUILD CANDIDATE`.
 ```

package/dist-skill/library/{forgecad-model-grader → forgecad-grade-model}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: forgecad-model-grader
-description: Analyze, verify, and grade ForgeCAD or CAD-as-code models against a user requirement, design brief, prompt, reference, or acceptance criteria. Use when asked to evaluate, judge, QA, benchmark, score, rate, or compare a CAD model; render it from multiple angles, run targeted inspections when needed, visually verify the evidence, and produce a 0-10 score with concise justification.
+name: forgecad-grade-model
+description: Grade a ForgeCAD or CAD-as-code model against a requirement, brief, prompt, reference, or acceptance criteria with evidence and a 0-10 score.
 forgecad-public: true
 ---
 
-# ForgeCAD Model Grader
+# Grade Model
 
 Grade the delivered model against the requirement, not against what could be fixed later. Never edit the model unless the user explicitly requests repairs — then record the baseline grade first, change, and re-grade.
 
@@ -14,7 +14,7 @@ Grade the delivered model against the requirement, not against what could be fix
 2. **Run the model**: `forgecad run <model>.forge.js` (in the ForgeCAD repo use the local build, `node dist-cli/forgecad.js run ...`). If it fails to execute, stop and apply the caps.
 3. **Render** at least `iso`, `front`, `right`, `top` to a scratch dir; add views (back, bottom, close-up, section) when the model is asymmetric, hollow, mechanical, or likely to hide mistakes.
 4. **Open and look at every PNG** — never score from command output alone. Check silhouette, proportions, required features, part boundaries, interfaces, and whether the model reads as the requested artifact from more than one angle.
-5. **Inspect** whenever hidden internals, fit, wall thickness, or assembly behavior are central to the brief — grading without inspecting them caps the score. Delegate evidence choice, commands, and manifest reading to the `forgecad-render-inspect` skill. Findings (unexpected collisions, thin regions, floating bodies, wrong component counts) are evidence, not warnings to wave away.
+5. **Inspect** whenever hidden internals, fit, wall thickness, or assembly behavior are central to the brief — grading without inspecting them caps the score. Delegate evidence choice, commands, and manifest reading to the `forgecad-inspect-model` skill. Findings (unexpected collisions, thin regions, floating bodies, wrong component counts) are evidence, not warnings to wave away.
 6. **Score**: fill the rubric, apply caps, give a final 0-10 in whole or `.5` increments. Unknowns count against the score.
 
 ## Rubric
@@ -40,6 +40,7 @@ Maximum scores, applied after the rubric:
 - A must-have requirement is absent: max `6`.
 - Visually recognizable but physically impossible for the requested use: max `6`.
 - Internals, fit, walls, or assembly central to the brief but uninspected: max `7`.
+- Multi-part assembly violates the ForgeCAD component model — sibling imports, assembly-space coordinates inside parts, structural `translate()` placement, missing connector mates, or parent/child data flow confusion: max `7`; max `6` when the violation makes the assembly brittle or mechanically wrong.
 - Inspection finds unexpected collisions, floating bodies, critical thin walls, or wrong connectivity: max `6`; max `5` when the defect invalidates the main function.
 - Delivered as a finished product/prototype but presented with default flat lighting (no `scene()` rig), a generically colorful or material-false palette, or teaching-diagram styling: max `8`. Does not apply when the brief asks for a blockout or bare technical study.
 - Any score relying on an assumption the evidence cannot verify: mark it `Unknown`, never score above `8`.
@@ -66,5 +67,6 @@ Next fixes: the 2-5 highest-leverage improvements.
 - Grade the default returned model unless the user names a parameter set or variant.
 - No points for comments, labels, or intentions absent from the geometry.
 - Decorative screws, floating labels, and teaching-diagram callouts are not real mechanical interfaces.
+- For multi-part assemblies, require the component model: parts build locally at origin, expose connectors/metadata, the parent positions them, and inter-part data flows through parent props and returned metadata.
 - Cite which render or inspection finding drove the grade.
 - When comparing models, use identical checklist, cameras, inspection evidence, and caps for all.

package/dist-skill/library/forgecad-grade-model/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ForgeCAD Grade Model"
+  short_description: "Grade CAD models against a brief"
+  default_prompt: "Use $forgecad-grade-model to evaluate this ForgeCAD model against the requirement and give a 0-10 score with evidence."

package/dist-skill/library/{forgecad-visual-spec → forgecad-image-prompt}/SKILL.md

@@ -1,18 +1,18 @@
 ---
-name: forgecad-visual-spec
-description: Turn a concrete ForgeCAD artifact, build brief, HLD, or existing model into builder-honest image prompts for AI image models. Use when the user wants visual-spec renders that show the final product while keeping mechanisms, seams, hardware, and build cues visible instead of drifting into concept art.
+name: forgecad-image-prompt
+description: Write builder-honest AI image prompts from a concrete ForgeCAD model, build brief, HLD, or LLD without hiding how the artifact is built.
 forgecad-public: true
 ---
 
-# ForgeCAD Visual Spec
+# Image Prompt
 
 ## Scope
 
-Only for artifacts already concrete enough to visualize (a specific `.forge.js` model, build brief, or HLD); route vague briefs to `forgecad-prepare-prompt` first. Read minimum context — entry `.forge.js`, one key helper if it delegates geometry, brief/HLD — and capture what must survive the image model: artifact type and scale, major subassemblies, actuation style, visible mechanisms, material and color cues.
+Only for artifacts already concrete enough to visualize (a specific `.forge.js` model, build brief, or HLD); route vague briefs to `forgecad-design-spec` first. Read minimum context — entry `.forge.js`, one key helper if it delegates geometry, brief/HLD — and capture what must survive the image model: artifact type and scale, major subassemblies, actuation style, visible mechanisms, material and color cues.
 
 ## Core Rule
 
-Visual-spec prompts, not concept art: show the final artifact clearly, preserve build and subsystem truth, and keep visible the seams, modules, hardware, and mechanical hierarchy that matter.
+Image prompts, not concept art: show the final artifact clearly, preserve build and subsystem truth, and keep visible the seams, modules, hardware, and mechanical hierarchy that matter.
 
 Negatives (the only negatives list — reuse it, never restate variants):
 

package/dist-skill/library/forgecad-image-prompt/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ForgeCAD Image Prompt"
+  short_description: "Builder-honest image prompt packs"
+  default_prompt: "Use $forgecad-image-prompt to turn this ForgeCAD artifact into image prompts that show the final product without hiding how it is built."

package/dist-skill/library/{forgecad-render-inspect → forgecad-inspect-model}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: forgecad-render-inspect
-description: Run and interpret ForgeCAD inspection bundles for model verification. Use when asked to inspect a ForgeCAD model, analyze an inspection bundle, validate collisions, wall thickness, connectivity, floating bodies, sections, masks, depth, normals, or Zebra stripes.
+name: forgecad-inspect-model
+description: Select, run, and interpret ForgeCAD inspection evidence for collisions, sections, wall thickness, components, masks, depth, normals, surface continuity, and fit.
 forgecad-public: true
 ---
 
-# ForgeCAD Render Inspect
+# Inspect Model
 
 Use `forgecad inspect ...` when a shaded render is too ambiguous and you need structured evidence: a bundle directory with evidence PNGs plus a root `manifest.json` (or, for `inspect section`, a probe directory with `result.json`, `section.svg`, `section.png`). Inspection is not a substitute artifact: look inside with sections, masks, `--focus`/`--hide`, and transparency — never edit the model into a cutaway or exploded default to make inspecting easier. Output dirs: let `inspect` allocate its timestamped directory by default (repeated probes never collide); use `/tmp/<model>-inspect` for throwaway bundles, a project directory only for persistent artifacts.
 
-Routing: authoring/API questions → `forgecad` skill; creating a new model → `forgecad-make-a-model`.
+Routing: authoring/API questions → `forgecad` skill; creating a new model → `forgecad-build-model`.
 
 ## Workflow
 

package/dist-skill/library/{forgecad-project → forgecad-project-sync}/SKILL.md

@@ -1,10 +1,10 @@
 ---
-name: forgecad-project
-description: ForgeCAD project CLI workflow — creating, managing, syncing projects and files on forgecad.io. Covers init, push, pull, file operations, member management, publishing, and sharing.
+name: forgecad-project-sync
+description: Manage hosted ForgeCAD project sync from the CLI: init, clone, pull, push, file operations, members, publishing, and shares.
 forgecad-public: true
 ---
 
-# ForgeCAD Project Operating Rules
+# Project Sync
 
 forgecad.io is the hosted ForgeCAD platform; a project is a local folder linked to the server by `forgecad.json`. The full command inventory (project, file, member, share, token commands and flags) lives in `forgecad project --help` and the forgecad skill's `docs/CLI.md` — do not relearn it here.
 

package/dist-skill/library/{forgecad-3d-reconstruction → forgecad-reconstruct-cad-file}/SKILL.md

@@ -1,14 +1,14 @@
 ---
-name: forgecad-3d-reconstruction
-description: Reconstruct a parametric ForgeCAD model from an existing 3D CAD or mesh file such as STL, OBJ, 3MF, STEP, or STP; inspect the source asset directly, author real ForgeCAD geometry, and iteratively compare the candidate with `forgecad compare 3d`.
+name: forgecad-reconstruct-cad-file
+description: Reconstruct a readable parametric ForgeCAD model from an existing CAD or mesh file such as STL, OBJ, 3MF, STEP, or STP.
 forgecad-public: true
 ---
 
-# ForgeCAD 3D Reconstruction
+# Reconstruct CAD File
 
 The reference asset is evidence, not the deliverable. The deliverable is a readable, parametric `.forge.js` model that runs, renders, and scores well against the source. Never return `Import.mesh()`/`Import.step()` of the source as the final model unless the user explicitly asks for an import wrapper — imports are for measurement, rendering, and scoring only.
 
-Routing: user wants to KEEP the file as a live component and design around it (bracket, enclosure, mating assembly) → `forgecad-make-a-model` (Imported Parts section), not this skill; benchmark/RL episodes → `forgecad-reconstruction-benchmark`; inspection-bundle interpretation → `forgecad-render-inspect`; independent grading after reconstruction → `forgecad-model-grader`; API and command reference → `forgecad` skill + CLI.md.
+Routing: user wants to KEEP the file as a live component and design around it (bracket, enclosure, mating assembly) → `forgecad-build-model` (Imported Parts section), not this skill; prepared benchmark/RL episodes → use the task-local benchmark instructions, not the public skill library; inspection-bundle interpretation → `forgecad-inspect-model`; independent grading after reconstruction → `forgecad-grade-model`; API and command reference → `forgecad` skill + CLI.md.
 
 ## Workflow
 
@@ -43,4 +43,4 @@ Faceted sources: decide whether tessellation itself is evidence. Matching low-po
 
 ## Done Criteria
 
-The final model must run, render, re-compare at `--samples 5000`, and pass an `inspect compare overlay`. Add targeted inspects (`forgecad-render-inspect`) when the object is multi-part, hollow, thin-walled, or surface-sensitive. Report: source and candidate paths, score JSON path, final metrics, and every known mismatch classified as intentional simplification or remaining work.
+The final model must run, render, re-compare at `--samples 5000`, and pass an `inspect compare overlay`. Add targeted inspects (`forgecad-inspect-model`) when the object is multi-part, hollow, thin-walled, or surface-sensitive. Report: source and candidate paths, score JSON path, final metrics, and every known mismatch classified as intentional simplification or remaining work.

package/dist-skill/library/forgecad-reconstruct-cad-file/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ForgeCAD Reconstruct CAD File"
+  short_description: "Rebuild CAD files as ForgeCAD models"
+  default_prompt: "Use $forgecad-reconstruct-cad-file to inspect this 3D file, rebuild it as parametric ForgeCAD, and score the result against the source."

package/dist-skill/library/{forgecad-image-replicator → forgecad-reconstruct-from-images}/SKILL.md

@@ -1,19 +1,19 @@
 ---
-name: forgecad-image-replicator
-description: Build real ForgeCAD geometry from one or more reference images by treating images as evidence, inferring the object, then validating against both reference-matched and canonical views.
+name: forgecad-reconstruct-from-images
+description: Reconstruct a real parametric ForgeCAD object from reference images by using images as evidence, not as a one-view facade.
 forgecad-public: true
 ---
 
-# ForgeCAD Image Replicator
+# Reconstruct From Images
 
 The reference image is evidence, not the deliverable. The deliverable is a real parametric object that holds up from front, back, side, top, bottom, and reference camera views — a model that matches one image but falls apart from other angles has failed, even if the comparison board looks close. Cutaway, sectioned, exploded, or transparent references are evidence about the complete object: build the closed artifact and recreate explanatory views with viewer/inspection tools (the main `forgecad` skill's closed-artifact rule applies).
 
 ## Companion Skills
 
 - `forgecad` — API docs, model authoring, renderer behavior.
-- `forgecad-prepare-prompt` — when the images underdetermine artifact family, process posture, scale, operating story, or validation boundary.
-- `forgecad-make-a-model` — file placement, project structure, decomposition, definition of done.
-- `forgecad-render-inspect` — pre-delivery inspection for multi-part, internal, mechanical, thin-wall, or fit-sensitive objects.
+- `forgecad-design-spec` — when the images underdetermine artifact family, process posture, scale, operating story, or validation boundary.
+- `forgecad-build-model` — file placement, project structure, decomposition, definition of done.
+- `forgecad-inspect-model` — pre-delivery inspection for multi-part, internal, mechanical, thin-wall, or fit-sensitive objects.
 
 ## Core Rule
 
@@ -23,19 +23,19 @@ Infer the real object before matching any camera — identity, manufacture, scal
 
 1. Stage references in `/tmp/<slug>-replicate/refs`, keeping originals and adding view names where possible (`front`, `side`, `rear-iso`, `top`, `detail`).
 2. Read each image as evidence, recording: visible facts; scale cues; camera cues; unknowns (hidden/occluded geometry); conflicts across images or stylization.
-3. Write a Real Object Brief — a hard gate before modeling: (a) artifact identity + operating story; (b) assumed scale and units; (c) process posture + part/BOM boundary (real geometry vs purchased vs ghost vs omitted); (d) inferred hidden-side geometry + expected canonical front/back/left/right/top/bottom forms; (e) validation views and inspection evidence. Use `forgecad-prepare-prompt` when these are underdetermined.
-4. Build a coarse 3D blockout — model the object, not the image: large volumes, axes, symmetry, side depth, rear form, underside, hidden continuations. Render canonical views before any reference-camera comparison. Follow `forgecad-make-a-model` for project structure.
+3. Write a Real Object Brief — a hard gate before modeling: (a) artifact identity + operating story; (b) assumed scale and units; (c) process posture + part/BOM boundary (real geometry vs purchased vs ghost vs omitted); (d) inferred hidden-side geometry + expected canonical front/back/left/right/top/bottom forms; (e) validation views and inspection evidence. Use `forgecad-design-spec` when these are underdetermined.
+4. Build a coarse 3D blockout — model the object, not the image: large volumes, axes, symmetry, side depth, rear form, underside, hidden continuations. Render canonical views before any reference-camera comparison. Follow `forgecad-build-model` for project structure.
 5. Calibrate one camera per usable reference, only after the blockout makes sense from canonical views. Use the object center as `target`; estimate azimuth/elevation/distance/FOV from visible faces and perspective cues; use orthographic when parallel edges stay parallel with no perspective convergence.
 6. Render comparison boards: render the model from each calibrated reference camera and place it next to the original. Never compare from memory.
 7. Iterate one class of change at a time, in order: object hypothesis → major proportions → canonical geometry → camera → details → presentation. If improving one reference view makes another view or a canonical render worse, the object hypothesis is wrong — fix the model, not the camera illusion.
 8. Use every image as a constraint. Never pick one target image and ignore the rest: assign each image a camera, evidence list, and confidence; optimize one shared geometry against the whole set; state how distorted or decorative images were weighted.
-9. Validate the final object: `forgecad run`, reference comparison boards, canonical renders, and targeted inspections via `forgecad-render-inspect`.
+9. Validate the final object: `forgecad run`, reference comparison boards, canonical renders, and targeted inspections via `forgecad-inspect-model`.
 
 ## Comparison Boards
 
 Render with exact `--camera` specs (see the forgecad CLI doc for supported forms). If exact full camera specs do not render, fix the renderer before continuing — never substitute guesses from default `iso` renders.
 
-Build side-by-side boards with the bundled self-contained `uv` helper (installs Pillow on demand). Resolve `scripts/compare_images.py` relative to the installed `forgecad-image-replicator` skill directory:
+Build side-by-side boards with the bundled self-contained `uv` helper (installs Pillow on demand). Resolve `scripts/compare_images.py` relative to the installed `forgecad-reconstruct-from-images` skill directory:
 
 ```bash
 uv run <skill-dir>/scripts/compare_images.py refs/front.png render-front.png compare-front.png

package/dist-skill/library/forgecad-reconstruct-from-images/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "ForgeCAD Reconstruct From Images"
+  short_description: "Build real CAD objects from images"
+  default_prompt: "Use $forgecad-reconstruct-from-images to infer the real object from these reference images and build a ForgeCAD model that holds up from all views."

package/dist-skill/library/forgecad-verify-mujoco/SKILL.md

@@ -0,0 +1,66 @@
+---
+name: forgecad-verify-mujoco
+description: Verify a ForgeCAD MJCF export in MuJoCo with dynamics, contacts, controls, joint travel, and rendered evidence before calling it simulation-ready.
+forgecad-public: true
+---
+
+# Verify MuJoCo
+
+Use this when `forgecad export mjcf ...` is part of the deliverable. A model is not sim-ready just because `forgecad check simready` passes or the MJCF file loads: it must be loaded in MuJoCo, stepped under gravity, driven with the intended controls, contact pairs inspected, and rendered from useful views.
+
+Routing: geometry-only visual inspection -> `forgecad-inspect-model`; model authoring/API questions -> `forgecad`; building a new model -> `forgecad-build-model`.
+
+## Definition Of Done
+
+1. **Export from the exact source file.**
+   ```bash
+   rm -rf /tmp/forgecad-mjcf && mkdir -p /tmp/forgecad-mjcf
+   forgecad export mjcf path/to/model.forge.js --output /tmp/forgecad-mjcf
+   ```
+2. **Load the generated scene in MuJoCo.** Use `scene.xml`, not only the model XML, so the floor/camera/package context is included.
+3. **Check the root behavior.** If the model has a free root, it needs real support/contact geometry or an explicit fixed-root export path. Do not hide a floor failure by turning the whole shell into a giant bounding box that blocks moving internals.
+4. **Check initial poses numerically.** For mechanisms, compute the expected body/link axes from the design source and compare them to MuJoCo `xmat`/`xpos`. Joint `ref`/default and connector frames can disagree with visual intuition.
+5. **Keep meaningful collisions.** Do not mark moving functional parts `Sim.collider.none(...)` just to make motion pass. If full visual mesh contact is unstable, use a physically defensible simplified collider or proxy and state what physical surface it represents.
+6. **Run the intended control with numeric acceptance criteria.** Define the expected signed post-settle joint travel before running the test: e.g. "this drive should rotate the drum -0.04 to -0.06 cycles, then stop near zero velocity" or "this wheel should move at least +1 cycle and keep spinning". Use cycles for revolute/indexing mechanisms when that is easier to reason about, and radians for direct MuJoCo qpos checks. A controller that only jitters, moves the wrong direction, overshoots through a stop, or eventually jams after skipping the intended state is a failure even when the process exits 0.
+7. **Inspect contact pairs.** Contact names should match the physical story: floor/support, card/card, wheel/ground, stop/follower, etc. Contacts against a filled-in AABB, hidden fixture, or unrelated side plate usually indicate bad collider selection.
+8. **Render evidence.** Save initial, settled, and driven frames from views that actually show the moving parts. If the model orientation is not obvious, generate a labeled camera preview grid first, inspect it, then rerun with the azimuth/elevation that shows the functional face. Do not report GIFs/frames before visually confirming they are not from the back, underside, or an occluded side.
+
+## Helper Script
+
+This skill ships a MuJoCo smoke verifier:
+
+```bash
+uv run --python 3.11 --with mujoco --with pillow \
+  python <this-skill-dir>/scripts/mujoco_verify.py /tmp/forgecad-mjcf \
+  --settle-seconds 2 \
+  --seconds 8 \
+  --actuator drum_velocity=-0.75 \
+  --watch-joint drum_joint \
+  --expect-drive-cycles drum_joint=-0.06:-0.03 \
+  --expect-final-qvel drum_joint=-0.02:0.02 \
+  --render-dir /tmp/forgecad-mjcf/verify \
+  --camera-preview-grid
+```
+
+Use `--actuator name=value` more than once for multi-actuator models. Use `--expect-drive-cycles joint=min:max` to assert signed final-minus-settled revolute travel in cycles/turns. Use `--expect-drive-delta joint=min:max` when you want raw MuJoCo qpos units instead. Use `--expect-final-qvel joint=min:max` to assert terminal velocity when the mechanism should stop or continue at a bounded speed. The script prints JSON with root drift, initial-to-final joint delta, post-settle drive delta, derived cycle counts, final velocities, expectation ranges, and top contact pairs, then writes PNG frames if `--render-dir` is supplied.
+
+Prefer explicit travel envelopes over loose "it moved" checks:
+
+- Stops/latches: assert a signed drive cycle or delta range and a near-zero final velocity range.
+- Continuous drives: assert the signed drive cycle/delta is large enough over the run and final velocity remains in the expected direction/range.
+- Indexing mechanisms: assert the expected cycle step size, not just eventual stall. If the mechanism reaches a stop only after skipping several indices, treat that as failure.
+- Gravity-settling mechanisms: evaluate functional travel with post-settle drive delta, not initial-to-final delta.
+
+When rendered orientation matters, start with `--camera-preview-grid`, open `camera_preview_grid.png`, pick the azimuth that shows the mechanism face or contact interface, then rerun with `--camera-azimuth <deg>` and any needed `--camera-lookat`, `--camera-distance`, or `--camera-elevation` adjustment. For mechanism evidence, prefer front/front-quarter views for user-facing GIFs and add a side/contact view only when it explains a collision better.
+
+## Contact Debugging Rules
+
+- In MuJoCo UI, enable contact visualization with `Rendering` -> `Contact points` and `Contact forces`; use the right-side perturb/visualization panels if available in your build.
+- If rotation is blocked, list contacts during the stall and sort by repeated pairs. The blocker is usually the pair that appears every step while the driven joint velocity trends to zero.
+- If a body falls through the floor, inspect the exported geoms. Visual geoms have `contype="0" conaffinity="0"` and cannot support anything; collision geoms are usually group 3.
+- Bounding boxes are fast but dangerous for hollow frames, windows, handles, and side plates. They collide as the filled AABB, not the visible object.
+- Mesh collision on complex moving parts can be too exact or solver-hostile. Prefer simple physical proxies for contact-critical moving bodies, such as a slab for a flap card or cylinders for rolling contact, but keep them colliding.
+
+## Reporting
+
+Report the exact export command, the MuJoCo command/script, key numeric results, the most important contact pairs, and the rendered image paths. Say what was not verified. Never say "sim-ready" when only `forgecad run`, `forgecad check simready`, or a successful export was executed.