forgecad 0.10.4 → 0.11.0

package/dist-skill/library/forgecad-design-spec/references/master-prompt.md

@@ -1,73 +0,0 @@
-# ForgeCAD Manufacture-Realistic Prototype Master Prompt
-
-Fill the placeholders and return the finished prompt as one block.
-
-```text
-You are producing a ForgeCAD manufacture-realistic prototype package, not a concept sketch — a credible internal engineering package for a real build candidate, not a generic maker example. Use the specific operating story below to drive engineering choices; do not flatten it into a vague domain label.
-
-Target artifact:
-- artifact: {artifact}
-- request summary: {request_summary}
-- normalized interpretation: {normalized_interpretation}
-
-Specific operating story:
-- organization / team: {organization_team}
-- project / prototype revision: {project_revision}
-- milestone / review moment: {milestone_review}
-- domain context: {domain_context}
-- production reason: {production_reason}
-- test setting: {test_setting}
-- generic-output failure mode to avoid: {generic_failure_mode}
-- public comparison anchor, if useful: {benchmark_class}
-
-Chosen intake classification:
-- output posture: {output_posture} (manufacture-realistic prototype unless the user selected another)
-- artifact family: {artifact_family}
-- duty level: {duty_level}
-- scale level: {scale_level}
-- cost posture: {cost_posture}
-- manufacturing / process stack: {manufacturing_process_stack}
-- variant policy: {variant_policy}
-
-Working assumptions chosen to close missing inputs (provisional, scoped to `{artifact_family}` only):
-- {assumption_1}
-- {assumption_2}
-- {assumption_3}
-- {assumption_4}
-
-Hard constraints:
-- Use ForgeCAD. Any moving mechanism uses a real `assembly()` with honest joints, limits, axes, and operating ranges per the forgecad skill quality bar. Make the result runnable with `forgecad run`.
-- Default posture is manufacture-realistic prototype: real prototype materials, fabrication cues, purchased parts, assembly logic, serviceability, and validation — without claiming production certification or release readiness.
-- Choose processes that fit the artifact, load path, scale, safety, and operating story. Do not assume FDM/3D printing/"printable" unless the user asked or the selected process stack includes printed parts. Prefer metal shafts, bearings, fasteners, inserts, pins, tube, sheet goods, castings, molded/machined parts, or composite/wood members where honest, with process-appropriate clearances.
-- Include a BOM concrete enough to buy and assemble from, registered in-model with `bom()` entries — not only prose.
-- Model the physical artifact, not an educational diagram: no explanatory text labels, callouts, arrows, legends, axes, or part-name slabs unless the user explicitly asks for a teaching view. Include only markings the real artifact would carry (serial plates, connector labels, gauge ticks, alignment/warning marks, branding), sparse and process-appropriate.
-- Do not hide uncertainty; choose defaults and continue.
-- Do not claim the user works for a named company unless they said so; the invented org is a design scenario, not a factual claim. Do not clone proprietary named products — use public-domain patterns and first-principles engineering.
-
-Acceptable final states:
-1. `BUILD-READY` — specific enough that a competent builder could start fabricating, buying, assembling, and testing immediately without inventing missing details.
-2. `BEST-EFFORT BUILD CANDIDATE` — still the strongest concrete design possible, plus an explicit statement of the smallest unavoidable validation loop that remains.
-
-Non-negotiable rules:
-- No high-level concepts, visions, or wishlists; no generic category solution that could have been written without the operating story.
-- No placeholders like "appropriate motor", "standard hardware", or "adjust as needed". If a number is missing, choose a defensible value, state it, continue.
-- Prefer a complete best-effort design over an incomplete discussion. If the user's wording is physically confused, normalize it and proceed.
-- Do not import numeric assumptions from unrelated artifact families.
-- Do not ask follow-up questions unless the architecture would materially change and no safe assumption bundle exists.
-- Make the CAD legible through part boundaries, hardware, interfaces, and materials — not labels.
-
-Required outputs:
-
-0. Operating story and anti-generic bar — restate the org, revision, milestone, test setting; name the generic failure mode avoided and the domain-specific details that make the design credible.
-1. Problem normalization — what is being built, what it does, what "done" means physically.
-2. Assumption bundle — every chosen assumption with units and why it is reasonable.
-3. Architecture choice — one mechanism architecture; briefly name the rejected alternatives and why they lost.
-4. Detailed mechanical design — exact dimensions or formulas for major parts; subassemblies, interfaces, motion ranges, stops, load paths; for articulated mechanisms, concrete finger/link/jaw geometry and all joints.
-5. Actuation and transmission — actuator class, approximate torque/force, transmission approach, fit to the chosen profile.
-6. Manufacturing package — per critical part: material, process, prototype setup/orientation/tooling/finish assumptions, serviceability, process-accuracy-sensitive features. For printed parts (only if printing is selected): orientation, support strategy, print-sensitive features.
-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-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-grade-model/SKILL.md

@@ -1,72 +0,0 @@
----
-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
----
-
-# 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.
-
-## Workflow
-
-1. **Extract the requirement** into a checklist, must-haves separate from nice-to-haves. If the brief is vague, grade the most reasonable literal interpretation and mark unverifiable items `Unknown`.
-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-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
-
-| Dimension | Points | What To Look For |
-| --- | ---: | --- |
-| Requirement fit | 4 | Satisfies the stated must-haves, captures the intended object/function, no drift into a generic substitute. |
-| Geometric completeness | 2 | Correct silhouette, proportions, visible details, part boundaries, internal structure when required, no missing major components. |
-| Mechanical/manufacturing plausibility | 2 | Believable materials/process, real interfaces, clear load paths, fasteners/seats/clearances where needed, no impossible assembly. |
-| Validation health | 1 | Runs cleanly, renders from multiple views, targeted inspections reveal no major unaddressed issues. |
-| Code/model quality | 1 | Parametric clarity, readable organization, meaningful names, no debug junk, appropriate ForgeCAD APIs. |
-
-Anchors: 9-10 = evidence-backed match for the brief; 7-8 = recognizable and mostly complete, fixable gaps; 5-6 = main idea only; below 5 = broken or loosely related.
-
-## Evidence Caps
-
-Maximum scores, applied after the rubric:
-
-- Model does not execute: max `2`.
-- Executes but cannot be rendered: max `4`.
-- No rendered images visually inspected: max `5`.
-- Only one flattering view inspected: max `6`.
-- 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`.
-
-## Report Format
-
-```markdown
-Score: N / 10
-
-Requirement checklist:
-| Item | Result | Evidence |
-| --- | --- | --- |
-| ... | Pass/Partial/Fail/Unknown | render/inspection/file evidence |
-
-Evidence reviewed: run outcome; views inspected; inspection highlights.
-Why this score: decisive strengths and defects.
-Caps applied: list, or `None`.
-Next fixes: the 2-5 highest-leverage improvements.
-```
-
-## Grading Rules
-
-- A beautiful render with missing functional geometry is not a high score.
-- 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

