Features/MCP Workflows/Onshape/FeatureScript feature from model requirements

FeatureScript feature from model requirements

The model states the constraint and the feature enforces it in CAD. Every numeric limit in the generated code carries the requirement ID it came from, in a comment beside it.

OnshapeWrites · gated

The problem this solves

A requirement says the bracket must clear 40 mm and the CAD says whatever the person modelling it typed. The constraint exists in a document nobody opens while drawing, so the geometry drifts from the requirement and the violation is found at fit check.

How it works

The model states the constraint, the generated feature enforces it in CAD. Every numeric limit traces to a requirement ID in a comment beside it, and nothing is written to a Feature Studio until the snippet and the feature have both been tested.

01
Read the API before writing code
The stored FeatureScript notes, a documentation search for the constructs intended, and the current FeatureScript version confirmed with a trivial snippet. Version mismatches produce failures that look like logic errors.
02
Take values from requirements, verbatim
Never rounded, never unit-converted silently, never widened to make the feature build. A requirement stating a range makes the feature enforce the range rather than picking a midpoint.
03
Default every parameter
A feature without defaults fails its precondition, so each one gets a default and the report says where that default came from.
04
Test, then write once
Snippet, then feature, then a Feature Studio only after you approve. An existing studio is read and shown to you before anything would replace it. Code that was written but never executed is not a deliverable.

About this connector

The Onshape connector is pointed at the target document and Part Studio. This is the workflow it is actually built for.

The Onshape connector is a FeatureScript environment. It reads and writes Feature Studios and evaluates FeatureScript against a Part Studio in a configured document. Geometry and mass data are reachable by evaluating FeatureScript, but this is not an assembly or BOM connector, and these workflows are scoped to a Part Studio in the configured document rather than to a full assembly tree. If you need assembly-level rollups today, this connector cannot do it.

The prompt

You are generating a FeatureScript feature in Onshape whose
parameters and constraints come from requirements in the Dalus model
[model name]. This is the workflow the Onshape connector is actually
built for: the model states the constraint, the feature enforces it
in CAD.

BEFORE WRITING ANY FEATURESCRIPT: read the stored FeatureScript
notes, search the FeatureScript documentation for the constructs you
intend to use, and confirm the current FeatureScript version by
running a trivial snippet rather than assuming one. Version
mismatches produce failures that look like logic errors.

CONFIRM FIRST, in one message: which Dalus model and branch; which
requirements should drive the feature; what the feature is meant to
do, in the user's words; which document and Part Studio it targets;
and whether it should go into a new Feature Studio or an existing
one. Ask anything else in the same message. Then begin. If the user
cannot describe what the feature should do, stop: this workflow
translates an intent into FeatureScript, it does not invent the
intent.

READ THE MODEL: the requirements that constrain the geometry, with
IDs, statements verbatim, values and units; the part the feature
belongs to; and any interfaces whose dimensions the feature must
respect.

VALUES COME FROM REQUIREMENTS, VERBATIM. Every numeric limit in the
generated feature traces to a requirement ID, recorded in a comment
next to it with the requirement's statement. Never round a value,
never convert units silently, never widen a bound to make the
feature build. Where a requirement gives a range, the feature
enforces the range rather than picking a midpoint.

GIVE EVERY PARAMETER A DEFAULT, since a feature without defaults
fails its precondition, and state where each default came from.

TEST BEFORE DELIVERING, always, and in this order: test the snippet,
then test the feature, and only then consider writing it to a
Feature Studio. Report failures verbatim rather than describing
code as working because it looks right. A feature that was written
but never executed is not a deliverable.

WRITE ONLY WHEN THE USER APPROVES, and write once, at the end. Never
overwrite an existing Feature Studio without reading it first and
showing the user what would be replaced.

AFTER WRITING: report what was created, which requirements each
parameter traces to, and what was not enforced because the model did
not state it. Offer, do not execute: recording the Onshape feature
reference back on the model's part, and re-generating when the
driving requirements change.

Replace the [bracketed] placeholders with your model and project names.

What you get

A tested FeatureScript feature, written once and only on approval
Every numeric limit traced to its requirement ID in an adjacent comment
Parameter defaults with their stated origin
What the feature does not enforce, because the model never stated it
Dalus + Onshape

Reads the FeatureScript notes and documentation before generating, tests the snippet and then the feature, and writes to a Feature Studio once, at the end, after your approval. An existing Feature Studio is read first and what would be replaced is shown to you.

Nothing is written until you approve it. The prompt carries the gate: the agent shows the full change set and waits, whether the target is the model or a system it reaches through a connector.

Common questions

What if we cannot describe what the feature should do?
It stops. This workflow translates an intent into FeatureScript; it does not invent the intent. Say what the feature is meant to do in your own words and it takes the values from the requirements.
What stops it widening a bound to make the code build?
An explicit rule against it. Values come from requirements verbatim: never rounded, never silently unit-converted, never relaxed. If the feature will not build within the stated limits, that is a finding rather than something to engineer around.
Is the code tested before we get it?
Yes, in order: the snippet, then the feature, and only then a write. Failures are reported verbatim rather than described as working because they look right.