Describe

pc:describe

Produce a text description of an existing PartCAD shape by rendering it and looking at the result — the replacement for PartCAD's retired built-in AI summary. The text after the command ($ARGUMENTS) names the object to describe (optionally with its kind).

One picture is not enough to describe a shape. A single projection hides everything behind it, and a description written from one is a description of a silhouette. Render three views (§3), and where a dimensioned drawing can be had, read the numbers off that rather than estimating them (§4).

Nor is any picture enough to give a size. A projection is rendered to fit its frame, so nothing in it says whether the part is 20 mm across or 200 — which is why this starts by asking PartCAD what it measured (§2) and never estimates a dimension a number was available for.

1. Resolve the object

$ARGUMENTS is the object name (a part by default; an assembly or sketch if the user says so). Read its desc:/requirements: from partcad.yaml for context. Make sure PartCAD is available as /pc:init describes.

Pass --no-ansi on every run so the output is plain text; it is a global flag, goes before the subcommand, and routes the logs to stderr.

This skill describes an object a package declares, because §6 stores the result back into that package. To describe a bare CAD file that is in no package, render it with /pc:render (pc adhoc render) and write the description for the user instead of storing it.

2. Measure it

pc info reports what PartCAD measured when it built the object, and those are the numbers this description is anchored on:

pc --no-ansi info <name> 2>&1   # add -a / -s for an assembly or a sketch

Read all of it. The measurements are the first thing to look for, but the sections below are what the design says about itself, and a filter narrow enough to catch BoundingBox would cut them off.

• BoundingBox — min, max and size in millimetres. size is the overall envelope of the design: state it, and give every other dimension in proportion to it rather than in pixels.
• Volume — how much material is in it, in cubic millimetres, with Solids saying how many solids that is the volume of. More than one solid in a part is worth saying out loud: it is usually either deliberate (a part that is two pieces) or a mistake nobody has noticed. A negative volume means the faces are oriented inward — report that as a defect rather than dropping the sign.
• A sketch, a shell or a wire has no volume, and pc info says so by leaving Volume out. It is flat, so its bounding box is its size.

The rest of what pc info prints is worth a look too, and for an object read from a file it is where the design's own words are: a STEP file's File, Products, Layers and Properties, a DXF sketch's Drawing, Layers and Annotations — including the angle, radius and direction of a sheet metal bend. Anything stated there is the design's own and beats a reading off a picture.

The first run builds and measures the object, so it is slow; every run after it is a cache hit. If it fails — no sandbox, a part that does not build — say so in the report and describe the shape from the views alone, without inventing a size.

3. Render three views

front, top and iso: two orthographic views to read proportion and features from, and one pictorial view that shows how they go together. A rendered file is named after the object, so give each view a directory of its own or they overwrite each other:

for view in front top iso; do
  mkdir -p /tmp/pc-render/$view
  pc --no-ansi render -t png --view $view -O /tmp/pc-render/$view <name>   # add -a for an assembly
done

View all three — /tmp/pc-render/<view>/<name>.png.

Add right (or back, left, bottom) when the three leave a face unaccounted for: a part that is not symmetric about an axis has a side you have not seen, and guessing at it is exactly what this skill must not do.

A sketch is flat, so it has only one view worth rendering, and SVG suits it better than PNG:

mkdir -p /tmp/pc-render
pc --no-ansi render -s -t svg -O /tmp/pc-render <name>