mirror of
https://github.com/JimLiu/baoyu-skills.git
synced 2026-08-02 15:19:48 +08:00
feat(baoyu-diagram): add multi-diagram mode for article-wide diagram generation
- New multi-diagram mode: analyze article content and generate diagrams at identified positions
- New options: --density (minimal/balanced/per-section/rich), --mode (single/multi/auto)
- Auto mode detection: file path or multi-paragraph content → multi, short topic → single
- Output structure: diagram/{article-slug}/NN-{type}-{slug}/diagram.svg + outline.md
- Step 7: insert diagram image links into article at identified positions
- Modification guide: regenerate/add/remove individual diagrams
- Version bumped to 1.1.0 in SKILL.md
This commit is contained in:
Jim Liu 宝玉
+251
-55
@@ -1,7 +1,7 @@
|
||||
---
|
||||
name: baoyu-diagram
|
||||
description: Generates publication-ready SVG diagrams — flowcharts, sequence/protocol diagrams, structural/architecture diagrams, and illustrative intuition diagrams — by writing real SVG code directly following a cohesive design system. Use whenever the user asks to "draw a flowchart", "draw a sequence diagram", "show the OAuth / TCP / auth protocol", "make an architecture diagram", "explain how X works visually", "画流程图", "画时序图", "画架构图", "画示意图", "画图解", or wants a clean, embeddable vector diagram for articles, WeChat posts, slides, or docs. Output is a single self-contained .svg file that renders correctly in light and dark mode anywhere it is embedded.
|
||||
version: 1.0.0
|
||||
description: Generates publication-ready SVG diagrams — flowcharts, sequence/protocol diagrams, structural/architecture diagrams, and illustrative intuition diagrams — by writing real SVG code directly following a cohesive design system. Supports both single-diagram mode (topic-based) and multi-diagram mode (analyze article content and generate multiple diagrams at identified positions). Use whenever the user asks to "draw a flowchart", "draw a sequence diagram", "show the OAuth / TCP / auth protocol", "make an architecture diagram", "explain how X works visually", "illustrate this article with diagrams", "为文章画图解", "画流程图", "画时序图", "画架构图", "画示意图", "画图解", or wants clean, embeddable vector diagrams for articles, WeChat posts, slides, or docs. Output is one or more self-contained .svg files that render correctly in light and dark mode anywhere they are embedded.
|
||||
version: 1.1.0
|
||||
metadata:
|
||||
openclaw:
|
||||
homepage: https://github.com/JimLiu/baoyu-skills#baoyu-diagram
|
||||
@@ -9,12 +9,16 @@ metadata:
|
||||
|
||||
# Diagram Generator
|
||||
|
||||
Write **real SVG code** directly, following a consistent design system, the output is a single `.svg` file that is self-contained (embedded styles, auto dark-mode), editable by humans, scales to any size without quality loss, and embeds cleanly into articles, WeChat posts, slide decks, Notion, and markdown.
|
||||
Write **real SVG code** directly, following a consistent design system, the output is self-contained `.svg` files (embedded styles, auto dark-mode), editable by humans, scales to any size without quality loss, and embeds cleanly into articles, WeChat posts, slide decks, Notion, and markdown.
|
||||
|
||||
When given article or document content, the skill analyzes structure, identifies concepts that benefit from diagramming, and generates multiple diagrams — each with its own type, layout plan, and SVG. When given a single topic, it generates one diagram.
|
||||
|
||||
This is not an image-generation skill — it does not call any LLM image model. Claude writes the SVG node-by-node, doing the layout math by hand so every diagram honors the rules in `references/`.
|
||||
|
||||
## Usage
|
||||
|
||||
### Single-diagram mode
|
||||
|
||||
```bash
|
||||
# Prompt for the topic if no argument given
|
||||
/baoyu-diagram
|
||||
@@ -22,8 +26,8 @@ This is not an image-generation skill — it does not call any LLM image model.
|
||||
# Plain-text description
|
||||
/baoyu-diagram "how JWT authentication works"
|
||||
|
||||
# Path to a markdown file as source content
|
||||
/baoyu-diagram path/to/content.md
|
||||
# Path to a markdown file as source content (single diagram about one topic)
|
||||
/baoyu-diagram path/to/content.md --mode single
|
||||
|
||||
# Force a specific diagram type
|
||||
/baoyu-diagram "transformer attention" --type illustrative
|
||||
@@ -37,13 +41,41 @@ This is not an image-generation skill — it does not call any LLM image model.
|
||||
/baoyu-diagram "build pipeline" --out docs/build-pipeline.svg
|
||||
```
|
||||
|
||||
### Multi-diagram mode
|
||||
|
||||
```bash
|
||||
# Analyze article and generate diagrams at identified positions
|
||||
/baoyu-diagram path/to/article.md
|
||||
|
||||
# With density control
|
||||
/baoyu-diagram path/to/article.md --density balanced
|
||||
/baoyu-diagram path/to/article.md --density per-section --lang zh
|
||||
|
||||
# Force multi mode on pasted content
|
||||
/baoyu-diagram --mode multi
|
||||
```
|
||||
|
||||
### Mode detection
|
||||
|
||||
| Signal | Mode |
|
||||
|--------|------|
|
||||
| File path to `.md` / `.txt` (unless `--mode single`) | **Multi** |
|
||||
| Multi-paragraph pasted content (unless `--mode single`) | **Multi** |
|
||||
| Short quoted topic string (under ~100 chars, no markdown structure) | **Single** |
|
||||
| `--type` given | **Single** (forces) |
|
||||
| `--out` given | **Single** (forces) |
|
||||
| `--mode single` or `--mode multi` | Forced by flag |
|
||||
| Ambiguous | Ask with AskUserQuestion |
|
||||
|
||||
## Options
|
||||
|
||||
| Option | Values |
|
||||
|--------|--------|
|
||||
| `--type` | `flowchart`, `sequence`, `structural`, `illustrative`, `class`, `auto` (default — route on verb) |
|
||||
| `--type` | `flowchart`, `sequence`, `structural`, `illustrative`, `class`, `auto` (default — route on verb). Forces single-diagram mode. |
|
||||
| `--lang` | `en`, `zh`, `ja`, `ko`, ... (default: match the user's language) |
|
||||
| `--out` | Output file path (default: `diagram/{slug}/diagram.svg`) |
|
||||
| `--out` | Output file path (default: `diagram/{slug}/diagram.svg`). Forces single-diagram mode. |
|
||||
| `--density` | `minimal` (1-2), `balanced` (3-5, default), `per-section`, `rich` (6+). Multi-diagram mode only. |
|
||||
| `--mode` | `single`, `multi`, `auto` (default). Override automatic mode detection. |
|
||||
|
||||
## Diagram types
|
||||
|
||||
@@ -108,11 +140,116 @@ Cycles, ERDs, and gantt charts are **out of scope for v1**. For cycles, draw the
|
||||
|
||||
## Workflow
|
||||
|
||||
### Step 1: Capture intent
|
||||
### Step 1: Detect mode and capture input
|
||||
|
||||
Read the user's prompt or content file. If the topic is missing, ask for it with AskUserQuestion.
|
||||
Read the user's prompt, content file, or pasted content. Determine the mode:
|
||||
|
||||
**Before routing, extract these five things from the source:**
|
||||
| Signal | Mode |
|
||||
|--------|------|
|
||||
| Short topic string, `--type` given, or `--out` given | **Single** |
|
||||
| File path to `.md` / `.txt`, or multi-paragraph pasted content | **Multi** |
|
||||
| `--mode single` or `--mode multi` | Forced by flag |
|
||||
| Ambiguous (medium-length text, unclear if topic or content) | Ask with AskUserQuestion |
|
||||
|
||||
**Single mode** → jump to Step 5.
|
||||
|
||||
**Multi mode** → continue to Step 2.
|
||||
|
||||
If input is a file path, read the file. If input is pasted content, note it for saving later. If no input at all, ask for it with AskUserQuestion.
|
||||
|
||||
### Step 2: Analyze content (multi-diagram mode)
|
||||
|
||||
Analyze the article or document for diagramming opportunities. For each section or concept cluster, determine:
|
||||
|
||||
| Analysis | Output |
|
||||
|----------|--------|
|
||||
| Content structure | Sections, subsections, key transitions |
|
||||
| Core concepts | 2-8 concepts that benefit from visual explanation |
|
||||
| Diagram positions | Where in the article each diagram belongs (anchored to specific paragraphs or headings) |
|
||||
| Per-position type signal | What verb/need drives each diagram (→ routing table in "Diagram types") |
|
||||
| Per-position complexity | Simple (3-4 nodes) vs. complex (poster/subsystem) |
|
||||
|
||||
**What to diagram:**
|
||||
- Core mechanisms the reader needs to *understand* (→ illustrative)
|
||||
- Multi-step processes described in prose (→ flowchart)
|
||||
- Multi-actor interactions (→ sequence)
|
||||
- Architectural descriptions with containment or hierarchy (→ structural)
|
||||
- Type hierarchies or data models (→ class)
|
||||
- Comparisons between two approaches or systems (→ structural subsystem)
|
||||
|
||||
**What NOT to diagram:**
|
||||
- Simple lists — a bullet list is already visual enough
|
||||
- Concepts already shown in an existing image or figure in the article
|
||||
- Purely emotional or narrative passages with no underlying mechanism
|
||||
- Content that is a single sentence or trivially simple
|
||||
- Decorative filler — every diagram must earn its place with a concrete reader need
|
||||
|
||||
**Output**: A list of N candidate diagram positions, each with: section anchor, tentative type, named elements, and the "After seeing this diagram, the reader understands ___" sentence.
|
||||
|
||||
### Step 3: Confirm settings (multi-diagram mode)
|
||||
|
||||
**ONE AskUserQuestion, max 3 questions. Q1 required. Q2 required unless `--density` given.**
|
||||
|
||||
| Q | When to ask | Options |
|
||||
|---|-------------|---------|
|
||||
| **Q1: Diagram positions** | Always | Show the N candidate positions with tentative types. "I identified N positions for diagrams: [numbered list with section anchor + type + one-line purpose]. Adjust, add, or remove?" |
|
||||
| **Q2: Density** | No `--density` flag | minimal (1-2 core concepts only), balanced (3-5 major concepts, Recommended), per-section (one per section/chapter), rich (6+ comprehensive) |
|
||||
| **Q3: Language** | Article language ≠ user's language or `--lang` | Which language for diagram labels? |
|
||||
|
||||
After confirmation, finalize the list of diagrams to generate. If the user adjusts positions or types, update accordingly.
|
||||
|
||||
### Step 4: Generate outline (multi-diagram mode)
|
||||
|
||||
Save `outline.md` with YAML frontmatter and per-diagram entries:
|
||||
|
||||
```yaml
|
||||
---
|
||||
article: path/to/article.md # or "pasted content"
|
||||
slug: article-topic-slug
|
||||
density: balanced
|
||||
diagram_count: 4
|
||||
language: en
|
||||
---
|
||||
```
|
||||
|
||||
Per-diagram entry format:
|
||||
|
||||
```markdown
|
||||
## Diagram 1
|
||||
**Position**: [section name / paragraph anchor, e.g. "Section 2, after 'Authentication is the first step...'"]
|
||||
**Purpose**: [why this diagram helps the reader]
|
||||
**Type**: [flowchart | sequence | structural | illustrative | class]
|
||||
**Named elements**: [list of actors, components, states, or concepts]
|
||||
**Reader need**: "After seeing this diagram, the reader understands ___"
|
||||
**Slug**: [2-4 kebab-case words]
|
||||
**Filename**: 01-{type}-{slug}/diagram.svg
|
||||
```
|
||||
|
||||
**Requirements**:
|
||||
- Each position justified by a concrete reader need (the "After seeing this..." sentence)
|
||||
- Type chosen per the routing table, not arbitrarily
|
||||
- Count matches the confirmed density
|
||||
- If input was pasted content, also save it as `source-{slug}.md` in the output directory
|
||||
|
||||
Save to `diagram/{article-slug}/outline.md`.
|
||||
|
||||
### Step 5: Load shared references
|
||||
|
||||
**Always read**:
|
||||
- `references/design-system.md` — philosophy, typography, color palette, hard rules
|
||||
- `references/svg-template.md` — the `<style>` + `<defs>` boilerplate to copy verbatim
|
||||
- `references/layout-math.md` — text-width estimation, viewBox sizing, arrow routing
|
||||
- `references/pitfalls.md` — the pre-save checklist
|
||||
|
||||
Per-type reference files are loaded inside the generation loop (Step 6b) since each diagram may have a different type.
|
||||
|
||||
### Step 6: Per-diagram generation loop
|
||||
|
||||
For each diagram (single iteration in single mode, N iterations in multi mode):
|
||||
|
||||
#### 6a: Capture intent
|
||||
|
||||
**Single mode**: Read the user's prompt. Extract these five things from the source:
|
||||
|
||||
1. **Named elements** — list every distinct actor, component, service, state, or phase explicitly named. Count them. If the count is 6+, plan multiple diagrams rather than cramming everything into one (see `flowchart.md` → "Planning before you write SVG").
|
||||
|
||||
@@ -125,23 +262,17 @@ Read the user's prompt or content file. If the topic is missing, ask for it with
|
||||
|
||||
3. **What the reader needs** — complete this sentence before routing: *"After seeing this diagram, the reader understands ___."* If you can't finish it, the topic is underspecified — ask.
|
||||
|
||||
4. **Label preview** — for each element name, count the characters. Latin titles >30 chars (CJK >16) will overflow a 180-wide box and need shortening. Draft the abbreviated form now, before layout math, so Step 4 uses real labels.
|
||||
4. **Label preview** — for each element name, count the characters. Latin titles >30 chars (CJK >16) will overflow a 180-wide box and need shortening. Draft the abbreviated form now, before layout math, so Step 6d uses real labels.
|
||||
|
||||
5. **Language** — CJK vs. Latin. Affects text-width multipliers in Step 4 (15 px/char vs. 8 px/char for titles). Mixed content (CJK labels with some Latin terms) counts as CJK.
|
||||
5. **Language** — CJK vs. Latin. Affects text-width multipliers in Step 6d (15 px/char vs. 8 px/char for titles). Mixed content (CJK labels with some Latin terms) counts as CJK.
|
||||
|
||||
### Step 2: Route the diagram type
|
||||
**Multi mode**: Most of this was already done in Steps 2/4. Read the current diagram's outline entry. Refine the named elements and label preview now, for this specific diagram.
|
||||
|
||||
Match the user's phrasing to the table above. If `--type` is given, use it. Otherwise route on the verb. When genuinely ambiguous between flowchart and illustrative, default to **illustrative** — the reader almost always benefits more from intuition than from a list of steps.
|
||||
#### 6b: Route type and load type reference
|
||||
|
||||
Tell the user which type you picked and why, in one sentence. Do not ask for confirmation — the type can always be changed with `--type` on a rerun.
|
||||
**Single mode**: Match the user's phrasing to the routing table in "Diagram types". If `--type` is given, use it. Otherwise route on the verb. When genuinely ambiguous between flowchart and illustrative, default to **illustrative**. Tell the user which type you picked and why, in one sentence.
|
||||
|
||||
### Step 3: Load references
|
||||
|
||||
**Always read**:
|
||||
- `references/design-system.md` — philosophy, typography, color palette, hard rules
|
||||
- `references/svg-template.md` — the `<style>` + `<defs>` boilerplate to copy verbatim
|
||||
- `references/layout-math.md` — text-width estimation, viewBox sizing, arrow routing
|
||||
- `references/pitfalls.md` — the pre-save checklist
|
||||
**Multi mode**: The type was already determined in the outline. Load the matching reference file now.
|
||||
|
||||
**Read the one that matches the type**:
|
||||
- `references/flowchart.md`
|
||||
@@ -154,36 +285,36 @@ Tell the user which type you picked and why, in one sentence. Do not ask for con
|
||||
- `references/glyphs.md` — the shared glyph library, tool card icon set, operator icons, and dark-mode rules
|
||||
|
||||
**Read on demand for diagram type extensions:**
|
||||
- `references/flowchart-poster.md` — when ≥3 poster-mode triggers fire in Step 4a (topic has a short name, named phases, parallel candidates, a loop termination mechanic, overflow annotations, or a footer quote)
|
||||
- `references/flowchart-phase-bands.md` — when the prompt describes a multi-phase sequential operation where each phase contains parallel tools or steps and outcomes propagate between phases ("phase 1/2/3", "attack phases", "phased workflow with tools")
|
||||
- `references/structural-network.md` — when drawing network topology: zone containers, wired/wireless device connectivity, security zones (DMZ / VPC / firewall)
|
||||
- `references/structural-matrix.md` — when drawing a comparison matrix: feature table, ✓/✗ cells, side-by-side "option × attribute" grid
|
||||
- `references/flowchart-poster.md` — when ≥3 poster-mode triggers fire in Step 6d (topic has a short name, named phases, parallel candidates, a loop termination mechanic, overflow annotations, or a footer quote)
|
||||
- `references/flowchart-phase-bands.md` — when the prompt describes a multi-phase sequential operation where each phase contains parallel tools or steps and outcomes propagate between phases
|
||||
- `references/structural-network.md` — when drawing network topology: zone containers, wired/wireless device connectivity, security zones
|
||||
- `references/structural-matrix.md` — when drawing a comparison matrix: feature table, ✓/✗ cells, side-by-side grid
|
||||
|
||||
### Step 3.5: Check the patterns library
|
||||
#### 6c: Check patterns library
|
||||
|
||||
If the user's topic matches a known AI-system pattern (multi-agent research, message bus, shared state, agent with skills, contextual retrieval), there is a pre-cooked starter plan in `references/patterns/`. Scan `references/patterns/README.md` for a pattern name that matches the prompt. If one matches, load that pattern file and use its mermaid reference + baoyu SVG plan as the starting point for Step 4 — the node list, widths, and arrow routing are already drafted, and you only need to adapt labels.
|
||||
If the topic matches a known AI-system pattern, there is a pre-cooked starter plan in `references/patterns/`. Scan `references/patterns/README.md` for a pattern name that matches. If one matches, load that pattern file and use its mermaid reference + baoyu SVG plan as the starting point for Step 6d.
|
||||
|
||||
If nothing matches, skip this step and plan from scratch in Step 4. Do not force a near-miss: two patterns that share a surface name may have genuinely different topologies, and using the wrong pre-plan is worse than planning from scratch.
|
||||
If nothing matches, skip and plan from scratch in Step 6d. Do not force a near-miss.
|
||||
|
||||
### Step 4: Plan on paper first
|
||||
#### 6d: Plan on paper
|
||||
|
||||
Before writing any SVG, draft a short layout plan. Do the math once, correctly, so the SVG comes out right on the first pass.
|
||||
|
||||
**4a. Extract structure from the source** — don't just transcribe the user's bullets into boxes. Read the source looking for these elements. Not every element will be present, but every present element should land in the diagram:
|
||||
**6d-i. Extract structure from the source** — don't just transcribe bullets into boxes. Read the source looking for these elements. Not every element will be present, but every present element should land in the diagram:
|
||||
|
||||
- **Mechanism name** — does the topic have a short, nameable identity (Autoreason, AutoResearch, OAuth, JWT auth, Reflexion loop)? If yes, that's a candidate `.title`.
|
||||
- **Framing question** — does the source contain a "why does this exist" sentence? Usually in the form *"Problem X has no Y, so we built Z to …"*. That's a candidate subtitle.
|
||||
- **Phases** — do the stages naturally cluster into 2–4 named groups (setup / loop body / judgment / convergence)? Each cluster is a candidate `.eyebrow` section.
|
||||
- **Framing question** — does the source contain a "why does this exist" sentence? That's a candidate subtitle.
|
||||
- **Phases** — do the stages naturally cluster into 2–4 named groups? Each cluster is a candidate `.eyebrow` section.
|
||||
- **Anchor inputs** — is there a constant input (the task prompt, a dataset, a knowledge base) that every stage references? That's a candidate anchor box above the main flow.
|
||||
- **Parallel candidates** — at some point, does the process generate N alternatives that are then compared? "Produce A, B, AB and pick the best" is a candidate fan-out + judge pattern. **Watch for the implicit "keep unchanged" candidate** — many iterative methods include "the incumbent wins by default" as one of the options, even when the source doesn't name it explicitly.
|
||||
- **Loop scope + termination** — which boxes are inside a loop that repeats? What is the *specific* termination rule — streak counter, convergence check, iteration cap, quality threshold? That's a candidate left-rail loop bracket + a dedicated termination box.
|
||||
- **Per-box context that won't fit in a subtitle** — "sees task + A + critique / adversarial / fresh context" is too long for a 5-word subtitle but too important to drop. Those are candidate right-column `.anno` annotations.
|
||||
- **Parallel candidates** — at some point, does the process generate N alternatives that are then compared? **Watch for the implicit "keep unchanged" candidate.**
|
||||
- **Loop scope + termination** — which boxes are inside a loop that repeats? What is the *specific* termination rule? That's a candidate left-rail loop bracket + a dedicated termination box.
|
||||
- **Per-box context that won't fit in a subtitle** — those are candidate right-column `.anno` annotations.
|
||||
- **Quotable hook** — does the source end with a test result, a quote, or a memorable framing? That's a candidate footer `.caption`.
|
||||
- **Role categories** — how many *distinct kinds* of operation does the process have (draft / critique / synthesize / judge)? This determines the color budget. Identity is a category, not a sequence.
|
||||
- **Role categories** — how many *distinct kinds* of operation does the process have? This determines the color budget. Identity is a category, not a sequence.
|
||||
|
||||
Write the answers to these in the plan file. If ≥3 of them land, you're building a **poster flowchart** — load `references/flowchart-poster.md` and follow its coordinate budget. Otherwise, it's a simple flowchart and the linear-top-down pattern applies.
|
||||
|
||||
**4b. Draft the layout:**
|
||||
**6d-ii. Draft the layout:**
|
||||
|
||||
1. **List the nodes / regions / shapes** with their full label text (title + optional subtitle).
|
||||
- Simple flowchart: ≤5 nodes.
|
||||
@@ -202,9 +333,11 @@ Write the answers to these in the plan file. If ≥3 of them land, you're buildi
|
||||
5. **Map arrows** and verify none cross an unrelated box. Use L-bends where a straight line would collide. (Sequence messages are always straight horizontal lines — no L-bends. Fan-out candidates converge to a common `ymid` channel just above the judge box.)
|
||||
6. **Compute viewBox height**: `H = max_y + 20` where `max_y` is the bottom of the lowest element. Poster flowcharts routinely reach H=800–950 — don't force them to be compact.
|
||||
|
||||
Save this plan to `diagram/{slug}/plan.md` so iteration runs can re-read it.
|
||||
Save this plan:
|
||||
- **Single mode**: `diagram/{slug}/plan.md`
|
||||
- **Multi mode**: `diagram/{article-slug}/NN-{type}-{slug}/plan.md`
|
||||
|
||||
### Step 5: Write the SVG
|
||||
#### 6e: Write the SVG
|
||||
|
||||
Emit a single `<svg width="100%" viewBox="0 0 680 H">` element. Copy the `<style>` + `<defs>` block from `svg-template.md` **verbatim** — don't abbreviate or edit the color ramp definitions. Then add visual elements in z-order:
|
||||
|
||||
@@ -220,7 +353,7 @@ Typography rules:
|
||||
- Sentence case everywhere — "User login" not "User Login"
|
||||
- Every `<text>` element gets a class (`t`, `ts`, or `th`) — never hardcode fill colors on text
|
||||
|
||||
### Step 6: Run the pre-save checklist
|
||||
#### 6f: Run the pre-save checklist
|
||||
|
||||
Walk through every item in `references/pitfalls.md`. The top failures to catch every time:
|
||||
|
||||
@@ -236,25 +369,25 @@ Walk through every item in `references/pitfalls.md`. The top failures to catch e
|
||||
|
||||
If any item fails, fix the SVG before saving. Don't rationalize past a failure — the checklist exists because these bugs are silent: the SVG is valid but looks wrong when rendered.
|
||||
|
||||
### Step 7: Save output
|
||||
#### 6g: Save and report progress
|
||||
|
||||
If `--out` is given, save the SVG there and skip the scaffolded directory. Otherwise use the default layout:
|
||||
Save the SVG and plan:
|
||||
- **Single mode**: `diagram/{slug}/plan.md` + `diagram.svg`
|
||||
- **Multi mode**: `diagram/{article-slug}/NN-{type}-{slug}/plan.md` + `diagram.svg`
|
||||
|
||||
```
|
||||
diagram/{topic-slug}/
|
||||
├── source-{slug}.md # optional: user's input content if provided
|
||||
├── plan.md # layout sketch from Step 4
|
||||
└── diagram.svg # final output
|
||||
```
|
||||
**Backup rule**: if `diagram.svg` already exists at the target path, rename the existing one to `diagram-backup-YYYYMMDD-HHMMSS.svg` before writing the new file — never overwrite prior work silently.
|
||||
|
||||
- **Slug**: 2–4 kebab-case words derived from the topic.
|
||||
- **Backup rule**: if `diagram.svg` already exists at the target path, rename the existing one to `diagram-backup-YYYYMMDD-HHMMSS.svg` before writing the new file — never overwrite prior work silently.
|
||||
- **Plan**: always save `plan.md` from Step 4 beside the SVG so the next iteration can re-read it.
|
||||
- **Source**: if the user pasted source content, save it as `source-{slug}.md` in the same directory.
|
||||
**Multi mode progress**: after each diagram, report progress: "Generated 2/4: 02-illustrative-jwt-token-structure".
|
||||
|
||||
### Step 7: Finalize (multi-diagram mode)
|
||||
|
||||
If input was a file path, insert `` at each identified position in the article. Compute the relative path based on the article location vs. the diagram output directory.
|
||||
|
||||
If input was pasted content, skip insertion — the diagrams are generated and the outline records positions, but there's no source file to modify.
|
||||
|
||||
### Step 8: Report
|
||||
|
||||
Tell the user in 4-6 lines:
|
||||
**Single mode** — tell the user in 4-6 lines:
|
||||
- Diagram type picked (and one-sentence why)
|
||||
- Node count / complexity
|
||||
- viewBox dimensions
|
||||
@@ -262,10 +395,73 @@ Tell the user in 4-6 lines:
|
||||
- Output file path
|
||||
- One suggestion for how to preview it (e.g., "Open in Chrome for light/dark check")
|
||||
|
||||
**Multi mode**:
|
||||
|
||||
```
|
||||
Article Diagram Generation Complete!
|
||||
|
||||
Article: [path or "pasted content"]
|
||||
Density: [level] | Language: [lang]
|
||||
Diagrams: X/N generated
|
||||
|
||||
Positions:
|
||||
- 01-sequence-jwt-auth-flow → After "Authentication is the first step..."
|
||||
- 02-illustrative-jwt-token-structure → After "The token structure..."
|
||||
- 03-flowchart-token-refresh → After "When the token expires..."
|
||||
- 04-structural-microservice-auth → After "In a microservices architecture..."
|
||||
|
||||
Output: diagram/{article-slug}/
|
||||
Preview: Open any .svg in Chrome for light/dark check
|
||||
```
|
||||
|
||||
## Output structure
|
||||
|
||||
### Single-diagram mode
|
||||
|
||||
```
|
||||
diagram/{topic-slug}/
|
||||
├── source-{slug}.md # optional: user's input content if provided
|
||||
├── plan.md # layout sketch from Step 6d
|
||||
└── diagram.svg # final output
|
||||
```
|
||||
|
||||
### Multi-diagram mode
|
||||
|
||||
```
|
||||
diagram/{article-slug}/
|
||||
├── source-{slug}.md # saved input content (file copy or pasted content)
|
||||
├── outline.md # frontmatter + all diagram entries from Step 4
|
||||
├── 01-{type}-{slug}/
|
||||
│ ├── plan.md # layout sketch for this diagram
|
||||
│ └── diagram.svg # final SVG
|
||||
├── 02-{type}-{slug}/
|
||||
│ ├── plan.md
|
||||
│ └── diagram.svg
|
||||
└── 03-{type}-{slug}/
|
||||
├── plan.md
|
||||
└── diagram.svg
|
||||
```
|
||||
|
||||
- **Slug**: 2–4 kebab-case words derived from the topic or concept.
|
||||
- **Backup rule**: if `diagram.svg` already exists at the target path, rename the existing one to `diagram-backup-YYYYMMDD-HHMMSS.svg` before writing the new file.
|
||||
- **Plan**: always save `plan.md` beside the SVG so the next iteration can re-read it.
|
||||
- **Source**: if the user pasted source content, save it as `source-{slug}.md` in the output directory.
|
||||
- **Numbering**: NN prefix (01, 02, ...) matches the outline order, which matches article position order.
|
||||
- **Outline**: in multi mode, always save `outline.md` from Step 4 so the generation can be resumed or individual diagrams can be regenerated.
|
||||
|
||||
## Modification
|
||||
|
||||
| Action | Steps |
|
||||
|--------|-------|
|
||||
| **Regenerate one diagram** (multi mode) | Re-read `outline.md` → find the entry → re-run Step 6 for that diagram only → update the SVG |
|
||||
| **Add a diagram** (multi mode) | Identify position → add entry to `outline.md` → run Step 6 for the new entry → insert into article |
|
||||
| **Remove a diagram** (multi mode) | Delete the `NN-{type}-{slug}/` directory → remove entry from `outline.md` → remove `![...]` from article |
|
||||
| **Change type** (single or multi) | Update the outline entry or re-run with `--type` → regenerate |
|
||||
|
||||
## Core principles
|
||||
|
||||
- **Draw the mechanism, not a diagram about the mechanism** (illustrative). **Draw the sequence, not the architecture** (flowchart). **Draw the containment, not the flow** (structural). **Draw the conversation, not the steps** (sequence). Picking the wrong type is the single biggest failure mode — more harmful than any layout bug.
|
||||
- **One design system, always.** No `--style` flag, no alternate themes, no per-topic visual variants. The cohesive look across every diagram is the product — if a reader sees two baoyu diagrams in different articles, they should feel they came from the same hand. Any request to "use a different style" is a request to break this principle; push back and ask what the underlying need is instead.
|
||||
- **One design system, always.** No `--style` flag, no alternate themes, no per-topic visual variants. The cohesive look across every diagram is the product — if a reader sees two baoyu diagrams in different articles, they should feel they came from the same hand. Any request to "use a different style" is a request to break this principle; push back and ask what the underlying need is instead. In multi-diagram mode, all diagrams in a run share the same design system — no per-diagram style overrides.
|
||||
- **Self-contained output.** Every SVG carries its own styles and dark-mode rules. The reader should never need to edit anything after pasting it into their article.
|
||||
- **Math before markup.** SVG has no auto-layout. Every coordinate is hand-computed. A diagram that "almost fits" has a bug — fix the math, don't nudge pixels.
|
||||
- **Color encodes meaning, not position.** Five steps in a flowchart are not five colors. All five are gray unless one specific step deserves emphasis — in which case it gets the accent color.
|
||||
|
||||
Reference in New Issue
Block a user