forgecad 0.10.2 → 0.10.4

package/examples/api/texture-projection.forge.js

@@ -0,0 +1,75 @@
+// Bitmap Texturing: Projected UV
+//
+// Wrap an imported bitmap onto a surface with `Shape.wrapTexture(image,
+// projection)`. The projection (a `Wrap.*` helper) decides how each point of the
+// surface maps into the image — no UV unwrapping, no Math.sin/cos.
+//
+// The image's colored edges (top=red, right=green, bottom=blue, left=orange) and
+// the dark top-left corner wedge make the mapping orientation easy to read on
+// every shape.
+//
+// Two key properties:
+//   1. AUTO-FIT — a bare `Wrap.flat/box/aroundCylinder` (no width/height/size)
+//      maps ONE copy of the image across the shape's extent. No magic numbers:
+//      the fit is read from the shape's bounding box.
+//   2. WORLD-SPACE & BOOLEAN-SAFE — the UV is derived from each vertex's final
+//      world position at render time, so the texture survives cuts/unions AND so
+//      you must texture a shape *after* positioning it (auto-fit reads the final
+//      world box; see the rightmost part, textured *then* bored).
+
+const tile = Param.number("Tile repeat", 1, { min: 1, max: 6, step: 1 });
+
+const art = Import.image("assets/uv-grid.png");
+
+// Laid out left-to-right in a tidy row on the z = 0 ground plane, ~25 mm gaps so
+// nothing overlaps. box() and sphere() are origin-centered (lift them by half
+// their height to sit on the ground); cylinder(height, radius) already has its
+// base at z = 0, so the can needs no z lift.
+//
+// In every case: build → translate → wrapTexture LAST, so auto-fit reads the
+// final world bounding box.
+
+// 1. FLAT — lay the image onto one axis-aligned face (a logo on a plate's top).
+//    No width/height: auto-fit maps the face span to the image once. `repeat`
+//    tiles that single fitted copy.
+const plate = box(50, 50, 8)
+  .translate(-140, 0, 4)
+  .wrapTexture(art, Wrap.flat({ onto: "top", repeat: [tile, tile] }));
+
+// 2. AROUND A CYLINDER — wrap the image like a can label. `axis` is the cylinder
+//    axis; the seam falls on the -X side (the atan2 wrap at ±π). No height:
+//    auto-fit maps the can's full height to the image once.
+const can = cylinder(55, 20)
+  .translate(-70, 0, 0)
+  .wrapTexture(art, Wrap.aroundCylinder({ axis: "z" }));
+
+// 3. ONTO A SPHERE — longitude/latitude mapping, like a globe. Auto-fit centers
+//    the projection on the sphere wherever it sits.
+const globe = sphere(26)
+  .translate(0, 0, 26)
+  .wrapTexture(art, Wrap.onSphere());
+
+// 4. BOX (cube-map) — the dominant face axis picks one of three planar maps, so
+//    each of the six sides shows one copy of the image. No size: auto-fit reads
+//    the box extent.
+const crate = box(40, 40, 40)
+  .translate(70, 0, 20)
+  .wrapTexture(art, Wrap.box());
+
+// 5. BOOLEAN-SAFE — position the plate, texture it (auto-fit over the solid
+//    plate), THEN subtract a bore. The image keeps flowing across the top and
+//    around the freshly-cut hole because the UV is re-derived from world position
+//    every frame, not baked into the original mesh. (Texture-then-cut, no
+//    translate after — the world-space UV must be locked before the boolean.)
+const bored = box(50, 50, 16)
+  .translate(140, 0, 8)
+  .wrapTexture(art, Wrap.flat({ onto: "top", repeat: [tile, tile] }))
+  .subtract(cylinder(40, 12).translate(140, 0, -12)); // through-hole, centered on the plate
+
+return [
+  { name: "Flat (plate top)", shape: plate },
+  { name: "Cylinder (label)", shape: can },
+  { name: "Sphere (globe)", shape: globe },
+  { name: "Box (cube-map)", shape: crate },
+  { name: "Boolean-safe (bored)", shape: bored },
+];

package/examples/products/sportscar.forge.js