@@ -1,4 +0,0 @@
-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-inspect-model/SKILL.md

@@ -1,68 +0,0 @@
----
-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
----
-
-# 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-build-model`.
-
-## Workflow
-
-1. **Identify the failure question.** What would make the model wrong: overlap, thin walls, hidden cavity failure, disconnected or accidentally fused bodies, floating parts, orientation artifacts, identity confusion?
-2. **Confirm the model executes.** If in doubt, run `forgecad run model.forge.js` first; add `--debug-imports` for suspect imports.
-3. **Pick ONE targeted evidence command** from the table below. `forgecad inspect evidence` lists everything available.
-4. **Summarize the manifest first**, then use `jq` against `manifest.json` for targeted follow-up. The helper ships beside this SKILL.md — invoke it skill-dir-relative; it accepts the bundle directory or a `manifest.json` path:
-
-   ```bash
-   python <this-skill-dir>/summarize_manifest.py /tmp/model-inspect
-   ```
-
-5. **Inspect the PNGs, not only the JSON.** View identity/context images first, then the risk evidence's view, then orthogonal cameras (`front`, `right`, `top`) when iso hides the issue, sections only when internals matter. In automation, resolve file paths through the manifest — custom cameras break canonical filenames.
-6. **Isolate intentional overlaps** with `--focus "A,B"` or `--hide "C"` so the remaining report stays meaningful.
-7. **Treat findings as model bugs**: unexpected collisions, critical thin regions, high unresolved thickness area, wrong component counts, floating bodies, or surprising gaps mean fix the model and reinspect.
-8. **Report honestly.** Include the exact command, bundle path, manifest highlights, and the PNG views actually inspected. Never claim geometry is verified if you only ran `forgecad run`.
-
-## Evidence Selection
-
-| Question | Evidence command |
-|----------|------------------|
-| Quick visual sanity | `inspect visual image` |
-| Kinematic rig, joints, axes, and links | `inspect visual rig` |
-| Object naming and identity | `inspect visual objects` |
-| Exact local section measurement, bore widths, rib thickness through a chosen line | `inspect section --ray ...` |
-| Hidden internals, cavities, pockets, screw paths, captured components | `inspect sections at\|stack\|sample` |
-| Multi-part interference, fit checks, ghost parts, moving clearances | `inspect fit interference` |
-| Printability, shell walls, ribs, bosses, snaps, slots | `inspect manufacture thickness` plus `inspect sections at\|stack\|sample` when internals matter |
-| Parts without a mesh-contact path to the ground | `inspect physical floating` |
-| Accidental fusion, connected solids | `inspect physical components` |
-| Air gaps between physical components | `inspect physical gaps` |
-| Surface orientation, occlusion, faceting, strange protrusions | `inspect visual depth` or `inspect visual normals` |
-| Loft, fillet, skin, and sweep surface continuity | `inspect surface zebra` or `inspect visual normals` |
-| Reference-vs-candidate reconstruction comparison | `inspect compare overlay --with reference.3mf` |
-
-## Section Probe + Replay
-
-The agent-native measure-then-recheck loop:
-
-```bash
-forgecad inspect section model.forge.js --plane yz --ray bore:-20,0:20,0
-forgecad inspect replay outputs/inspect/<probe>/result.json --source candidate.forge.js
-```
-
-The probe's `result.json` field contract (frames, rulers, gaps, replaySpec) is documented in the forgecad skill's `docs/guides/inspection-bundles.md`.
-
-## Misread Traps
-
-- Face-touching is not a collision; collision findings are positive-volume overlaps.
-- Gray/unresolved thickness area means the evidence is incomplete, not that the model is safe.
-- Distance/gap figures are bbox-gap metrics between components, not closest-surface distances.
-- Depth, normals, and zebra are visual aids (heatmap, camera-view normals, stripe shader), not exact measurements or curvature proofs.
-- Resolve mask colors through the manifest's object list, never by object order.
-
-## Reference
-
-Bundle/manifest contract, evidence semantics, and current limits: the forgecad skill's `docs/guides/inspection-bundles.md`. CLI flags and command tree: its `docs/CLI.md`.

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

