fluid-cad/fluidcad/fluidcad-from-drawing

Provenance: maintained in the FluidCAD repo (https://github.com/Fluid-CAD/FluidCAD), under mcp/skills/. The installed local skill files are the runtime source of truth.

Modeling a part from a drawing

This skill layers on top of the fluidcad skill. That one owns everything generic: the MCP loop (read the docs, write the file, check render.state, screenshot), parallel doc research with sub-agents, what a build plan contains and how to write it, building in small increments, when a feature earns a verification screenshot, and rolling the scene back to debug. Follow it. This skill covers only what is specific to working from a drawing: reading it correctly, turning it into that plan, and checking the result back against the sheet.

The governing principle: a drawing is a specification you are transcribing, not a picture you are approximating. Every number in the model should trace back to a number on the sheet — printed, or derived from printed ones by construction.

Its corollary: the sheet is complete and correct. A released drawing fully determines the part; not every determining dimension is printed, because some are implicit — carried by symmetry marks, centerlines, tangency, concentricity, equal spacing, closed dimension chains. A dimension that seems missing is one you have not derived yet, never a defect in the drawing, and an apparent contradiction between views means you misread one of them. "The drawing doesn't give this" is always a statement about your reading, not about the sheet.

1. Every read of the drawing is whole — no cropping, ever

Open the drawing with whatever file/image reading tool your client provides — and for a multi-page PDF, read every page, not just the first.

Whoever reads the sheet reads the original image, whole — you and every transcriber alike. Do not crop it, tile it into quadrants, split out a region, zoom-and-slice, or otherwise preprocess it into sub-images to pull the dimensions out. It feels like it should help; it does not:

• Cropping strips the context that gives a number its meaning. A dimension is defined by the extension lines it spans, the arrowheads at its ends, and the view it sits in. Isolated in a tile, 24 is just a number with no referent — and that is exactly how a width gets modeled as a depth.
• Splitting causes both double-counting and omission. The same dimension shows up in two tiles and gets modeled twice, or it lands on a seam and vanishes from both. Neither failure announces itself.
• Re-encoding adds no information. Enlarging a blurry region does not recover pixels the original never had; it produces confident-looking digits that were never on the sheet. A misread you invented this way is indistinguishable from a real reading.

If something is genuinely unreadable at full size, that is a question for the user (§4), not a problem to solve with image processing.

The same ban covers scripted analysis of the drawing, for any purpose — no PIL/OpenCV/numpy code, circle or line detection, arc fitting, radial probing, density maps. Not to read values, and not "just for topology or attachment" (which circle a leader touches, which edges an extension line spans): a script that "finds" the answer produces confident-looking geometry with no authority behind it, and writing, debugging, and interpreting one eats the session. All labels on an engineering drawing are printed to be read; you read the sheet with your eyes on the whole image, and anything that reading cannot settle goes down §4's ladder — never through code.

2. One structural glance, then a parallel consensus read

Do not transcribe the digits alone, one long careful pass at a time. The read splits into a structural pass you do and a digit-level pass several independent readers do in parallel.

Your structural glance. Read the sheet once for what it is, not yet for its numbers:

• Title block: units (mm or inch), scale, projection angle (first vs third), general tolerance note, material, revision. These change how you interpret every view. FluidCAD files are in millimetres unless they say otherwise: a drawing in inches is modelled with unit('in') as the first statement after the imports, writing the sheet's numbers verbatim (or, for a single imperial dimension in a metric part, inch(x) from fluidcad/units) — never by multiplying by 25.4 by hand. Confirm the policy with the user up front.
• Views: which are orthographic (front/top/right), which are sections, which are detail blow-ups. For a section, note where the cutting plane is — a section shows internal geometry, not an outer face.
• Dashed lines are hidden geometry — bores, pockets, and counterbores seen through material; internal features to cut, never outlines to extrude.
• Callouts you'll need decoded: ⌀ diameter, R radius, SR spherical radius, □ square, ⌴ counterbore, ⌵ countersink, ↧ depth, THRU, TYP, 4X, ±, bolt-circle notation, thread callouts (M6×1, 1/4-20 UNC).

That glance is enough to launch the baseline doc sub-agents (FluidCAD skill, "Send sub-agents into the docs") and to start thinking about the plan.

The transcribers. In the same message as those doc agents, launch three transcriber sub-agents (two is acceptable for a small, cleanly rendered sheet):

• each gets the drawing's file path and reads the whole image itself
• each is told to first read references/transcription-contract.md in this skill's folder (when the skill is not installed locally: the resource skill://fluidcad-from-drawing/references/transcription-contract.md, or read_skill with name: "fluidcad-from-drawing", file: "references/transcription-contract.md") and follow it exactly — it defines the JSON they produce and the reading rules that bind them
• each gets a reader label (A, B, C) and a distinct output path in your scratch directory (drawing-read-a.json, …)
• they work independently — never show one reader another's output

The merge. When they return, run the bundled script (no dependencies, Node ≥ 18). Without a local skill folder, fetch it with read_skill (file: "scripts/merge-drawing-reads.mjs") and save it to your scratch directory first:

node <this skill's folder>/scripts/merge-drawing-reads.mjs \
  drawing-read-a.json drawing-read-b.json drawing-read-c.json \
  -o <part>.drawing.json --source <drawing file>

It aligns the reads by view + sheet position + callout text and gives every dimension a status:

• agreed — every reader, same value. Model from it without re-reading the image.
• majority — one dissent, recorded under variants. Usable; mention it in the question batch when it drives a functional dimension (a bore, a mating distance).
• partial — a reader missed it, or a reader invented it. Verify with one targeted look at the full sheet before modeling it.
• conflict — no majority; the entry carries variants and no value. Never model it: resolve it with your own whole-sheet look or put it in the question batch.

The merged <part>.drawing.json is the dimension inventory. Save it next to the model file: the plan's steps cite its ids (d3, d7), the close-out in §9 walks it entry by entry, and a future session starts from it instead of re-reading the sheet.

Check the arithmetic on the merged table. Chained dimensions should sum to the stated overall; hole positions should fall inside the outline; a bolt circle should clear the edge. Reader agreement means the digits were printed that way — not that the sheet is consistent. A mismatch is a §4 question, not something to reconcile by guessing.

A merge with no conflicts is a green light. Triage the reader questions (§4), then go straight to the plan and the first solid. Do not spend more time studying the sheet to pre-resolve every residual doubt about what a dimension attaches to: a referent doubt is cheaper and more reliably settled against the 3D model — measure and screenshot_multi laid next to the sheet — than by another round of image study.

Fallback. If your client cannot run sub-agents, or the drawing exists only as a pasted conversation image you cannot hand to one, first ask the user for the file path — a file on disk is what makes the parallel read possible. Failing that, do the full careful read yourself as a single reader and still write the same <part>.drawing.json by hand, contract schema and honest confidences included. Everything downstream consumes that file either way.

3. What sub-agents may and may not do with the drawing

The FluidCAD skill's sub-agent rules apply as written — doc agents are read-only, verbatim signatures, verify anything surprising. On top of them:

• Doc agents never get the image. They read the API docs; the drawing is not their input.
• Transcribers get the image whole, or not at all. Never a crop, a single view, or "just read the top half" — §1 binds them identically.
• Dimensions never cross an agent boundary as prose. A summarized dimension is a number stripped of the extension lines, arrowheads, and view that gave it meaning — the same failure that makes cropping unsafe, with a lossy retelling on top. Numbers move between agents only as contract JSON, and only merged statuses reach the model.
• Transcribers write exactly one file: their own output path. Never the model, and never the MCP scene tools (write_file, edit_range, recompute, rollback_to).

4. Triage every open point, then ask what survives — batched into one round

Never guess a digit. An 8 read as a 3 propagates silently through every downstream feature and is expensive to unwind. But "never guess" applies to what is printed, not to every doubt a reader can voice — most reader questions are not user questions. Walk each open point down this ladder, in order:

1. Drafting convention settles it. No units stated but the callouts read M12×1.75 and 110.4 → millimetres. 4X 12 THRU on a circle in a hole pattern → ⌀12 through-holes. Blank title-block fields (material, scale, title) → genuinely absent, not a mystery to chase. A convention reading is a decision, not a guess: take it, and record it as a one-line // ASSUMPTION: comment on the feature it drives.
2. Derivation settles it — arithmetic, construction, cross-view consistency. A dimension the sheet does not print is implicit: close the chain (overall minus the printed links), apply the symmetry a centerline declares, place the tangent line two dimensioned arcs fully determine, center what the centerline centers, space equally what the pattern note spaces. These are exact values with a stated derivation — comment the derivation, not an ASSUMPTION. The same logic settles referents: unsure which edges a 54 spans? Usually only one candidate makes the chains close and agrees with the other views. Take that reading, mark it ASSUMPTION, and let §9's measurements confirm it on the model.
3. Only what survives 1–2 goes to the user — genuinely illegible digits, chains that do not close under any reading, contradictions between views.

If no user is available to answer — an autonomous run, a benchmark, or the user has said to proceed without them — the ladder is the entire procedure: take the convention/consistency reading, mark it ASSUMPTION, keep building, and surface the full assumption list in the final report. Do not stall the build hunting for certainty the sheet does not print, and never turn to image-processing scripts to manufacture it (§1).

The merge report feeds the ladder: every conflict, the partial entries a targeted look did not settle, low-confidence values on functional dimensions, title-block conflicts, and the readers' own questions. Add what only you can see: