/anthropic-style-diagram

name: anthropic-style-diagram
description: "Draw architecture, flow and structural diagrams in the Anthropic/Claude visual language as SVG, then render and save them as PNG. Trigger ONLY when the user names that visual language — 'Anthropic 风格架构图', 'Claude 风格流程图', 'Anthropic style diagram', 'Claude style flowchart', 'Anthropic 配色的图' — or asks for another diagram in the same style after this skill has already produced one in the conversation. Also use to re-render or export an SVG that already uses this skill's class system (th/ts/box/arr/c-blue…). Do NOT use for a plain 画图/画流程图/draw a diagram request with no style named, for data charts, UI mockups, illustrations, TikZ or mermaid output, or database ERDs."

Anthropic Style Diagram

Author a semantic SVG, let the browser do the rest. `scripts/render.mjs` supplies the design system, resolves the theme, audits the layout, crops the viewBox to the real ink bounds, bakes every computed style into literal attributes, and writes the PNG.

**You draw geometry and meaning. The script owns colour, theme, viewBox and export.** Never hardcode a hex value, never write a `<style>` block, never compute the final viewBox height by hand.

Workflow

1. **Plan before drawing.** Count the nodes and group them by kind — one colour ramp per kind, never one per row. Decide the diagram type (see below). If the user named 6+ components, split into an overview plus one diagram per sub-flow rather than cramming one canvas. 2. **Write the SVG** to a working path (scratchpad or `/tmp`), not the delivery path. Follow the authoring contract below; `references/example-structural.svg` and `references/example-cycle.svg` are the canonical shapes to imitate. 3. **Render**: `node scripts/render.mjs <working.svg> -o <target.png>`. 4. **Clear the audit.** Layout warnings print on stdout. Fix every one and re-render until the run is clean. A clean run only means nothing collides — that is the floor, not the bar. 5. **Review the render yourself** against the checklist below. Any failure sends you back to step 2. This step is not optional: the audit measures geometry, and almost everything that makes a diagram *wrong* lives outside geometry. 6. **Report** the saved path, and say what the review turned up.

The review checklist

Read the rendered image, not your source. The source is what you meant; the image is what the reader gets, and only one of those can be wrong.

1. **Read it cold.** Set aside what you set out to draw and say what the picture actually claims. If that differs from the request, the diagram is wrong — not the reader. 2. **Trace every arrow.** Each must start and end on the shape it means, and its direction must assert something true. An arrow down the page claims the lower node is used by the upper one; say that claim out loud and check it. Placing a component below another is an assertion, not a layout convenience. 3. **Find the loop.** If the subject has feedback — an agent, a control system, a retry path, a training cycle — locate the return edge in the image. If you cannot see it, it is not there, and a one-way drawing of a loop is simply false. 4. **Read every label.** Accurate, ≤5 words, sentence case, unclipped, and not claiming more than the system does. 5. **Check the colour.** Same colour must mean same category. If two nodes share a ramp only because they were next in the list, re-assign. 6. **Scan the whitespace.** Crowded regions and dead regions are both defects, and a uniform grid of same-sized boxes means the layout is carrying no information.

Rendering

node scripts/render.mjs diagram.svg -o ~/Downloads/architecture.png

| Option | Default | Notes | |---|---|---| | `-o, --out <path>` | `./<name>.png` | Parent directories are created | | `--theme <t>` | `light` | `light`, `dark`, or `both` (writes `<name>-dark.png` too) | | `--scale <n>` | `2` | Pixel density. `3`–`4` for print or large social images | | `--bg <v>` | `auto` | Theme paper colour; or `transparent`, or any `#rrggbb` | | `--padding <n>` | `32` | Margin around content after cropping | | `--no-fit` | — | Keep the authored viewBox instead of cropping to ink bounds | | `--svg` | — | Also write a portable flattened `.svg` (no CSS, opens anywhere) | | `--check` | — | Audit only, write nothing; exits non-zero when problems exist | | `--json` | — | Machine-readable report |

The audit catches the three *mechanical* failure modes: text spilling out of its shape, nodes overlapping, and connectors slicing through unrelated nodes. Round nodes are measured as ellipses rather than as their bounding box, so ring layouts are checked as strictly as grids. A clean run prints only the output paths. It says nothing about whether the diagram is well composed or even correct — see "Composition" below, and never treat a clean audit as approval.

First run needs Playwright. It is picked up from the skill, the project, or the global npm root; if missing, `npm install` in this directory.

Authoring contract

<svg viewBox="0 0 680 H" role="img">
  <title>Short name</title>
  <desc>One sentence describing what the diagram shows.</desc>
  <defs>
    <marker id="arrow" viewBox="0 0 10 10" refX="8" refY="5" markerWidth="6" markerHeight="6" orient="auto-start-reverse">
      <path d="M2 1L8 5L2 9" fill="none" stroke="context-stroke" stroke-width="1.5" stroke-linecap="round" stroke-linejoin="round"/>
    </marker>
  </defs>
  ...
</svg>

• `role="img"` with `<title>` and `<desc>` as the first two children. Always.
• **Canvas width 680** by default — the text-width table below is calibrated to it.

Widen to at most ~1000 when the content genuinely needs more columns; never shrink to hug narrow content, centre it instead.

• Height is a rough guess. The renderer crops to the true bounds, so overestimate

rather than clip.

• No `<script>`, no `onclick`, no `sendPrompt`, no `<a href>`, no gradients, no

filters