@@ -1,66 +0,0 @@
----
-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.

package/dist-skill/website/skills/forgecad-design-spec.md

@@ -1,145 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-design-spec/SKILL.md instead. -->
-
-# forgecad-design-spec
-
-Create a ForgeCAD design brief, HLD, or LLD before coding by walking through use, assembly, interfaces, decisions, and verification.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-design-spec/SKILL.md` |
-
----
-
-## 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` |
-
-
-## Bundled Files
-
-- `references/default-profiles.md`
-- `references/master-prompt.md`

package/dist-skill/website/skills/forgecad-grade-model.md

@@ -1,84 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-grade-model/SKILL.md instead. -->
-
-# forgecad-grade-model
-
-Grade a ForgeCAD or CAD-as-code model against a requirement, brief, prompt, reference, or acceptance criteria with evidence and a 0-10 score.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-grade-model/SKILL.md` |
-
----
-
-## 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.
-
-### Workflow
-
-1. **Extract the requirement** into a checklist, must-haves separate from nice-to-haves. If the brief is vague, grade the most reasonable literal interpretation and mark unverifiable items `Unknown`.
-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-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
-
-| Dimension | Points | What To Look For |
-| --- | ---: | --- |
-| Requirement fit | 4 | Satisfies the stated must-haves, captures the intended object/function, no drift into a generic substitute. |
-| Geometric completeness | 2 | Correct silhouette, proportions, visible details, part boundaries, internal structure when required, no missing major components. |
-| Mechanical/manufacturing plausibility | 2 | Believable materials/process, real interfaces, clear load paths, fasteners/seats/clearances where needed, no impossible assembly. |
-| Validation health | 1 | Runs cleanly, renders from multiple views, targeted inspections reveal no major unaddressed issues. |
-| Code/model quality | 1 | Parametric clarity, readable organization, meaningful names, no debug junk, appropriate ForgeCAD APIs. |
-
-Anchors: 9-10 = evidence-backed match for the brief; 7-8 = recognizable and mostly complete, fixable gaps; 5-6 = main idea only; below 5 = broken or loosely related.
-
-### Evidence Caps
-
-Maximum scores, applied after the rubric:
-
-- Model does not execute: max `2`.
-- Executes but cannot be rendered: max `4`.
-- No rendered images visually inspected: max `5`.
-- Only one flattering view inspected: max `6`.
-- 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`.
-
-### Report Format
-
-```markdown
-Score: N / 10
-
-Requirement checklist:
-| Item | Result | Evidence |
-| --- | --- | --- |
-| ... | Pass/Partial/Fail/Unknown | render/inspection/file evidence |
-
-Evidence reviewed: run outcome; views inspected; inspection highlights.
-Why this score: decisive strengths and defects.
-Caps applied: list, or `None`.
-Next fixes: the 2-5 highest-leverage improvements.
-```
-
-### Grading Rules
-
-- A beautiful render with missing functional geometry is not a high score.
-- 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.
-
-
-## Bundled Files
-
-- `agents/openai.yaml`

