forgecad 0.10.1 → 0.10.3

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-skill/library/forgecad-high-level-spec/SKILL.md

@@ -1,94 +0,0 @@
----
-name: forgecad-high-level-spec
-description: 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.
-forgecad-public: true
----
-
-# 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-skill/library/forgecad-lld/SKILL.md

@@ -1,34 +0,0 @@
----
-name: forgecad-lld
-description: 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.
-forgecad-public: true
----
-
-# 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-skill/library/forgecad-prepare-prompt/SKILL.md

@@ -1,50 +0,0 @@
----
-name: forgecad-prepare-prompt
-description: 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.
-forgecad-public: true
----
-
-# 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.

package/dist-skill/website/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-skill/website/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-skill/website/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`