Design Space Explore

An engineering team designing a part rarely has one answer. They have a design space — a range of possible designs bounded by what they're allowed to vary (wall thickness, rib count, hole pattern, material) and what the part must satisfy (envelope, mass, load, cost, manufacturability). Modeling one design at a time, by hand, means evaluating three to five options and picking the best of a small set. This skill generates many at once, directly in the CAD tool the engineer already has open.

It does not design from scratch. It takes a model the engineer already has and generates variants of it — that constraint is what makes the output trustworthy and reviewable rather than a pile of new geometry nobody asked for.

It does not run analysis. It produces the variants and the manifest describing them, so an analysis tool or a person evaluates each one and returns results, which trade-study-report then consumes.

Quick start

→ Connect: Fusion, with the base model open in the desktop app
→ Read the model's parameter set. Not driving what was asked? Stop and say so
→ Confirm the variant plan — parameters, ranges, step, and the resulting count
→ Generate. Verify each regenerated; failures at range extremes are expected
→ Capture per-variant properties: parameter values, mass, volume, bounding box
→ Produce the manifest in the shape trade-study-report consumes
→ Never touch the base model. Variants are new documents, clearly named

Inputs

Workflow

Step 1 — Connect to the CAD environment

One implementation, Fusion, behind one interface. Read reference/cad-adapter.md for the interface and the connector behaviors that break a naive script.

• Fusion — desktop only, and acts on the open document via command-based operations on live geometry. There is no server-side fetch path; if the document is not open on the user's machine, there is nothing to act on.

Record the backend as cad_backend on the manifest, so a second CAD connector drops in later without a contract change.

Step 2 — Read the parameter set, and check what actually drives it

This check comes first, before anything else, and it is the single biggest practical risk in the skill. A parametric model is built from driving dimensions — change wall_thickness and the geometry regenerates. Many real production models are not properly parametric, and automated variant generation on one that isn't will not work.

Read the model's parameters and report which ones are actually driving geometry. Where a parameter the engineer wants to vary is not a driving dimension, stop and say so rather than generating variants that silently ignore it. Read reference/parametric-check.md.

Step 3 — Confirm the variant plan

Before generating anything: which parameters, which ranges, which step or sampling strategy, and the resulting variant count, stated plainly.

Generating 200 variants nobody asked for is the obvious failure. Five parameters at five values each is 3,125 combinations — show the count and get an explicit yes before the batch runs. Read reference/variant-generation.md.

Step 4 — Generate, and verify each one

Apply each confirmed parameter set to the existing model. After each, verify the model regenerated without error. The open, save-as-new, apply and untouched-check sequence is reference/adapt-prior-model.md — the same mechanism rfq-to-quote uses to adapt a prior part's model.

A failed regeneration is expected, not a bug — geometry that self-intersects or a feature that fails to rebuild at a range extreme happens routinely and does not abort the batch. Report it per variant, with what failed.

Step 5 — Capture per-variant properties

Parameter values, mass, volume, bounding box, and any other property the model computed.

A property the model could not compute is absent, not zero. A variant with no mass reading is unmeasured, not massless, and reporting it as zero would win a lower-is-better weight criterion outright.

Step 6 — Produce the handoff manifest

One row per variant — its ID, its parameter values, its computed properties, its status, and its document reference — per ../../shared/contracts/variant-manifest.md, in exactly the shape trade-study-report consumes.

A failed or skipped variant stays in the manifest, never dropped. A dropped row is indistinguishable from a variant nobody considered, and the trade study would then report a design space narrower than the one actually explored.

Step 7 — Never touch the base model

Variants are new documents, or clearly-named configurations of the base — never a modification in place. State what was created, and where.

Approval gates

Nothing generates without the variant plan being confirmed — parameters, ranges, and the resulting count, agreed before the batch runs. This is the skill's one real chance to prevent a runaway job; a live CAD connection generates 3,000 low-value variants exactly as easily as 30 good ones.

The base model is never modified. Every variant is a new document or a clearly-named configuration, so there is nothing to approve or roll back on the original.

This skill does not run analysis and does not decide anything about the trade study — it hands the manifest off. trade-study-report and the engineer own what happens next.

Output

Every document this skill produces is printed in the reply, in full. Saving a copy to a file as well is fine, as Word or Excel per ../../shared/replies.md, never .txt; a file instead of the reply is not. The person reads the reply, and every delimited block and outbound check lives in it — a document only on disk has been neither seen nor checked. A record handed to another skill is saved and summarised, never pasted as raw YAML; memory blocks are written where the plant's memory lives; and the name on an approval is asked, never taken from the account. All three per ../../shared/replies.md.

The generated variants, in the CAD system, consistently named and traceable back to their parameter set.

The variant manifest — per ../../shared/contracts/variant-manifest.md: the parameters varied, the parametric check result, and per variant its ID, parameter values, computed properties, status, and document reference.

The generation report — what succeeded, what failed to regenerate and why, what was skipped and why. Rendered in the house artifact style (../../shared/artifact-style.md) when there is enough of a batch to be worth referring back to.

The handoff package — the manifest plus the generation report, ready for an analysis tool or a person to evaluate and return results into, which trade-study-report then consumes.

Edge cases and failure modes

• The base model isn't properly parametric — the most likely real-world blocker. Detect and report before generating anything.
• Fusion isn't open, or the customer uses Fusion's web client — the connector cannot work at all. Detect and say so plainly; there is no server-side fetch path.
• The connector replays an earlier script — geometry nobody asked for appears, or read-only calls fail with "cannot modify." Stop and ask the user to restart Fusion; see reference/cad-adapter.md.
• Geometry fails to regenerate at a range extreme — expected. Report it per variant; do not abort the batch.
• The parameter combination count explodes — five parameters at five values is 3,125. Always show the count and confirm before generating.
• The model has external references or in-context relationships — variant generation can break them. Detect and warn before generating.
• CAD operations are slow — this is a long-running batch, not a single blocking call. Design for progress reporting, not silence until it finishes.

Degradation

One CAD tool, on one platform. The skill works for customers running Fusion on the desktop, with no cloud path. There is no fallback CAD backend — no connector currently reaches SolidWorks, Creo, NX or Inventor, so a customer on any of those has no path to this skill at all. State that plainly rather than letting a prospect discover it for the first time in a demo. Keep the CAD-adapter layer regardless, so a CAD connector appearing later drops in without a redesign.

If Fusion is not available — the skill cannot generate variants and says so, naming exactly what is needed: Fusion desktop with the document open. trade-study-report is unaffected — its manifest can be hand-authored by an engineer with no CAD backend at all, per its own contract.

Chain position

Not part of a named chain, but feeds trade-study-report directly — the same producer-consumer relationship breakdown-diagnosis has with daily-production-report in Chain 4.

Metric. Configurations evaluated per program; design cycle time.

Reference files