package/dist-skill/website/skills/forgecad-inspect-model.md

@@ -1,80 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-inspect-model/SKILL.md instead. -->
-
-# forgecad-inspect-model
-
-Select, run, and interpret ForgeCAD inspection evidence for collisions, sections, wall thickness, components, masks, depth, normals, surface continuity, and fit.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-inspect-model/SKILL.md` |
-
----
-
-## 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-build-model`.
-
-### Workflow
-
-1. **Identify the failure question.** What would make the model wrong: overlap, thin walls, hidden cavity failure, disconnected or accidentally fused bodies, floating parts, orientation artifacts, identity confusion?
-2. **Confirm the model executes.** If in doubt, run `forgecad run model.forge.js` first; add `--debug-imports` for suspect imports.
-3. **Pick ONE targeted evidence command** from the table below. `forgecad inspect evidence` lists everything available.
-4. **Summarize the manifest first**, then use `jq` against `manifest.json` for targeted follow-up. The helper ships beside this SKILL.md — invoke it skill-dir-relative; it accepts the bundle directory or a `manifest.json` path:
-
-   ```bash
-   python <this-skill-dir>/summarize_manifest.py /tmp/model-inspect
-   ```
-
-5. **Inspect the PNGs, not only the JSON.** View identity/context images first, then the risk evidence's view, then orthogonal cameras (`front`, `right`, `top`) when iso hides the issue, sections only when internals matter. In automation, resolve file paths through the manifest — custom cameras break canonical filenames.
-6. **Isolate intentional overlaps** with `--focus "A,B"` or `--hide "C"` so the remaining report stays meaningful.
-7. **Treat findings as model bugs**: unexpected collisions, critical thin regions, high unresolved thickness area, wrong component counts, floating bodies, or surprising gaps mean fix the model and reinspect.
-8. **Report honestly.** Include the exact command, bundle path, manifest highlights, and the PNG views actually inspected. Never claim geometry is verified if you only ran `forgecad run`.
-
-### Evidence Selection
-
-| Question | Evidence command |
-|----------|------------------|
-| Quick visual sanity | `inspect visual image` |
-| Kinematic rig, joints, axes, and links | `inspect visual rig` |
-| Object naming and identity | `inspect visual objects` |
-| Exact local section measurement, bore widths, rib thickness through a chosen line | `inspect section --ray ...` |
-| Hidden internals, cavities, pockets, screw paths, captured components | `inspect sections at\|stack\|sample` |
-| Multi-part interference, fit checks, ghost parts, moving clearances | `inspect fit interference` |
-| Printability, shell walls, ribs, bosses, snaps, slots | `inspect manufacture thickness` plus `inspect sections at\|stack\|sample` when internals matter |
-| Parts without a mesh-contact path to the ground | `inspect physical floating` |
-| Accidental fusion, connected solids | `inspect physical components` |
-| Air gaps between physical components | `inspect physical gaps` |
-| Surface orientation, occlusion, faceting, strange protrusions | `inspect visual depth` or `inspect visual normals` |
-| Loft, fillet, skin, and sweep surface continuity | `inspect surface zebra` or `inspect visual normals` |
-| Reference-vs-candidate reconstruction comparison | `inspect compare overlay --with reference.3mf` |
-
-### Section Probe + Replay
-
-The agent-native measure-then-recheck loop:
-
-```bash
-forgecad inspect section model.forge.js --plane yz --ray bore:-20,0:20,0
-forgecad inspect replay outputs/inspect/<probe>/result.json --source candidate.forge.js
-```
-
-The probe's `result.json` field contract (frames, rulers, gaps, replaySpec) is documented in the forgecad skill's `docs/guides/inspection-bundles.md`.
-
-### Misread Traps
-
-- Face-touching is not a collision; collision findings are positive-volume overlaps.
-- Gray/unresolved thickness area means the evidence is incomplete, not that the model is safe.
-- Distance/gap figures are bbox-gap metrics between components, not closest-surface distances.
-- Depth, normals, and zebra are visual aids (heatmap, camera-view normals, stripe shader), not exact measurements or curvature proofs.
-- Resolve mask colors through the manifest's object list, never by object order.
-
-### Reference
-
-Bundle/manifest contract, evidence semantics, and current limits: the forgecad skill's `docs/guides/inspection-bundles.md`. CLI flags and command tree: its `docs/CLI.md`.
-
-
-## Bundled Files
-
-- `summarize_manifest.py`