forgecad 0.9.16 → 0.10.1

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

@@ -1,3 +1,5 @@
+<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-model-grader/SKILL.md instead. -->
+
 # forgecad-model-grader
 
 Analyze, verify, and grade ForgeCAD or CAD-as-code models against a user requirement, design brief, prompt, reference, or acceptance criteria. Use when asked to evaluate, judge, QA, benchmark, score, rate, or compare a CAD model; render it from multiple angles, run targeted inspections when needed, visually verify the evidence, and produce a 0-10 score with concise justification.
@@ -11,140 +13,68 @@ Analyze, verify, and grade ForgeCAD or CAD-as-code models against a user require
 
 ## ForgeCAD Model Grader
 
-Grade the delivered CAD model against the requirement, not against what could be fixed later. Use renders and inspection evidence before assigning a score.
-
-This skill is an evaluator workflow. Do not edit the model unless the user explicitly asks for repairs; if repair is requested, first record the baseline grade, then make changes, then re-grade.
+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.
-   Convert the user's prompt, design brief, reference image, or acceptance criteria into a short checklist. Separate must-haves from nice-to-haves. If the requirement is vague, grade against the most reasonable literal interpretation and mark uncertain items as `Unknown`.
-
-2. Identify grading risks.
-   Decide what could make the model fail: wrong object, missing parts, weak silhouette, hidden internals absent, impossible assembly, collisions, floating bodies, wrong scale, thin walls, poor manufacturing cues, bad parameter behavior, or unclear visual identity.
-
-3. Run the model.
-   In the ForgeCAD repo, use the local build:
-
-   ```bash
-   node dist-cli/forgecad.js run path/to/model.forge.js
-   ```
-
-   Outside the repo, use the installed CLI:
-
-   ```bash
-   forgecad run path/to/model.forge.js
-   ```
-
-   If the script fails to execute, stop normal grading and assign a capped score using the Evidence Caps section.
-
-4. Render multiple views.
-   Use a scratch output directory such as `/tmp/<model-name>-grade`. Render at least `iso`, `front`, `right`, and `top`. Add `back`, `bottom`, close-up, section, or custom cameras when the model is asymmetric, hollow, mechanical, or likely to hide mistakes.
-
-   ```bash
-   node dist-cli/forgecad.js render 3d path/to/model.forge.js /tmp/model-grade/view.png --camera iso --camera front --camera right --camera top --edges bold
-   ```
-
-   If a multi-camera render does not emit separate useful PNGs, rerun one camera at a time with explicit output paths.
-
-5. Visually inspect the PNGs.
-   Open the rendered images. Do not score from command output alone. Check silhouette, proportions, required visible features, part boundaries, material/color cues, seams, fasteners, interfaces, and whether the model reads as the requested artifact from more than one angle.
-
-6. Run targeted inspections when the risk calls for them.
-   Use `forgecad-render-inspect` for inspection bundles. Minimum guidance:
-
-   - `inspect visual image` and `inspect visual objects`: visual sanity, object naming, and part identity.
-   - `inspect fit interference`: multi-part fit, interference, and assembled mechanisms.
-   - `inspect sections at|stack|sample` and `inspect manufacture thickness`: shells, enclosures, ribs, bosses, printability, and wall claims.
-   - `inspect physical components`: accidental fusion or disconnected solids.
-   - `inspect physical floating`: loose bodies without physical support.
-   - `inspect visual depth`, `inspect visual normals`, or `inspect surface zebra`: surface, occlusion, faceting, continuity, or strange protrusions.
-
-   Typical command:
-
-   ```bash
-   node dist-cli/forgecad.js inspect fit interference path/to/model.forge.js /tmp/model-grade/collisions --camera iso --force --size 700
-   python agent-skill-library/forgecad-render-inspect/summarize_manifest.py /tmp/model-grade/collisions
-   ```
-
-   Read the manifest and inspect the relevant evidence PNGs. Treat unexpected collisions, thin regions, missing sections, wrong component counts, floating bodies, and confusing object colors as evidence, not as warnings to wave away.
-
-7. Score with evidence.
-   Fill the rubric, apply caps, then give a final 0-10 score. Use whole numbers or `.5` increments. Unknowns count against the score.
+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-render-inspect` 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
 
-Start from these dimensions, then apply the caps below:
-
 | Dimension | Points | What To Look For |
 | --- | ---: | --- |
-| Requirement fit | 4 | The model satisfies the stated must-haves, captures the intended object/function, and does not drift into a generic substitute. |
-| Geometric completeness | 2 | Correct silhouette, proportions, visible details, part boundaries, internal structure when required, and no missing major components. |
-| Mechanical/manufacturing plausibility | 2 | Believable materials/process, real interfaces, clear load paths, fasteners/seats/clearances where needed, and no impossible assembly behavior. |
-| Validation health | 1 | Runs cleanly, renders from multiple views, and targeted inspections do not reveal major unaddressed issues. |
-| Code/model quality | 1 | Parametric clarity, readable organization, meaningful names, no debug junk, and appropriate use of ForgeCAD APIs. |
-
-Interpretation:
-
-| Score | Meaning |
-| ---: | --- |
-| 10 | Exceptional match; requirements are met with strong visual and inspection evidence, no meaningful defects found. |
-| 9 | Excellent; one or two small gaps, but the artifact is clearly fit for the brief. |
-| 7-8 | Good; recognizable and mostly complete, with fixable omissions or moderate mechanical/detail issues. |
-| 5-6 | Partial; main idea is present, but major requirements, proportions, internals, or plausibility are missing. |
-| 3-4 | Weak; model runs or renders but only loosely matches the request. |
-| 1-2 | Barely useful; broken, mostly unrelated, or only a trivial placeholder. |
-| 0 | No evaluable model or completely unrelated artifact. |
+| 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
 
-Apply these maximum scores after the rubric:
+Maximum scores, applied after the rubric:
 
-- If the model does not execute: max `2`.
-- If the model executes but cannot be rendered: max `4`.
-- If no rendered images were visually inspected: max `5`.
-- If only one flattering view was inspected: max `6`.
-- If a must-have requirement is absent: max `6`.
-- If the model is visually recognizable but physically impossible for the requested use: max `6`.
-- If hidden internals, fit, wall thickness, or assembly behavior are central to the brief but not inspected: max `7`.
-- If targeted inspection finds unexpected collisions, floating bodies, critical thin walls, or wrong connectivity: max `6`, or max `5` when the defect invalidates the main function.
-- If the score relies on an assumption the evidence cannot verify: mark it `Unknown` and do not score above `8`.
+- 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`.
+- 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
 