@@ -0,0 +1,77 @@
+// Sports-car body — a showcase of class-A curve-network surfacing (Surface.Net).
+// Two Gordon surfaces compose the car: a near-closed lower body with fender
+// bulges, and an inset fastback greenhouse. Each is thickened to a glassy shell
+// (analytic vertex normals that survive the boolean wheel-arch cuts), then the
+// tyres are tucked into the arches.
+
+// Normalized body cross-section outline (right side, bottom edge -> deck centre).
+// y is a fraction of the half-width, z a fraction of floor..deck height.
+const BODY_OUTLINE = [
+  [0.12, 0.00], [0.60, 0.01], [0.95, 0.10], [1.00, 0.32],
+  [0.99, 0.55], [0.90, 0.78], [0.62, 0.93], [0.00, 1.00],
+];
+
+// Wrap the outline into a full closed-ish section (right bottom -> deck -> left
+// bottom), open only along a narrow underbody seam, so the thickened shell reads
+// as a solid body.
+function bodySection(halfW, floorZ, topZ) {
+  const cols = [];
+  for (let i = 0; i < BODY_OUTLINE.length; i++) {
+    const [yf, zf] = BODY_OUTLINE[i];
+    cols.push([yf * halfW, floorZ + zf * (topZ - floorZ)]);
+  }
+  for (let i = BODY_OUTLINE.length - 2; i >= 0; i--) {
+    const [yf, zf] = BODY_OUTLINE[i];
+    cols.push([-yf * halfW, floorZ + zf * (topZ - floorZ)]);
+  }
+  return cols; // [y, z] columns, right-bottom -> deck -> left-bottom
+}
+
+// A simpler open arch (rocker/deck edge -> spine -> other edge) for the cabin dome.
+function archSection(halfW, baseZ, topZ) {
+  const half = 7;
+  const cols = 2 * half - 1;
+  const out = [];
+  for (let c = 0; c < cols; c++) {
+    const s = c / (cols - 1);
+    const f = 1 - Math.abs(2 * s - 1);
+    const ease = f * f * (3 - 2 * f);
+    out.push([Math.sign(0.5 - s) * halfW * Math.pow(1 - f, 0.8), baseZ + (topZ - baseZ) * ease]);
+  }
+  return out;
+}
+
+// Assemble a cage from per-station section columns.
+function cageFrom(xs, sectionAt) {
+  return xs.map((x, i) => sectionAt(i).map(([y, z]) => [x, y, z]));
+}
+
+// ── Lower body: long & wide, fender bulges over the wheels, low deck ──────────
+const bodyX   = [0,   400, 950, 1500, 2100, 2700, 3250, 3800, 4200];
+const deckZ   = [420, 600, 690, 705,  710,  715,  730,  700,  560];
+const floorZ  = [300, 180, 150, 150,  155,  160,  165,  240,  380];
+const fenderW = [300, 620, 880, 760,  780,  760,  890,  760,  380];
+const body0 = Surface.Net().cage(cageFrom(bodyX, (i) => bodySection(fenderW[i], floorZ[i], deckZ[i]))).degree(3, 3);
+let body = body0.thicken(10).color('#c01622');
+
+// ── Greenhouse / cabin: long, low fastback set back on the deck ───────────────
+const ghX    = [1480, 1950, 2420, 2900, 3450];
+const ghBase = [700,  706,  710,  714,  724];
+const ghRoof = [725,  915,  975,  930,  745]; // windshield -> roof -> long backlight
+const ghW    = [560,  610,  580,  500,  330];
+const cabin = Surface.Net().cage(cageFrom(ghX, (i) => archSection(ghW[i], ghBase[i], ghRoof[i]))).degree(3, 3);
+body = union(body, cabin.thicken(10));
+body = body.color('#c01622').material({ metalness: 0.55, roughness: 0.28, clearcoat: 1 });
+
+// ── Wheel arches + tyres (tucked under the fenders) ──────────────────────────
+const wheelR = 360;
+const archZ = 360; // wheel centre height -> bottom near the ground, top inside the fender
+const axleX = [1000, 3250];
+for (const x of axleX) body = body.subtract(cylinder(2 * 980, wheelR + 30).rotateX(90).translate(x, 980, archZ));
+
+const tyre = (x, side) =>
+  cylinder(240, wheelR).rotateX(90).translate(x, side * 740, archZ).color('#141414').material({ roughness: 0.85 });
+const wheels = [];
+for (const x of axleX) for (const side of [1, -1]) wheels.push(tyre(x, side));
+
+export default group(body, ...wheels);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "forgecad",
-  "version": "0.10.2",
+  "version": "0.10.4",
   "description": "Code-first parametric CAD for JavaScript/TypeScript, in the browser and CLI.",
   "license": "SEE LICENSE IN LICENSE",
   "homepage": "https://forgecad.io",
