--- name: Fireworks Tech Graph slug: fireworks-tech-graph category: Frontend description: Fireworks Tech Graph creates geometry-checked technical diagrams from natural language, including architecture, flow, sequence, UML, and C4 visuals. Use it to export SVG, PNG, GIF motion, or offline interactive HTML for system and engineering concepts. github: "https://github.com/yizhiyanhua-ai/fireworks-tech-graph" language: Python stars: 9923 forks: 823 install: "npx degit https://github.com/yizhiyanhua-ai/fireworks-tech-graph ~/.claude/skills/fireworks-tech-graph" installs_to: ~/.claude/skills/fireworks-tech-graph source_path: SKILL.md collection_size: 1 category_size: 567 added: 2026-08-15T06:50:32.702Z last_synced: 2026-08-15T06:50:32.702Z canonical_url: "https://dirskills.com/skills/fireworks-tech-graph" --- # Fireworks Tech Graph Fireworks Tech Graph creates geometry-checked technical diagrams from natural language, including architecture, flow, sequence, UML, and C4 visuals. Use it to export SVG, PNG, GIF motion, or offline interactive HTML for system and engineering concepts. **Install:** ```bash npx degit https://github.com/yizhiyanhua-ai/fireworks-tech-graph ~/.claude/skills/fireworks-tech-graph ``` ## README # Fireworks Tech Graph Generate geometry-checked SVG technical diagrams, high-resolution PNG, validated SVG-to-GIF semantic motion, and sanitized offline interactive HTML. ## Runtime Compatibility Use this repository unchanged in both Codex and Claude Code. It follows the Agent Skills layout: `SKILL.md` is the shared entry point, bundled resources use relative paths, and `agents/openai.yaml` adds optional Codex UI metadata without affecting Claude Code. Before reading a reference or running a script, resolve the directory containing this `SKILL.md` as `SKILL_ROOT`. Do not assume the current working directory is the skill directory, and do not assume a variable set in one shell call persists into the next. - In Claude Code, use `${CLAUDE_SKILL_DIR}`. - In Codex, use the absolute skill directory shown in the loaded skill metadata. Every command block below sets `SKILL_ROOT` itself. In Codex, replace `/absolute/path/from-codex-skill-metadata` with the absolute skill directory before running the command. ## Helper Scripts (Recommended) The unified `scripts/fireworks.py` CLI and compatibility helpers provide stable rendering, geometry validation, inspection, animation, and export: ### 1. `generate-diagram.sh` - Validate SVG + export PNG ```bash SKILL_ROOT="${CLAUDE_SKILL_DIR:-/absolute/path/from-codex-skill-metadata}" "$SKILL_ROOT/scripts/generate-diagram.sh" -t architecture -s 1 -o ./output/arch.svg ``` - Validates an existing SVG file - Exports PNG after validation - Example: `"$SKILL_ROOT/scripts/generate-diagram.sh" -t architecture -s 1 -o ./output/arch.svg` ### 2. `generate-from-template.py` - Create starter SVG from template ```bash SKILL_ROOT="${CLAUDE_SKILL_DIR:-/absolute/path/from-codex-skill-metadata}" mkdir -p ./output python3 "$SKILL_ROOT/scripts/generate-from-template.py" architecture ./output/arch.svg '{"title":"My Diagram","nodes":[],"arrows":[]}' ``` - Loads a built-in SVG template - Renders nodes, arrows, and legend entries from JSON input - Escapes text content to keep output XML-valid ### 3. `validate-svg.sh` - Validate SVG syntax ```bash SKILL_ROOT="${CLAUDE_SKILL_DIR:-/absolute/path/from-codex-skill-metadata}" "$SKILL_ROOT/scripts/validate-svg.sh" ``` - Checks XML syntax - Verifies tag balance - Validates marker references - Checks attribute completeness - Validates path data ### 4. `test-all-styles.sh` - Batch test all styles ```bash SKILL_ROOT="${CLAUDE_SKILL_DIR:-/absolute/path/from-codex-skill-metadata}" "$SKILL_ROOT/scripts/test-all-styles.sh" ``` - Tests multiple diagram sizes - Validates all generated SVGs - Generates test report **When to use scripts:** - Use scripts when generating complex SVGs to avoid syntax errors - Scripts provide automatic validation and error reporting - Recommended for production diagrams ## Workflow (Always Follow This Order) 1. **Classify** the diagram type (see Diagram Types below) 2. **Extract structure** — identify layers, nodes, edges, flows, and semantic groups from user description 3. **Plan layout** — load `$SKILL_ROOT/references/composition-quality-contract.md`, then apply the diagram-type layout rules 4. **Load style reference** — always load `$SKILL_ROOT/references/style-1-flat-icon.md` unless user specifies another; load the matching `$SKILL_ROOT/references/style-N-*.md` for exact color tokens and SVG patterns 5. **Select semantic contract** — Styles 9–12 default to `c4-review`, `cloud-fabric`, `event-transit`, and `ops-pulse`; use `scripts/fireworks.py validate` before layout so missing or contradictory engineering facts fail closed 6. **Map nodes to shapes** — use Shape Vocabulary below 7. **Check icon needs** — load `$SKILL_ROOT/references/icons.md` for known products 8. **Write SVG** with adaptive strategy (see SVG Generation Strategy below) 9. **Validate**: Run `"$SKILL_ROOT/scripts/validate-svg.sh" file.svg` to check XML, markers, geometry, composition budgets, and renderability 10. **Export PNG**: Use `cairosvg` (recommended). Load `$SKILL_ROOT/references/png-export.md` when choosing another renderer 11. **Animate on request** — `让这张图动起来` / `生成 GIF` / `制作 GIF` / `Animate this diagram` / `Generate a GIF` means the latest generated semantic SVG to one GIF with `auto`, 5.75s, 20fps, and 960px width when that SVG satisfies one of the 12 approved motion contracts. Exact source bytes are not pinned, but role/stage/order coverage, route directions, required colors, and geometry fail closed; do not claim arbitrary same-style topologies are supported. Load `$SKILL_ROOT/references/motion-effects.md`, run `fireworks.py animate`, and report SVG/GIF/report paths. GIF is the only motion media format, while the default command also emits `.motion.json`. Styles 1–12 are enabled, and their contracts plus the shared `+2s-settled-flow` timing revision are user-approved; the default keeps frames 38–109 at full opacity and resets on frames 110–114. Every scene begins connector-free and advances its moving primitives toward each target. The 75-vs-115 compatibility gate counts binary-exact frames first, decoded-RGBA-exact frames second, and permits a guarded antialias equivalent only when AE ≤ 128, normalized RMSE ≤ 0.001, every difference component is at most 2px wide or high, and all differences remain on edge or node borders; DOM and signature geometry stay strict-exact. Reject raster animation inputs and non-GIF motion outputs. Explicit 3.75s/75-frame and 2.75s/55-frame timelines remain supported 12. **Visual review gate** — if your runtime can read images, load the exported PNG back and inspect it. Syntactic validity does not guarantee visual correctness: arrows may cross through component interiors, labels may collide with lifelines or other labels, boxes may overlap, alt-frame text may sit on top of a message, or a legend may cover content. If you see any of these, revise the SVG and re-export, with at most two focused correction passes. Common fixes: - Route arrows through gaps between boxes, not through box interiors - Move arrow labels 6-8px away from the arrow line (offset-first); add background rects only when offset is insufficient - Widen inter-row/inter-column gutters so same-layer arrows have clear corridors - Collapse repeated cross-layer arrows into a single "delegates down" rail outside the content area - Move legend/notes out of any region where arrows or labels land - Increase viewBox height/width rather than packing elements tighter - If a filtered element (drop-shadow, blur) is missing one side of its border, move it ≥30px away from that viewBox edge, or remove the filter and rely on color/contrast for visual separation Report `visual_review: passed` after inspection. If image reading is unavailable, report `visual_review: skipped (image reader unavailable)` — do not guess or claim visual correctness. ## Rule Precedence Use this order when instructions disagree: 1. The user's explicit content and style request 2. The selected `$SKILL_ROOT/references/style-N-*.md` visual tokens (palette, typography, corner radius, shadow treatment) 3. Diagram-type layout rules and semantic flow requirements in this file 4. Universal defaults and examples Geometry and validation gates always remain active: style guidance cannot justify unreadable text, missing marker definitions, or arrows crossing component interiors. Tables in this file define semantic defaults; a selected style may override their colors and stroke treatment while preserving the meaning and direction of each flow. ## Diagram Types & Layout Rules ### Architecture Diagram Nodes = services/components. Group into **horizontal layers** (top→bottom or left→right). - Typical layers: Client → Gateway/LB → Services → Data/Storage - Use `` dashed containers to group related services in the same layer - Arrow direction follows data/request flow - ViewBox: `0 0 960 600` standard, `0 0 960 800` for tall stacks ### Data Flow Diagram Emphasizes **what data moves where**. Focus on data transformation. - Label every arrow with the data type (e.g., "embeddings", "query", "context") - Use wider arrows (`stroke-width: 2.5`) for primary data paths - Dashed arrows for control/trigger flows - Color arrows by data category (not just Agent/RAG — use semantics) ### Flowchart / Process Flow Sequential decision/process steps. - Top-to-bottom preferred; left-to-right for wide flows - Diamond shapes for decisions, rounded rects for processes, parallelograms for I/O - Keep node labels short (≤3 words); put detail in sub-labels - Align nodes on a grid: x positions snap to 120px intervals, y to 80px ### Agent Architecture Diagram Shows how an AI agent reasons, uses tools, and manages memory. Key conceptual layers to always consider: - **Input layer**: User, query, trigger - **Agent core**: LLM, reasoning loop, planner - **Memory layer**: Short-term (context window), Long-term (vector/graph DB), Episodic - **Tool layer**: Tool calls, APIs, search, code execution - **Output layer**: Response, action, side-effects Use cyclic arrows (loop arcs) to show iterative reasoning. Separate memory types visually. ### Memory Architecture Diagram (Mem0, MemGPT-style) Specialized agent diagram focused on memory operations. - Show memory **write path** and **read path** separately (different arrow colors) - Memory tiers: Working Memory → Short-term → Long-term → External Store - Label memory operations: `store()`, `retrieve()`, `forget()`, `consolidate()` - Use stacked rects or layered cylinders for storage tiers ### Sequence Diagram Time-ordered message exchanges between participants. - Participants as vertical **lifelines** (top labels + vertical dashed lines) - Messages as horizontal arrows between lifelines, top-to-bottom time order - Activation boxes (thin filled rects on lifeline) show active processing - Group with `` loop/alt frames with label in top-left corner - ViewBox height = 80 + (num_messages × 50) ### Comparison / Feature Matrix Side-by-side comparison of approaches, systems, or components. - Column headers = systems, row headers = attributes - Row height: 40px; column width: min 120px; header row height: 50px - Checked cell: tinted background (e.g. `#dcfce7`) + `✓` checkmark; unsupported: `#f9fafb` fill - Alternating row fills (`#f9fafb` / `#ffffff`) for readability - Max readable columns: 5; beyond that, split into two diagrams ### Timeline / Gantt Horizontal time axis showing durations, phases, and milestones. - X-axis = time (weeks/months/quarters); Y-axis = items/tasks/phases - Bars: rounded rects, colored by category, labeled inside or beside - Milestone markers: diamond or filled circle at specific x position with label above - ViewBox: `0 0 960 400` typical; wider for many time periods: `0 0 1200 400` ### Mind Map / Concept Map Radial layout from central concept. - Central node at `cx=480, cy=280` - First-level branches: evenly distributed around center (360/N degrees) - Second-level branches: branch off first-level at 30-45° offset - Use curved `` with cubic bezier for branches, not straight lines ### Class Diagram (UML) Static structure showing classes, attributes, methods, and relationships. - **Class box**: 3-compartment rect (name / attributes / methods), min width 160px - Top compartment: class name, bold, centered (abstract = *italic*) - Middle: attributes with visibility (`+` public, `-` private, `#` protected) - Bottom: method signatures, same visibility notation - **Relationships**: - Inheritance (extends): solid line + hollow triangle arrowhead, child → parent - Implementation (interface): dashed line + hollow triangle, class → interface - Association: solid line + open arrowhead, label with multiplicity (1, 0..*, 1..*) - Aggregation: solid line + hollow diamond on container side - Composition: solid line + filled diamond on container side - Dependency: dashed line + open arrowhead - **Interface**: `<>` stereotype above name, or circle/lollipop notation - **Enum**: compartment rect with `<>` stereotype, values in bottom - Layout: parent classes top, children below; interfaces to the left/right of implementors - ViewBox: `0 0 960 600` standard; `0 0 960 800` for deep hierarchies ### Use Case Diagram (UML) System functionality from user perspective. - **Actor**: stick figure (circle head + body line) placed outside system boundary - Label below figure, 13-14px - Primary actors on left, secondary/supporting on right - **Use case**: ellipse with label centered inside, min 140×60px - Keep names verb phrases: "Create Order", "Process Payment" - **System boundary**: large rect with dashed border + system name in top-left - **Relationships**: - Include: dashed arrow `<>` from base to included use case - Extend: dashed arrow `<>` from extension to base use case - Generalization: solid line + hollow triangle (specialized → general) - Layout: system boundary centered, actors outside, use cases inside - ViewBox: `0 0 960 600` standard ### State Machine Diagram (UML) Lifecycle states and transitions of an entity. - **State**: rounded rect with state name, min 120×50px - Internal activities: small text `entry/ action`, `exit/ action`, `do/ activity` - **Initial state**: filled black circle (r=8), one outgoing arrow - **Final state**: filled circle (r=8) inside hollow circle (r=12) - **Choice**: small hollow diamond, guard labels on outgoing arrows `[condition]` - **Transition**: arrow with optional label `event [guard] / action` - Guard conditions in square brackets - Actions after `/` - **Composite/nested state**: larger rect containing sub-states, with name tab - **Fork/join**: thick horizontal or vertical black bar (synchronization) - Layout: initial state top-left, final state bottom-right, flow top-to-bottom - ViewBox: `0 0 960 600` standard ### ER Diagram (Entity-Relationship) Database schema and data relationships. - **Entity**: rect with entity name in header (bold), attributes below - Primary key attribute: underlined - Foreign key: italic or marked with (FK) - Min width: 160px; attribute font-size: 12px - **Relationship**: diamond shape on connecting line - Label inside diamond: "has", "belongs to", "enrolls in" - Cardinality labels near entity: `1`, `N`, `0..1`, `0..*`, `1..*` - **Weak entity**: double-bordered rect with double diamond relationship - **Associative entity**: diamond + rect hybrid (rect with diamond inside) - Line style: solid for identifying relationships, dashed for non-identifying - Layout: entities in 2-3 rows, relationships between related entities - ViewBox: `0 0 960 600` standard; wider `0 0 1200 600` for many entities ### Network Topology Physical or logical network infrastructure. - **Devices**: icon-like rects or rounded rects - Router: circle with cross arrows - Switch: rect with arrow grid - Server: stacked rect (rack icon) - Firewall: brick-pattern rect or shield shape - Load Balancer: horizontal split rect with arrows - Cloud: cloud path (overlapping arcs) - **Connections**: lines between device centers - Ethernet/wired: solid line, label bandwidth - Wireless: dashed line with WiFi symbol - VPN: dashed line with lock icon - **Subnets/Zones**: dashed rect containers with zone label (DMZ, Internal, External) - **Labels**: device hostname + IP below, 12-13px - Layout: tiered top-to-bottom (Internet → Edge → Core → Access → Endpoints) - ViewBox: `0 0 960 600` standard ## UML Coverage Map Full mapping of UML 14 diagram types to supported diagram types: | UML Diagram | Supported As | Notes | |-------------|-------------|-------| | Class | Class Diagram | Full UML notation | | Component | Architecture Diagram | Use colored fills per component type | | Deployment | Architecture Diagram | Add node/instance labels | | Package | Architecture Diagram | Use dashed grouping containers | | Composite Structure | Architecture Diagram | Nested rects within components | | Object | Class Diagram | Instance boxes with underlined name | | Use Case | Use Case Diagram | Full actor/ellipse/relationship | | Activity | Flowchart / Process Flow | Add fork/join bars | | State Machine | State Machine Diagram | Full UML notation | | Sequence | Sequence Diagram | Add alt/opt/loop frames | | Communication | — | Approximate with Sequence (swap axes) | | Timing | Timeline | Adapt time axis | | Interaction Overview | Flowchart | Combine activity + sequence fragments | | ER Diagram | ER Diagram | Chen/Crow's foot notation | ## Shape Vocabulary Map semantic concepts to consistent shapes across all diagram types: | Concept | Shape | Notes | |---------|-------|-------| | User / Human | Circle + body path | Stick figure or avatar | | LLM / Model | Rounded rect with brain/spark icon or gradient fill | Use accent color | | Agent / Orchestrator | Hexagon or rounded rect with double border | Signals "active controller" | | Memory (short-term) | Rounded rect, dashed border | Ephemeral = dashed | | Memory (long-term) | Cylinder (database shape) | Persistent = solid cylinder | | Vector Store | Cylinder with grid lines inside | Add 3 horizontal lines | | Graph DB | Circle cluster (3 overlapping circles) | | | Tool / Function | Gear-like rect or rect with wrench icon | | | API / Gateway | Hexagon (single border) | | | Queue / Stream | Horizontal tube (pipe shape) | | | File / Document | Folded-corner rect | | | Browser / UI | Rect with 3-dot titlebar | | | Decision | Diamond | Flowcharts only | | Process / Step | Rounded rect | Standard box | | External Service | Rect with cloud icon or dashed border | | | Data / Artifact | Parallelogram | I/O in flowcharts | ## Arrow Semantics Always assign arrow meaning, not just color. The values below are defaults; the selected style reference overrides colors and stroke weights while preserving flow semantics: | Flow Type | Color | Stroke | Dash | Meaning | |-----------|-------|--------|------|---------| | Primary data flow | blue `#2563eb` | 2px solid | none | Main request/response path | | Control / trigger | orange `#ea580c` | 1.5px solid | none | One system triggering another | | Memory read | green `#059669` | 1.5px solid | none | Retrieval from store | | Memory write | green `#059669` | 1.5px | `5,3` | Write/store operation | | Async / event | gray `#6b7280` | 1.5px | `4,2` | Non-blocking, event-driven | | Embedding / transform | purple `#7c3aed` | 1px solid | none | Data transformation | | Feedback / loop | purple `#7c3aed` | 1.5px curved | none | Iterative reasoning loop | Always include a **legend** when 2+ arrow types are used. ## Layout Rules & Validation **Spacing**: - Same-layer nodes: 80px horizontal, 120px vertical between layers - Canvas margins: 40px minimum, 60px between node edges - Snap to 8px grid: horizontal 120px intervals, vertical 120px intervals **Arrow Labels** (CRITICAL): - **Offset-first** (default): place label 6-8px above horizontal arrows, or 8px left/right of vertical arrows — do not overlap the arrow line - **Background fallback**: add `` only when the offset label still crosses another visual element (another arrow, a node edge, etc.) - Place mid-arrow, ≤3 words, stagger by 15-20px when multiple arrows converge - Maintain 10px safety distance from nodes **Arrow Routing**: - Prefer orthogonal (L-shaped) paths to minimize crossings - Anchor arrows on component edges, not geometric centers - Route around dense node clusters, use different y-offsets for parallel arrows - Jump-over arcs (5px radius) for unavoidable crossings - Compress equivalent bidirectional traffic only when both directions share the same semantics and styling: use one corridor with `marker-start` + `marker-end`, or two visibly offset paths in that corridor - Keep read/write, request/response, sync/async, or differently labeled directions as separate arrows; remove redundant bends and duplicate rails without erasing direction or meaning