-Keep the report compact and evidence-first:
-
 ```markdown
-Score: 7.5 / 10
+Score: N / 10
 
 Requirement checklist:
 | Item | Result | Evidence |
 | --- | --- | --- |
 | ... | Pass/Partial/Fail/Unknown | render/inspection/file evidence |
 
-Evidence reviewed:
-- Run: command and outcome
-- Renders: paths/views inspected
-- Inspections: bundle path, evidence command, manifest highlights
-
-Why this score:
-Short paragraph explaining the decisive strengths and defects.
-
-Caps applied:
-List any cap that affected the final score, or `None`.
-
-Next fixes:
-The 2-5 highest-leverage improvements, only if useful.
+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
 
-- Be strict but fair. A beautiful render with missing functional geometry is not a high score.
-- Grade the default returned model unless the user names a specific parameter set or variant.
-- Do not award points for comments, labels, or intentions that are not present in geometry.
-- Do not treat decorative screws, floating labels, or teaching-diagram callouts as substitutes for real mechanical interfaces.
-- Prefer concrete evidence over taste. Say which render or inspection finding drove the grade.
-- If comparing several models, use the same checklist, cameras, inspection evidence, and caps for all of them.
+- 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.
+- Cite which render or inspection finding drove the grade.
+- When comparing models, use identical checklist, cameras, inspection evidence, and caps for all.
 
 
 ## Bundled Files

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

@@ -1,3 +1,5 @@
+<!-- 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.
@@ -11,237 +13,48 @@ Turn a fuzzy physical product, mechanism, or CAD artifact request into a concret
 
 ## Prepare ForgeCAD Prompt
 
-Use this skill before modeling when the user wants something physically real, manufacturing-aware, and buildable as a manufacture-realistic prototype, but their request sounds like:
+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.
 
-- "make me a robot gripper"
-- "design a real mechanism"
-- "make it production ready / assembly ready"
-- "I do not know the payload or exact dimensions, just make sensible choices"
+### Core Rules
 
-This skill owns the intake and prompt-preparation step. After the brief is concrete, switch to `forgecad` for implementation.
+**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.
 
-### Core Rule
+**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.
 
-Do not start by asking raw engineering inputs like payload mass, torque, or tolerance unless the architecture truly depends on them and you cannot bracket them safely.
+**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.
 
-Manufacturing is a design decision, not a default.
-Do not assume FDM, 3D printing, "printable", or plastic parts unless the user explicitly asks for that, the artifact family honestly points there, or the chosen process stack includes printed parts.
-Choose the manufacturing/process stack from the artifact family, load path, scale, safety expectations, material properties, production intent, and operating story.
-For example: scooters, bikes, skateboards, and rideable vehicles usually point toward metal/composite frames, wood/composite decks, urethane/rubber wheels, bearings, brakes, and standard hardware; furniture often points toward wood, sheet goods, tube, metal brackets, or conventional joinery; enclosures may point toward injection molding, sheet metal, CNC, or printing depending on quantity and ruggedness; fixtures may be machined, laser-cut, welded, printed, or hybrid.
-If the user asks for "printable", "3D printed", "laser cut", "CNC", or another process, honor that process while still warning when it is unsafe or dishonest for the duty.
+### Workflow
 
-The default output posture is **manufacture-realistic prototype** unless the user asks for a different posture.
-This means a serious prototype build candidate with real manufacturing cues, purchased-part boundaries, assembly logic, and validation loops. It is stronger than a visual concept or hobby sketch, but it does not claim final production tooling, certification, rider safety, medical compliance, or release-ready DFM.
-Use `production-realistic` only when the user wants production intent, `printable` only when printing is actually the selected process, and `visual-CAD` only for visual/form studies.
+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.
 
-Do not let the modeling prompt sound like a casual hobby sketch when the requested artifact belongs to a serious product domain.
-Give the model a specific operating story: a named company or lab, named program, named prototype/revision, review moment, test setting, and concrete reason the part matters.
-If the user did not provide this story, invent plausible non-famous names and details.
-This should raise the specificity bar without pretending the user works for a real named company or copying proprietary designs.
-Prefer bold, high-agency stories over modest lab exercises: product pilots, go/no-go reviews, investor demos, field trials, first-customer deployments, or ambitious internal programs with real schedule pressure.
+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.
 
-Do not use one numeric default profile across unrelated artifact families.
-The correct order is:
+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.
 
-1. classify what kind of thing is being built
-2. choose the manufacturing/process posture that fits the artifact
-3. choose qualitative levers like duty / scale / cost posture
-4. translate those into family-scoped starter assumptions
-5. make those assumptions explicit in the final prompt
+4. **Choose the process posture** per the taxonomy above.
 
-Instead:
+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.
 
-1. Translate the request into plain-language build choices.
-2. Classify the artifact family.
-3. Choose a defensible manufacturing/process stack unless the user already specified one.
-4. Offer a small set of common-sense option bundles.
-5. Choose a defensible family-scoped starter assumption set if the user stays vague.
-6. Produce one single ForgeCAD master prompt with explicit 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?"
 
-When a product naturally has multiple versions of the same object, treat those versions as selectable parameters, not simultaneous geometry.
-The master prompt should ask for one selected variant to be rendered at a time through choice params such as `Variant`, `Preset`, `Style`, or `Configuration`.
-Do not ask the modeling pass to show a lineup of all variants by default; if a comparison view is useful, make it an explicit non-default debug/presentation mode so final collision inspection still proves one real assembly.
+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.
 
-### What Good Looks Like
+8. **Emit one master prompt.** Fill `references/master-prompt.md` from the chosen profile and assumptions. Return the finished prompt, not notes about it.
 
-By the end of this skill, there should be:
+9. **Hand off** to the `forgecad` skill if implementation continues; for moving mechanisms its index routes to the assembly and joint-design docs.
 
-- a normalized statement of what is being built
-- an artifact family classification
-- an assumption bundle with units
-- a clear build profile and manufacturing/process stack
-- a stated output posture, defaulting to manufacture-realistic prototype unless the user chose otherwise
-- a specific operating story
-- a motion / load / size target
-- a BOM boundary
-- a validation boundary
-- a variant-selection policy when the artifact has multiple sizes/styles/revisions
-- a file-organization policy, including `main.forge.js` as the entry point for multi-file projects
-- an artifact-first policy that forbids explanatory in-model text/callouts unless the user explicitly wants a teaching or presentation view
-- one ready-to-copy master prompt for the modeling pass
+### Defaults And Verdict
 
-### Workflow
+If the user stays vague: `general-duty` / `medium` / `balanced`, invent the operating story, and use the family starter assumptions from `references/default-profiles.md`.
 
-1. Normalize the ask.
-   If the user says something physically ambiguous, restate it in proper mechanism language.
-   Example: "6 DOF gripper" often means one of:
-   - a standalone gripper with finger joints
-   - a wrist plus gripper
-   - a full arm plus gripper
-
-2. Build the specific operating story.
-   Convert the artifact into a concrete professional assignment.
-   Do not use vague prestige phrases like "frontier robotics startup" by themselves.
-   Do not make the story feel small unless the artifact genuinely calls for it.
-   The story should feel like a real ticket from a real team, even when the company and program names are invented.
-   Include:
-   - a fictional but specific company / lab / team name when no real organization was provided
-   - an ambitious company posture, such as a venture-backed robotics company, advanced hardware group, field deployment team, or first-customer pilot team
-   - a named project, prototype revision, or milestone
-   - the domain context, such as humanoid robotics, lab automation, field tooling, consumer hardware, workshop equipment, or medical-adjacent assistive prototyping
-   - the production reason, such as internal prototype review, next-iteration part evaluation, assembly rehearsal, manufacturability review, or validation rig
-   - the test setting, such as a named bench rig, demo cell, assembly fixture, or field trial setup
-   - the external or mission pressure, such as a pilot gate, demo date, reliability target, investor milestone, or customer deployment constraint
-   - what a generic solution would miss in this domain
-   - the level of seriousness expected from the deliverable
-
-   Good framing:
-   - "Use this operating story: Helix Handworks, a venture-backed humanoid robotics company preparing a warehouse-pilot manipulation stack, is reviewing the F2 index-finger module for its DEX-07 go/no-go gate. The module must bolt into Palm Mule V3, route a Bowden tendon cleanly through the MCP base, survive a 1,000-cycle curl test on Rig-3, and expose every wear surface before the customer demo cell build starts."
-   - "Use this operating story: 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."
-   - "Use this operating story: Northbay Instruments is preparing the EVB-12 field calibration kit for a launch-readiness review. The case has to protect two stacked boards, expose USB-C and probe ports, survive repeated lid removal, and be credible for a prototype manufacturing review."
-
-   Bad framing:
-   - "The user works at Tesla."
-   - "Treat this as a frontier humanoid robotics startup."
-   - "Copy the Optimus finger."
-   - "Make something inspired by a named proprietary product without changing the engineering problem."
-
-   Named companies, famous products, and competitor designs may be used only as public comparison anchors if the user provided them or they are needed to clarify the class of artifact.
-   Do not assert affiliation, privileged context, or proprietary requirements unless the user explicitly supplied them.
-   Invented organizations are allowed, but do not present them as the user's employer.
-
-3. Classify the artifact family.
-   Read `references/default-profiles.md`.
-   Common families:
-   - grippers and small mechanisms
-   - fixtures, jigs, and holders
-   - enclosures and electronics housings
-   - furniture and load-bearing structures
-   - chassis and mobile robot structures
-   - human vehicles and rideable product forms
-   - custom / other
-   If no family fits cleanly, do not force one. Create a custom brief shape.
-
-4. Choose manufacturing/process posture.
-   Treat process selection as part of the brief.
-   Default to `manufacture-realistic prototype`.
-   Use `production-realistic`, `prototype-realistic`, `printable`, `visual-CAD`, or a more specific process such as `sheet-metal`, `CNC-machined`, `laser-cut`, `welded tube`, `injection-molded`, `cast`, or `hybrid purchased-hardware` only when the brief justifies that more specific posture.
-   Choose the posture that is honest for the artifact rather than the easiest CAD surface to make.
-
-5. Pick qualitative levers, not raw numbers.
-   Start from:
-   - duty level: `light-duty`, `general-duty`, `sturdy-duty`
-   - scale level: `compact`, `medium`, `large`
-   - cost posture: `cheapest`, `balanced`, `performance-first`
-   Then translate them into numbers only inside the chosen family.
-
-6. Close only the critical gaps.
-   Ask at most 3 grouped questions.
-   Use choice menus, not blank forms.
-   Good grouped questions:
-   - for a gripper: object style, opening band, cost/performance posture
-   - for a table: use style, span band, load style
-   - for an enclosure: electronics size, ruggedness, cooling posture
-   - for an underspecified product: manufacture-realistic prototype, production-realistic, printable, or visual-CAD posture
-
-7. Convert choices into an engineering brief.
-   The brief must include:
-   - target artifact
-   - artifact family
-   - specific operating story
-   - production reason
-   - test setting
-   - what generic output would miss
-   - output posture, defaulting to manufacture-realistic prototype unless changed by the user
-   - intended objects / loads
-   - rough size envelope
-   - motion style and degrees of freedom
-   - manufacturing/process stack and material defaults
-   - purchased-part boundary
-   - validation standard
-   - variant-selection policy when multiple versions of the same object are requested
-   - file-organization policy: if the implementation needs multiple files, the runnable ForgeCAD entry point must be `main.forge.js`; renderable parts/sub-assemblies belong in neighboring `.forge.js` files, while plain `.js` files are only for pure helpers/constants
-   - explicit uncertainty policy
-
-8. Emit one master prompt.
-   Start from `references/master-prompt.md`.
-   Fill in the placeholders using the chosen profile and assumptions.
-   If the requested model is complex enough to split across files, include an explicit instruction that the project must use `main.forge.js` as the runnable entry point.
-   Return the finished prompt, not notes about the prompt.
-
-9. If implementation continues immediately, hand off to `forgecad`.
-   For moving mechanisms, load:
-   - `~/.agents/skills/forgecad/SKILL.md`
-   - `docs/permanent/generated/assembly.md`
-   - `docs/permanent/generated/output.md`
-   - `docs/permanent/guides/joint-design.md`
-   - `docs/permanent/CLI.md`
-
-### Question Style
-
-Keep questions short and maker-friendly.
-
-Good:
-
-- "Which target feels closest: a light desk demo, a useful hobby tool, or a sturdier bench mechanism?"
-- "Will it mostly handle soft/light things, mixed household parts, or rigid/tool-like objects?"
-- "Should we bias for cheapest parts, balanced practicality, or stronger hardware?"
-- "Should this be a manufacture-realistic prototype, production-realistic, printable, or just a visual CAD study?"
-- "Is this more like a gripper, a fixture, an enclosure, a chassis, or furniture?"
-- "Will the table mostly hold decor, laptop-and-books, or workshop abuse?"
-
-Bad:
-
-- "What payload mass?"
-- "What torque budget?"
-- "What joint backlash can you tolerate?"
-
-### Default Behavior
-
-If the user says "I don't know" or gives only a broad goal:
-
-- infer the nearest artifact family from the request
-- invent a specific operating story for the artifact
-- infer the manufacturing/process stack from the artifact family and operating story
-- default the output posture to `manufacture-realistic prototype`
-- choose `general-duty`
-- choose `medium`
-- choose `balanced`
-- use the family-specific starter assumptions from `references/default-profiles.md`
-- do not copy assumptions from one family into another
-- do not make the artifact printable unless the user asked for it or the chosen process stack includes printed parts
-
-Examples:
-
-- gripper request -> use gripper-specific object mass, opening, and actuator assumptions, plus a named robotics or automation prototype-review story
-- table request -> use table-specific span, load, and leg/stiffness assumptions
-- enclosure request -> use enclosure-specific board size, wall thickness, and thermal assumptions
-
-Do not promise impossible honesty.
-If the request pushes beyond the chosen profile, keep going but downgrade the final claim from "build-ready" to "best-effort build candidate".
+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
 
-When using this skill, your answer should usually contain:
-
-1. a short interpretation of the user's request
-2. the chosen artifact family
-3. the specific operating story
-4. a compact options menu if truly needed
-5. the chosen assumption bundle
-6. the single filled ForgeCAD master prompt
-
-Do not bury the prompt beneath long theory.
+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

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

@@ -1,3 +1,5 @@
+<!-- Generated by scripts/build-forgecad-skill.mjs — do not edit. Edit agent-skill-library/forgecad-project/SKILL.md instead. -->
+
 # forgecad-project
 
 ForgeCAD project CLI workflow — creating, managing, syncing projects and files on forgecad.io. Covers init, push, pull, file operations, member management, publishing, and sharing.
@@ -9,136 +11,16 @@ ForgeCAD project CLI workflow — creating, managing, syncing projects and files
 
 ---
 
-## ForgeCAD Project CLI Workflow
-
-### Overview
-
-**forgecad.io** is the primary platform for ForgeCAD projects. The CLI is the main way AI agents interact with it — creating projects, managing files, publishing models, and collaborating. `forgecad studio <project-path> [project-path ...]` opens the installed local editor for users; `forgecad dev <project-path> [project-path ...]` is mainly for ForgeCAD source development.
-
-Keep one long-running `forgecad studio <project-path> [project-path ...]` process open with every active project folder listed in its arguments; the user opens the single printed localhost port once, and AI agents should only create or edit files under those folders so the browser updates live without starting more servers.
-
-### Authentication
-
-```sh
-forgecad login                          # Choose email/password or API token
-forgecad login --server http://localhost:5174  # Local dev server
-forgecad logout
-forgecad whoami                         # Show user, server, license
-```
-
-### Project Lifecycle
-
-#### Create a project
-
-```sh
-cd path/to/my-models
-forgecad project init "My Project Name"
-forgecad project init "My Project" --slug my-project --visibility public
-```
-
-Creates the project on the server, writes `forgecad.json` locally, and pushes any existing local files.
-
-#### Clone an existing project
-
-```sh
-forgecad project clone <slug>
-```
-
-Downloads into a new local directory.
-
-#### Sync (push/pull)
-
-```sh
-forgecad project push [--force]         # Upload local changes
-forgecad project pull [--force]         # Download remote changes
-forgecad project status                 # Show local vs remote diff
-```
-
-Sync is content-hash-based (SHA-256) — no timestamps, no git. `--force` skips confirmation.
-
-#### Inspect and modify
-
-```sh
-forgecad project list                   # List all your projects
-forgecad project info                   # Name, visibility, files, URL
-forgecad project rename "New Name"      # Rename
-forgecad project set-visibility public  # private | shared | public
-forgecad project delete [--force]       # Permanently delete
-forgecad project open                   # Open in browser
-```
-
-### Remote File Management
-
-Prefer `forgecad project status`, `forgecad project pull`, and `forgecad project push` for normal local sync. Use direct remote file commands only when you need a single hosted file operation without a full push/pull cycle:
-
-```sh
-forgecad project file list [path]               # List remote files
-forgecad project file read <path>               # Print contents to stdout
-forgecad project file save <path>               # Upload local file (same relative path)
-forgecad project file save <path> --content "const x = box(10, 10, 10); return x;"
-cat model.forge.js | forgecad project file save model.forge.js --stdin
-forgecad project file delete <path> [--force]   # Delete remote file
-forgecad project file rename <old> <new>        # Rename/move
-forgecad project file mkdir <path>              # Create directory
-forgecad project file copy <source-slug> <path> [--dest <dest-path>]  # Copy from another project
-```
-
-All file commands require being inside an initialized project (has `forgecad.json`).
-
-### Member Management
-
-```sh
-forgecad project members                          # List members
-forgecad project add-member alice@example.com     # Add as editor (default)
-forgecad project add-member bob@example.com --role viewer
-forgecad project remove-member alice@example.com
-forgecad project set-role bob@example.com editor
-```
-
-Roles: **owner** (full control), **editor** (read/write), **viewer** (read-only).
-
-### Publishing & Sharing
-
-```sh
-forgecad project publish model.forge.js --title "My Model"   # Publish, get URL
-forgecad project publish model.forge.js --no-sync             # Skip auto-push
-forgecad project shares list                           # List published models
-forgecad project shares delete <share-id> [--force]    # Unpublish
-forgecad link <gist-url-or-id>                        # Share from Gist
-```
-
-Published models are viewable at `forgecad.io/m/<shareId>`. Shares are **live references** to project files — they always show the current version, not a snapshot. Publishing requires a project context.
-
-### AI Agent Workflow Example
-
-```sh
-# 1. Authenticate
-forgecad login
-
-# 2. Create project
-mkdir my-gadget && cd my-gadget
-forgecad project init "My Gadget" --visibility private
-
-# 3. Create a model
-forgecad new housing --template part
-
-# 4. Edit and push
-# ... edit housing.forge.js ...
-forgecad project push --force
-
-# 5. Or save directly to remote
-forgecad project file save housing.forge.js --content "$(cat housing.forge.js)"
-
-# 6. Validate
-forgecad run housing.forge.js
-
-# 7. Publish
-forgecad project publish housing.forge.js --title "Gadget Housing"
-```
+## ForgeCAD Project Operating Rules
 
-### How sync works
+forgecad.io is the hosted ForgeCAD platform; a project is a local folder linked to the server by `forgecad.json`. The full command inventory (project, file, member, share, token commands and flags) lives in `forgecad project --help` and the forgecad skill's `docs/CLI.md` — do not relearn it here.
 
-- Scans local source files (`.forge.js`, `.js`, `.svg`), hashes each with SHA-256 (16-char prefix)
-- Fetches remote files from `/api/projects/:projectId/files`, hashes them the same way
-- Diffs: `added` (local only), `deleted` (remote only), `modified` (hash mismatch), `unchanged`
-- No timestamps, no git — purely content-based
+- **One studio process.** Run a single long-running `forgecad studio <folder> [<folder> ...]` naming every active project folder. The user opens the one printed localhost port once; create and edit files only under those folders so the browser live-updates. Never spawn extra servers per project.
+- **studio vs dev.** `forgecad studio` is for users and agents; `forgecad dev` is only for developing ForgeCAD itself.
+- **Login only for hosted commands.** `forgecad login` before any `project`/`publish` command; local work (run, render, studio) needs no auth.
+- **init creates, push syncs.** `project init "Name"` creates the remote project, writes `forgecad.json`, and pushes existing local files. `push` only syncs an already-initialized project. `clone <slug>` is the inverse: remote → new local folder.
+- **Sync is content-hash based.** `status`/`push`/`pull` compare file content hashes — no timestamps, no git; a file is "modified" purely by content difference. Loop: edit → `project status` → `project push`.
+- **Sync vs single-file ops.** Use `status`/`pull`/`push` for normal sync; use `project file <read|save|delete|...>` only for one hosted-file operation without a full push/pull cycle.
+- **Project context required.** All `project file *` and `publish` commands must run inside a folder containing `forgecad.json`.
+- **Shares are live references.** A published model always shows the current project file, never a snapshot — pushing changes silently updates published models. `publish` prints the share URL.
+- **Non-interactive runs.** Pass `--force` to skip confirmation prompts (push, pull, delete) in agent automation.