@@ -204,7 +204,6 @@
     "@fastify/static": "^9.0.0",
     "@fontsource/inter": "^5.2.8",
     "@oclif/core": "^4.11.3",
-    "@react-three/postprocessing": "^3.0.4",
     "argon2": "^0.44.0",
     "chokidar": "^4.0.0",
     "clipper-lib": "^6.4.2",
@@ -224,7 +223,6 @@
     "pngjs": "^7.0.0",
     "polygon-clipping": "^0.15.7",
     "postgres": "^3.4.8",
-    "postprocessing": "^6.39.0",
     "prom-client": "^15.1.3",
     "puppeteer-core": "^24.37.2",
     "react-router-dom": "^7.13.2",

package/dist/docs-raw/skills/forgecad-blockout-model.md

@@ -1,49 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-blockout-model/SKILL.md instead. -->
-
-# forgecad-blockout-model
-
-Create rough high-level ForgeCAD concept models from simple primitives to explore layout, proportions, motion, and part relationships without production detail. Use when asked for a quick model sketch, blockout, spatial mockup, or intuitive low-detail 3D concept.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-blockout-model/SKILL.md` |
-
----
-
-## Block Out a Model
-
-A blockout is a spatial planning artifact: 3-7 simple masses that answer where parts go, whether a mechanism makes spatial sense, and what the silhouette, footprint, or motion envelope looks like. Not for print-ready geometry, exact fit, tolerances, or detail work.
-
-| Need | Skill |
-|------|-------|
-| High-level 3D idea using simple masses | `forgecad-blockout-model` |
-| Written concept or architecture before CAD | `forgecad-high-level-spec` |
-| Accurate, detailed, parametric ForgeCAD model | `forgecad-make-a-model` |
-
-### Method
-
-- Load the `forgecad` skill first; read its Core API and CLI docs. Load nothing else unless the concept demands it.
-- Translate the idea into 3-7 conceptual parts BEFORE writing geometry: masses and zones (base, arm, payload, sweep volume, keep-out, hand access).
-- One primitive stands in for many eventual details. A bounding box beats a fake detailed part. Never add detail as a substitute for clarity — simplify or reposition instead.
-- Use round-number dimensions; "believably shaped" beats numerically correct. Name uncertainty honestly: `armLengthGuess`, `baseWidthApprox`, `clearanceEnvelope`.
-- At most a handful of `param()` values, for comparing proportions. Do not parameterize every dimension.
-- Color by meaning; keep each conceptual part visually distinct via color or opacity. Return named shape objects so the viewer can inspect the concept part-by-part.
-- Ghost geometry: transparent volumes only for REAL physical envelopes — sweep arcs, keep-out volumes, approximate payloads, reach/access zones. Never decorative teaching overlays. Exaggerate tiny clearances when needed for readability.
-- Even a blockout represents the object in its normal assembled state: no labels, legends, cutaways, or permanently exploded layouts (full rule in the `forgecad` skill).
-- Leave out: fasteners and screw holes, wall thicknesses, fillets and blend radii, polished materials, hidden internal structure that does not affect the concept.
-
-### Verify
-
-Rendering is mandatory even for rough models. Run the script, then render from 2-3 angles with the installed `forgecad` CLI (syntax: the `forgecad` skill's CLI docs). Judge by the reader test:
-
-- Can someone unfamiliar with the idea tell what each mass represents?
-- Are proportions believable enough to discuss?
-- Is motion or interference visible where it matters?
-- Are unknowns shown honestly, not hidden behind fake detail?
-
-If any answer is no, simplify or add clearer ghost volumes.
-
-### Handoff
-
-File placement and naming follow `forgecad-make-a-model` conventions; suffix the filename `-blockout` or `-concept` unless the user supplied a clearer name. Once the high-level questions are answered, stop. If the next question is real fit, tunable dimensions, part details, or manufacturing logic, switch to `forgecad-make-a-model` instead of refining the blockout indefinitely.

package/dist/docs-raw/skills/forgecad-component-model.md

@@ -1,53 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-component-model/SKILL.md instead. -->
-
-# forgecad-component-model
-
-Enforce the ForgeCAD Component Model when building multi-part assemblies. Parts build at origin, connectors position them, data flows down from parent. Use when building or reviewing any multi-file ForgeCAD project.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-component-model/SKILL.md` |
-
----
-
-## Component Model
-
-The React of CAD: a part is a function from props to `{ shape, connectors, metadata }`, built at origin in local space. Parts never position themselves — the assembly positions them via connectors.
-
-### Rules
-
-1. **Parts build at origin.** Geometry starts at `[0,0,0]` in local coordinates; no assembly-space offsets; internal structure derives from the part's own props only.
-2. **Connectors are the only interface.** Declare via `.withConnectors({})`; axes point outward, mating is face-to-face (exception: prismatic joints share a co-directional slide axis). Mechanics: the forgecad skill's `docs/guides/positioning.md` and `docs/generated/assembly.md`.
-3. **Assembly is pure composition.** Zero `translate()` to position structural parts, zero coordinate math — connect connectors, pass props down, read metadata up.
-4. **Data flows down, never sideways.** Props down via `require('./part.forge.js', { Height: 20 })` overrides; metadata up via the part's return object; siblings NEVER import each other — the assembly mediates all sibling communication.
-5. **Validate with `verify.*`, never `console.log` + `if`.**
-
-### Part return shape
-
-```js
-return { shape, boltPattern, pinionZ }; // shape + metadata the parent may route to siblings
-```
-
-### File structure
-
-Default: ONE file per project-specific assembly — parts as sections, shared data as variables. Split only for cross-project reuse or past ~300 lines. Never split for "organization".
-
-### Anti-patterns (reject on review)
-
-- `shared-dims.js` — a file that only computes derived dimensions; the assembly derives and passes them.
-- Sibling `require()` — e.g. `require('./motor-mount.forge.js')` inside `cover-plate.forge.js`; route through the parent.
-- Assembly-space coordinates inside a part — a part knowing `pinionZ = 14` from a sibling's geometry; receive it as a prop.
-- `translate()` to position a structural part in an assembly — add a connector instead.
-- `console.log` + `if` validation — use `verify.*`.
-- Bare `connector.neutral()` outside a reusable component library with compatibility checking.
-
-### Design gate
-
-Before committing any multi-part assembly:
-
-1. Can you understand each part without reading other files?
-2. Does the assembly contain zero coordinate math?
-3. Do all inter-part relationships flow through connectors and props?
-
-If any answer is no, refactor.

