Prompting Guide

The agent is good at engineering work and bad at guessing what you meant. Most of the difference between a session that works and one that wastes an hour is in the first message.

Say what, where, and how you will judge it

A prompt that works usually has three parts: the task, the files it concerns, and the criterion for done.

Weak:

Analyze this bracket.

Better:

Static structural analysis of cad/bracket.step. Fixed at the four
M6 holes on the base flange, 1.2 kN vertical load distributed over
the top face. 6061-T6. I need peak von Mises and the margin against
yield with a factor of safety of 2.

The second version names the geometry, the boundary conditions, the material, and what number you actually want. There is nothing left to guess.

Point at files precisely

Type @ in the composer to pick a file from the workspace. It is faster than describing a path and it cannot be misread.

For directories and patterns, be explicit: the cases under ./cases/dfbi, every .nvm in this folder, the newest run in ./runs.

Plan first for anything substantial

Press ⇧Tab to reach Plan mode. The agent researches and proposes an approach under instructions to avoid changing files, system state, or repository state.

Read the plan for the things that are expensive to get wrong:

• Did it identify the right geometry and the right faces?
• Are the loads and constraints what you described?
• Is it about to run something that takes four hours?

Approving a wrong plan costs one round trip. Discovering the same error after the solve costs the solve.

Review and correct the plan, then exit Plan (for example, select Accept Edits) before asking the agent to implement it. Plan approval does not enable edits while Plan is active. Plan is not a read-only shell sandbox: shell allowlist rules and approvals still apply. See Permissions & Approvals for the shell-trust limits.

Give it the units

Units are the most common source of silently wrong answers, and no solver will catch them for you. Ferro in particular is strictly SI — Pa, N, m, K, kg, Hz — with no conversion layer. A case in millimetres solves happily and gives you nonsense.

Say the units in the prompt, and check them in the diff.

Let it read before it writes

For unfamiliar work, split the task:

Read ./cases/pipe and tell me what this case is set up to solve —
solver, turbulence model, boundary conditions, and mesh size.
Don't change anything.

Then, once you agree with its reading:

Now change the inlet to 12 m/s and rerun.

Two messages, and you have verified its understanding before it acts on it.

Ask for the check, not just the result

The agent will report success readily. Ask it to prove it:

Run it, then tell me whether it converged: show the residual history
and the last 20 lines of the log.

After the solve, check the mesh quality report and tell me if
anything failed the checks.

Iterate in the same thread, restart when the subject changes

Follow-ups work because the whole transcript is context. That same property makes a thread that wandered across three unrelated tasks worse at all of them.

Stay in the thread while you are refining one piece of work. Start a new one (⌘N) when you move to a different part, case, or question.

Effort

The effort picker controls how much reasoning the model spends. Raise it for:

• Setting up a case from scratch.
• Debugging a solve that failed for a non-obvious reason.
• Anything where being wrong is expensive.

Leave it low for lookups, summaries, and small edits.

Prompts worth stealing

Understanding handed-over geometry

@cad/assembly.step came from a supplier. List every body with its
bounding box (mm) and volume, then group them into likely
subassemblies and say what each one probably does. Flag duplicates,
fasteners, and anything floating free of the rest. Don't modify it.

Asking about what you have selected

I've selected a face in the CAD viewer. What is it: surface type,
area, normal, and which body it's on? Then list the other faces on
that body that are coplanar with it.

Setting up an OpenFOAM case from scratch

Run this one in Plan mode and check the boundary assignment before it meshes.

Build an OpenFOAM case from scratch for air flow (20 °C) through
@cad/duct.step, which is modelled in mm. Inlet: the end face at
minimum x, 12 m/s uniform. Outlet: the opposite end, 0 Pa gauge.
Everything else is a no-slip wall. Steady, incompressible, k-omega SST.
Mesh with snappyHexMesh and three boundary layers on the walls, run
checkMesh, and stop if anything fails. Before solving, tell me the cell
count and estimated run time. Count it as converged when residuals are
below 1e-4 and the pressure drop moves less than 0.5% over the last 200
iterations. Report the pressure drop and the outlet velocity uniformity.

Debugging a failed solve

@runs/duct-v3 diverged around iteration 1400. Read the log and tell
me the most likely cause, quoting the lines that support it. Propose
one fix and wait for me before changing anything.

Setting up a structural case from CAD

Set up a static CalculiX case for @cad/bracket.step (modelled in mm).
Mesh it with second-order tets and named sets for the four base-flange
bolt holes and the top face. Fix the holes, 1.2 kN downward on the top
face, 6061-T6. Use N-mm-MPa throughout and state the unit system in a
comment at the top of the .inp. Report peak von Mises, max deflection,
and margin against yield at FoS 2, then open the .frd so I can see it.

Checking the answer

Before I trust that: refine the mesh 2× around the peak-stress
location, rerun, and tell me how much peak von Mises moved. Then give
me a hand-calc estimate for the same load so we can see whether the
FEA is in the right ballpark.

Design iteration

Rebuild @cad/bracket.step as a parametric model and iterate it in
CalculiX to pass FoS 2 on yield at minimum mass. Free: wall thickness
(3–8 mm), rib count and height. Fixed: hole pattern, outer envelope,
3 mm minimum wall. Save each variant under its own name. Stop after 8
iterations or when mass changes by less than 2%, and give me a table:
variant, mass, peak stress, margin.

Visualizing a result

Make an .nvpost view of @runs/duct-v4: velocity magnitude on a slice
at the symmetry plane (z = 0), colour range pinned to 0–40 m/s. Export
an isometric PNG and give me the path.

Producing a deliverable

Write a structural analysis report for the bracket using the
engineering-reports template: load case and supports, mesh and mesh
convergence, peak stress and deflection with captured views, margin
table. Every number must come from a solved CalculiX run. Say which
one. PDF.

What not to do

• Do not ask for everything at once. "Design, mesh, solve, iterate, and write the report" in one message produces a long turn that is hard to review and easy to get wrong halfway through.
• Do not skip the diff. The transcript says what the agent believes it did. The diff says what it did.
• Do not assume it remembers another thread. Each thread is its own context.
• Do not trust a number you did not check. The agent is a fast, tireless engineer who occasionally states something false with complete confidence. Peak stress, mass, and convergence are all cheap to verify.