Technical Figure

Produce figures a domain peer can verify and that look deliberate: one claim per figure, the mechanism drawn as structure rather than written as text, one visual grammar across the whole document, and a render that holds up at the width and theme where it will be read. Crude figures rarely come from the drawing tool. They come from a missing plan: every box drawn with the same weight, one accent color meaning something different in each figure, and comparisons that redraw the shared structure until the difference disappears. The bundled pipeline measures what it draws. Use an established project style or another suitable authoring route when it serves the artifact; preserve the content, accessibility, and rendered review contract below.

Quick path

1. Scope. A document, a section with several figures, or a request to redo a document's figures starts with the figure plan in references/planning.md: claim inventory, figure budget, semantic map, and a thumbnail storyboard. A single standalone figure starts at step 2 and still borrows the document's semantic map when one exists.
2. FigureSpec. Record the spec, using assets/templates/figure-spec.json or the project's equivalent: the reader's question, the claim in one sentence (it becomes the caption's first sentence), the exact names and relations the peer needs, the one focal element, and what goes to the caption instead of the canvas.
3. Form. Choose the form from the claim's shape with references/form-catalog.md, not from the request's noun. Compare alternative framings when the form is uncertain or a first render fails the claim test. Select the strongest supported framing within the task; ask only when the choice depends on a consequential missing preference.
4. Grammar and tokens. Use references/grammar.md and assets/figure-tokens.json as the default visual language, explained in references/visual-tokens.md. Preserve an established document grammar when present; keep encodings consistent and legible.
5. Author. Choose a route below. For the bundled SVG renderer, follow references/svg-contract.md: classes and data-* attributes carry semantics; the renderer supplies colors, fonts, and arrowheads. Other routes keep their editable source and use their own rendering contract.
6. Render and lint. For the bundled SVG route, check dependencies with bash scripts/setup.sh --check, reusing a current successful check. Run setup without --check only when dependency installation is authorized, then node scripts/render.mjs <figure>.svg. It writes light and dark PNGs, a portable SVG, and a lint report, judged at a 704 px column unless --width says otherwise (--width 1080 for a full-width page). Fix every lint error.
7. Review. Open both PNGs and judge them at the delivery width with references/review.md: the claim is visible without the caption, the focal element reads first, every spec element is present and nothing unspecified was added. Continue until the required checks pass within the task's time and resource budget. When a defect repeats or an edit makes no progress, diagnose the cause and change the layout, form, or tool before another attempt; see the revision rules in references/review.md.
8. Deliver. For a figure set, render the contact sheet (node scripts/sheet.mjs, --columns 2 to compare framings or old and new side by side) and check the grammar holds across figures before delivering.

Run scripts from the skill directory; they resolve assets relative to themselves.

Reader and content contract