package/dist/docs-raw/skills/forgecad-high-level-spec.md

@@ -1,101 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-high-level-spec/SKILL.md instead. -->
-
-# forgecad-high-level-spec
-
-Write a high-level design document (HLD) for a model, mechanism, or assembly before detailed specification or coding. Use when starting a new design, rethinking an existing one, or when the user asks to spec out, plan, or think through a model at a high level. Works backwards from requirements — defines the problem, explores alternatives, records decisions. Produces a right-sized design document for review and iteration.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-high-level-spec/SKILL.md` |
-
----
-
-## High-Level Design (HLD)
-
-The HLD aligns the user and the agent on *what* to build before anyone thinks about *how*. Every design concern, risk, and tradeoff lives in the document — not in conversation, not in the agent's head. Brevity is a readability tool, not a success metric: there is no page limit; include whatever evidence, diagrams, and dimensions a good decision needs. Decision-driving dimensions belong here; exhaustive construction dimensions belong in the LLD.
-
-Manufacturing process is a design decision, not a default — never assume 3D printing/FDM. If the user didn't specify a process, treat process choice as an HLD alternative (full posture taxonomy: `/forgecad-prepare-prompt`).
-
-Write an HLD before any LLD, and whenever an existing design is wrong in approach, not just in numbers. Output: `<name>-hld.md` beside the model files, or `hld.md` for a whole project.
-
-### Document Structure
-
-The section order is the workflow — write it top to bottom, following the embedded instructions.
-
-```markdown
-# [Name] — High-Level Design
-
-## Problem
-What must this do? Hard requirements (must grip 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 at a conceptual level. ASCII diagram of the key elements
-and their spatial relationships — diagram labels stay in this markdown;
-never carry them 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. Enough detail
-per row to see why it fits or loses. Mark one recommended and say why.
-If there is honestly only one approach, say so and skip the table.
-
-## Usage Guide
-The strongest validation: work backwards from how someone uses,
-assembles, or operates the thing, step by step (physical product:
-assembly steps, tools, what connects to what; mechanism: how it moves
-and what the user does). If a step doesn't make sense ("how does the
-servo get inside?"), the design has a gap — 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…". "Tolerances might be tight" is
-   useless; "the 12mm arm cantilevers under gripping load, may flex
-   >0.5mm" is useful.
-
-## Decisions
-| # | Decision | Rationale |
-|---|----------|-----------|
-Filled ONLY after user review — never pre-decide. Each row resolves a
-concern or alternative.
-```
-
-### 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."
-
-### Rules
-
-- If you're speccing every part, formula, tolerance, and fabrication step, you're writing an LLD — back up.
-- If you can't draw it, you don't understand it yet.
-- Tables are welcome where they clarify (interfaces, requirements, visible evidence); full parameter catalogs go to the LLD.
-
-### Pipeline
-
-| Stage | Skill | Output |
-|-------|-------|--------|
-| 1. Explore the problem space | this skill | `*-hld.md` |
-| 2. Detailed design | `/forgecad-lld` | `*-lld.md` |
-| 3. Implementation | `/forgecad-make-a-model` + `/forgecad` | `.forge.js` |
-
-The Decisions table must be filled before writing the LLD. Simple models may skip straight from HLD to code.

package/dist/docs-raw/skills/forgecad-lld.md

@@ -1,41 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-lld/SKILL.md instead. -->
-
-# forgecad-lld
-
-Write a Low-Level Design (LLD) for a CAD model — exact dimensions, constraints, parameters, and verification criteria. Use after a High-Level Design (HLD) exists and decisions are locked, or for simple parts that don't need an HLD. The detailed design document that code implements.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-lld/SKILL.md` |
-
----
-
-## Low-Level Design (LLD)
-
-### When and prerequisites
-
-- An HLD (`/forgecad-high-level-spec`) with a filled Decisions table must exist. The LLD implements those decisions — it never revisits them.
-- Simple parts (single body, no alternatives to explore) skip the HLD and go straight to the LLD.
-- Output: `<name>-lld.md` next to the model files. Complex assemblies split into a numbered directory: overview, global constraints, per-component files, assembly, verification.
-
-### What an LLD is
-
-- **Narrative first** — reads like describing the object over the phone: shape, behavior, purpose, proportions, feel.
-- **Authoritative** — the single source of truth that code implements.
-- **Implementation-blind** — the LLD knows nothing about ForgeCAD's capabilities; never let API convenience shape the design.
-- **Every number has a rationale** — each constraint and each parameter default/range gets an explicit reason; show the math (e.g. `wallThickness = 2.4mm = 6 × 0.4mm nozzle`).
-
-### 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 vague terms without grounding.
-2. **Technical** — typed parameter table (length / angle / count / boolean / choice / ratio / clearance — this is design-document vocabulary, not the runtime `Param.*` API), always with units (mm and degrees are the defaults) and a rationale for every default and range; derived dimensions shown as math; geometry and constraints, each constraint with rationale.
-3. **Verification** — mandatory checklist: dimensional checks, functional checks, printability checks.
-
-Don'ts: never open with a parameter list (story before numbers), never leave a constraint implicit, never skip verification.
-
-### Process
-
-Iterate via git exactly as in `/forgecad-high-level-spec`: commit every version; the diff, not the conversation, is the review artifact.
-
-Completeness gate before presenting: Can someone build from this alone? Does it implement every HLD decision? Is every constraint explicit with rationale?

package/dist/docs-raw/skills/forgecad-prepare-prompt.md

@@ -1,63 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-prepare-prompt/SKILL.md instead. -->
-
-# forgecad-prepare-prompt
-
-Turn a fuzzy physical product, mechanism, or CAD artifact request into a concrete manufacture-realistic prototype ForgeCAD build brief and a single master prompt for the modeling pass. Use when the engineering brief is incomplete, manufacturing/process choice is underspecified, or the work needs a specific operating story to avoid generic toy solutions.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-prepare-prompt/SKILL.md` |
-
----
-
-## Prepare ForgeCAD Prompt
-
-Use before modeling when the user wants something physically real and buildable but the request is fuzzy ("make me a robot gripper", "make it production ready", "I don't know the numbers, make sensible choices"). This skill owns intake and prompt preparation; once the brief is concrete, hand off to the `forgecad` skill.
-
-### Core Rules
-
-**Manufacturing is a design decision, not a default.** Never assume FDM, 3D printing, "printable", or plastic parts unless the user explicitly asked, the artifact family honestly points there, or the chosen process stack includes printed parts. Derive the process stack from artifact family, load path, scale, safety expectations, material properties, production intent, and operating story — family→process examples and all numeric anchors live in `references/default-profiles.md`. If the user names a process, honor it but warn when it is unsafe or dishonest for the duty.
-
-**Posture taxonomy.** Default output posture is **manufacture-realistic prototype**: a serious build candidate with real materials, purchased-part boundaries, assembly logic, and validation — no claims of production tooling, certification, rider safety, or release-ready DFM. Other postures only when the brief justifies them: `production-realistic` (explicit production intent), `printable` (printing is the selected process), `visual-CAD` (form study), or a specific process posture (`sheet-metal`, `CNC-machined`, `laser-cut`, `welded tube`, `injection-molded`, `cast`, `hybrid purchased-hardware`). Pick the posture that is 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; never apply one default profile to unrelated artifacts.
-
-### Workflow
-
-1. **Normalize the ask** into plain mechanism language. "6 DOF gripper" usually means one of: standalone gripper with finger joints, wrist plus gripper, or full arm plus gripper.
-
-2. **Build the specific operating story**: an invented specific (non-famous) org, a named program, a prototype revision, a review moment, a test setting, mission pressure (pilot gate, demo date, investor milestone, customer deployment), and the generic failure mode to avoid. Prefer bold high-agency stories — go/no-go gates, first-customer pilots, investor demos — over modest lab exercises.
-   - Good: "RivetLine Automation is racing toward a first-customer kitting-cell pilot and needs the RG-4 gripper jaw for a live demo next Wednesday. The jaw must pick 40-90 mm plastic housings from a tray, use hardware the build tech can source this week, and make finger-pad replacement possible without rebuilding the linkage."
-   - Bad: vague prestige labels ("frontier robotics startup") with no program/rig/milestone specifics.
-   - Never assert the user works for a named real company unless they said so. Named real products only as public comparison anchors. Never clone proprietary designs — public-domain patterns and first-principles engineering only.
-
-3. **Classify the artifact family** (`references/default-profiles.md`): grippers and small mechanisms; fixtures/jigs/holders; enclosures and electronics housings; furniture and load-bearing structures; chassis and mobile robot structures; human vehicles and rideable forms. Rideables always route to human-vehicles, never chassis. If no family fits, use the no-family-fits escape there — never force one.
-
-4. **Choose the process posture** per the taxonomy above.
-
-5. **Pick the qualitative levers** — duty: `light-duty`/`general-duty`/`sturdy-duty`; scale: `compact`/`medium`/`large`; cost: `cheapest`/`balanced`/`performance-first` — and translate them into family-scoped starter assumptions.
-
-6. **Close only the critical gaps.** At most 3 grouped questions, always choice menus, never raw engineering inputs (payload mass, torque budget, backlash tolerance) unless the architecture truly depends on them and cannot be bracketed safely. Good: "Which feels closest: a light desk demo, a useful hobby tool, or a sturdier bench mechanism?" Bad: "What payload mass?"
-
-7. **Write the engineering brief.** Required fields: artifact + family + normalized interpretation; operating story + production reason + test setting + generic failure mode to avoid; output posture; intended objects/loads, size envelope, motion style and DOF; process stack and material defaults; purchased-part (BOM) boundary; validation standard; variant policy — multiple versions of one object are selectable params (`Variant`/`Preset`/`Style`), one rendered at a time, a comparison lineup only as an explicit non-default debug mode so collision inspection proves one real assembly; file organization — `main.forge.js` entry point for multi-file projects (convention owned by `forgecad-make-a-model`); explicit uncertainty policy.
-
-8. **Emit one master prompt.** Fill `references/master-prompt.md` from the chosen profile and assumptions. Return the finished prompt, not notes about it.
-
-9. **Hand off** to the `forgecad` skill if implementation continues; for moving mechanisms its index routes to the assembly and joint-design docs.
-
-### Defaults And Verdict
-
-If the user stays vague: `general-duty` / `medium` / `balanced`, invent the operating story, and use the family starter assumptions from `references/default-profiles.md`.
-
-The prompt must demand exactly `BUILD-READY` or `BEST-EFFORT BUILD CANDIDATE`. If the request outruns the chosen profile, downgrade the claim and keep going. No placeholders ("appropriate motor", "adjust as needed") — choose a defensible value, state it, continue. No follow-up questions unless the architecture would materially change and no safe assumption bundle exists. Human-bearing furniture and rideable vehicles usually end `BEST-EFFORT BUILD CANDIDATE`.
-
-### Output Contract
-
-Reply with a short interpretation of the request, the chosen family + operating story + assumption bundle (compact, options menu only if truly needed), then the single filled master prompt last. Do not bury the prompt under theory.
-
-
-## Bundled Files
-
-- `references/default-profiles.md`
-- `references/master-prompt.md`

package/dist/docs-raw/skills/forgecad-reconstruction-benchmark.md

@@ -1,60 +0,0 @@
-<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-reconstruction-benchmark/SKILL.md instead. -->
-
-# forgecad-reconstruction-benchmark
-
-Solve ForgeCAD CAD reconstruction benchmark or RL episodes in a prepared workspace by rebuilding a visible reference asset as readable parametric ForgeCAD in the fixed submission path, using visual and geometric self-checks while respecting sandbox limits.
-
-| Field | Value |
-| --- | --- |
-| Installed by | `forgecad skill install` |
-| Source | `agent-skill-library/forgecad-reconstruction-benchmark/SKILL.md` |
-
----
-
-## ForgeCAD Reconstruction Benchmark
-
-Benchmark adaptation of `forgecad-3d-reconstruction`: same reconstruction loop, but with a fixed submission path, a local CLI wrapper, sandbox limits, and a short wall-clock budget. This sheet owns only those deltas — follow `forgecad-3d-reconstruction` for the reconstruction craft.
-
-### Workspace
-
-Read first: `AGENTS.md`, `task/instructions.md`, this skill, and `agent-home/.agents/skills/forgecad/SKILL.md` (API + CLI reference).
-
-- Reference asset (evidence only): `task/reference/*`
-- Final answer: `submission/main.forge.js`, unless `task/task.json` overrides
-- CLI: the local wrapper `./bin/forgecad`, never global commands
-- Scratch renders/notes: `outputs/`
-- Stay inside the prepared workspace.
-
-```bash
-./bin/forgecad run submission/main.forge.js
-```
-
-### Rules and Done Criteria
-
-- Deliverable is readable parametric ForgeCAD source at the required submission path. A clean parametric approximation beats an unreadable mesh mimic.
-- The final source must not call `Import.mesh`, `Import.step`, `importMesh`, `importStep`, `readFile`, `readFileSync`, or any equivalent asset-embedding trick, and must contain no `compareWith(...)`, external reference paths, base64 payloads, or debug probes.
-- Sandbox: allowed local tools only — no web search, no broad home-directory access, no subagents, no remote services.
-- Before exit: the run command above succeeds; visual/section evidence checked after the last meaningful edit; model recognizable against the reference from the main views.
-
-### Budget Discipline
-
-A runnable first candidate beats a perfect investigation with no model.
-
-1. Run the starter submission once before editing so syntax/runtime problems surface early.
-2. Inspect only the highest-value reference evidence: dimensions, volume, object count, one visual or sectional view. If a reference render/inspect command fails or stalls, continue from task instructions, filename, starter code, and mechanical inference — do not burn the budget retrying.
-3. Write a short reconstruction brief in `outputs/brief.md` (fields per `forgecad-3d-reconstruction`).
-4. Edit the submission early: coarse bbox, orientation, and main masses first, then iterate coarse-to-fine per `forgecad-3d-reconstruction`.
-5. 3MF references: the `forgecad run` source-structure table is evidence — account for every substantial 3MF item in the reconstruction (the final model may be one part or many).
-6. `inspect section` probes are replayable against the candidate via `inspect replay` — the cheap way to verify an exact local measurement transfers. Mechanics: `forgecad-render-inspect`.
-
-### Pointers
-
-- `forgecad-3d-reconstruction` — the evidence → brief → coarse → fine loop and metric diagnosis
-- `forgecad-render-inspect` — inspection bundles, section probes, replay
-- forgecad skill at `agent-home/.agents/skills/forgecad/` — API and CLI syntax
-- `forgecad-make-a-model` — general quality patterns only; its date-based file-placement workflow does not apply in benchmark workspaces
-
-
-## Bundled Files
-
-- `agents/openai.yaml`

package/dist-skill/library/forgecad-3d-reconstruction/agents/openai.yaml

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

package/dist-skill/library/forgecad-blockout-model/SKILL.md

@@ -1,42 +0,0 @@
----
-name: forgecad-blockout-model
-description: Create rough high-level ForgeCAD concept models from simple primitives to explore layout, proportions, motion, and part relationships without production detail. Use when asked for a quick model sketch, blockout, spatial mockup, or intuitive low-detail 3D concept.
-forgecad-public: true
----
-
-# Block Out a Model
-
-A blockout is a spatial planning artifact: 3-7 simple masses that answer where parts go, whether a mechanism makes spatial sense, and what the silhouette, footprint, or motion envelope looks like. Not for print-ready geometry, exact fit, tolerances, or detail work.
-
-| Need | Skill |
-|------|-------|
-| High-level 3D idea using simple masses | `forgecad-blockout-model` |
-| Written concept or architecture before CAD | `forgecad-high-level-spec` |
-| Accurate, detailed, parametric ForgeCAD model | `forgecad-make-a-model` |
-
-## Method
-
-- Load the `forgecad` skill first; read its Core API and CLI docs. Load nothing else unless the concept demands it.
-- Translate the idea into 3-7 conceptual parts BEFORE writing geometry: masses and zones (base, arm, payload, sweep volume, keep-out, hand access).
-- One primitive stands in for many eventual details. A bounding box beats a fake detailed part. Never add detail as a substitute for clarity — simplify or reposition instead.
-- Use round-number dimensions; "believably shaped" beats numerically correct. Name uncertainty honestly: `armLengthGuess`, `baseWidthApprox`, `clearanceEnvelope`.
-- At most a handful of `param()` values, for comparing proportions. Do not parameterize every dimension.
-- Color by meaning; keep each conceptual part visually distinct via color or opacity. Return named shape objects so the viewer can inspect the concept part-by-part.
-- Ghost geometry: transparent volumes only for REAL physical envelopes — sweep arcs, keep-out volumes, approximate payloads, reach/access zones. Never decorative teaching overlays. Exaggerate tiny clearances when needed for readability.
-- Even a blockout represents the object in its normal assembled state: no labels, legends, cutaways, or permanently exploded layouts (full rule in the `forgecad` skill).
-- Leave out: fasteners and screw holes, wall thicknesses, fillets and blend radii, polished materials, hidden internal structure that does not affect the concept.
-
-## Verify
-
-Rendering is mandatory even for rough models. Run the script, then render from 2-3 angles with the installed `forgecad` CLI (syntax: the `forgecad` skill's CLI docs). Judge by the reader test:
-
-- Can someone unfamiliar with the idea tell what each mass represents?
-- Are proportions believable enough to discuss?
-- Is motion or interference visible where it matters?
-- Are unknowns shown honestly, not hidden behind fake detail?
-
-If any answer is no, simplify or add clearer ghost volumes.
-
-## Handoff
-
-File placement and naming follow `forgecad-make-a-model` conventions; suffix the filename `-blockout` or `-concept` unless the user supplied a clearer name. Once the high-level questions are answered, stop. If the next question is real fit, tunable dimensions, part details, or manufacturing logic, switch to `forgecad-make-a-model` instead of refining the blockout indefinitely.