$npx -y skills add yzlnew/infra-skills --skill anthropic-theme-flowchartCreate and revise pure HTML/CSS flowcharts using an Anthropic-inspired design language. Use when Codex needs to produce process diagrams, decision trees, pipelines, or system flows that should share warm ivory backgrounds, transparent dashed grouping containers, pastel node fills
| 1 | # Anthropic Flowcharts In HTML/CSS |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Build flowcharts as standalone HTML/CSS artifacts using one visual system: warm neutral surfaces, pastel role-based fills, transparent dashed grouping containers, slightly tighter rounded nodes, quiet orthogonal connectors, and concise sans-serif labeling with primary/secondary color hierarchy. Use this skill when the user wants the highest-fidelity result rather than diagram-tool compatibility. |
| 6 | |
| 7 | ## Workflow |
| 8 | |
| 9 | 1. Reduce the process to 4-8 nodes before writing syntax. |
| 10 | 2. Choose a layout: |
| 11 | - Use a two-lane grouped layout when the process splits across active and background systems. |
| 12 | - Use a single-column stack when the process is strictly sequential or mobile-first. |
| 13 | 3. Start from the HTML references: |
| 14 | - Shared tokens: `references/design-language.md` |
| 15 | - HTML guidance: `references/html-flowchart.md` |
| 16 | - Generator entrypoint: `src/build.ts` |
| 17 | - Diagram specs: `src/diagrams/*.ts` |
| 18 | 4. Assign 4-6 role colors from the shared pastel palette instead of falling back to monochrome. |
| 19 | 5. Keep labels short and use intentional line breaks only when they improve scanning. |
| 20 | 6. Split label hierarchy: |
| 21 | - Primary line should use a near-black version of the node's own theme color. |
| 22 | - Secondary line should use a deeper version of the node's own theme color. |
| 23 | 7. Prefer one coordinate system for nodes and connectors: |
| 24 | - Use inline SVG with `foreignObject` cards when connector accuracy matters. |
| 25 | - Route arrows from explicit edge anchors, not approximate floating overlays. |
| 26 | 8. Keep connector routing deterministic: |
| 27 | - Prefer orthogonal elbow connectors over curves. |
| 28 | - Use hollow `>` arrowheads instead of filled triangle tips. |
| 29 | - Match connector annotation font size to the node secondary line. |
| 30 | 9. When lanes sit in separate SVGs: |
| 31 | - Match CSS grid column widths to the SVG `viewBox` widths to avoid hidden scaling drift. |
| 32 | - Add geometry comments that name each node's west/east/north/south center anchors before the connector paths. |
| 33 | |
| 34 | ## Labeling Rules |
| 35 | |
| 36 | - Keep labels to 2 lines whenever possible. |
| 37 | - Use sentence case, not all caps, inside nodes. |
| 38 | - Use one short noun phrase plus one short supporting phrase. |
| 39 | - If a trailing word is semantically weaker, move it into the secondary line. |
| 40 | - Example: `Observation` + `collector`, `System prompt` + `injection`. |
| 41 | - Prefer verbs that imply progression: define, review, route, validate, deliver. |
| 42 | - Use sans-serif in all flow boxes, lane labels, and connector annotations. |
| 43 | - Reduce corner radii slightly compared with editorial card layouts. The target is diagrammatic, not pill-like. |
| 44 | - Avoid pure black text inside nodes. Primary text should still be theme-aware. |
| 45 | - Make the primary line slightly larger and heavier than the secondary line, but keep lane labels regular weight. |
| 46 | |
| 47 | ## HTML/CSS Mapping |
| 48 | |
| 49 | - Use pure HTML/CSS for every output in this skill. |
| 50 | - Author diagrams in TS specs and generate HTML from them; do not hand-maintain connector coordinates in `assets/*.html`. |
| 51 | - Default to an SF Pro-style system stack: |
| 52 | - Body and annotations: `"SF Pro Text", "SF Pro Display", -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Segoe UI", sans-serif` |
| 53 | - Node headings: `"SF Pro Display", "SF Pro Text", -apple-system, BlinkMacSystemFont, "Helvetica Neue", "Segoe UI", sans-serif` |
| 54 | - Keep the full diagram sans-serif when the output should match modern product diagrams more than editorial pages. |
| 55 | - Use smaller card radii than a landing page UI and keep shadows restrained. |
| 56 | - Use inline SVG when connectors need exact control. |
| 57 | - Keep connector strokes thin and quiet. Arrowheads should feel technical, not illustrative. |
| 58 | - Default dashed grouping frames to transparent fills. |
| 59 | - For grouped layouts, put the secondary lane title inside the dashed frame when that keeps the grouping visually clearer. |
| 60 | - Preserve mobile readability by collapsing multi-column or alternating layouts into a single vertical stack. |
| 61 | |
| 62 | ## Connector Discipline |
| 63 | |
| 64 | - Treat each node as a rectangle with explicit anchor points: |
| 65 | - `north = (x + w / 2, y)` |
| 66 | - `south = (x + w / 2, y + h)` |
| 67 | - `west = (x, y + h / 2)` |
| 68 | - `east = (x + w, y + h / 2)` |
| 69 | - Write connector coordinates from those anchors, then leave a short HTML comment showing the derivation. |
| 70 | - If a connector crosses between separate SVG columns, document the cross-column transform in a short comment block. |
| 71 | - When the visual needs to bridge from a node in one SVG to a connector in another, either: |
| 72 | - add a short stub from the node edge to the column boundary, or |