creating-illustrations
Use when a structure, flow, sequence, state machine, dependency graph, or comparison would be clearer as a diagram than as prose. Produces accurate, readable, text-based diagrams.
- License 许可
- Apache-2.0
- 最近更新
- 2026-11-09
- Stars
- ★ 11
- Forks
- 0
01 前言 Front Matter
- name
- creating-illustrations
- description
- Use when a structure, flow, sequence, state machine, dependency graph, or comparison would be clearer as a diagram than as prose. Produces accurate, readable, text-based diagrams.
03 SKILL.md 正文
Creating Illustrations
Purpose
Show the shape of a system, change, or decision when words alone make the reader rebuild it in their head.
When To Draw
Draw when the reader needs to see relationships: call flows, data flow, module boundaries, state transitions, dependency order, timelines, or before/after structure. Do not draw a diagram that only repeats a short list.
Choose The Form
| Content | Form |
|---|---|
| Steps over time between actors | Mermaid sequenceDiagram |
| Components and their dependencies | Mermaid flowchart |
| States and transitions | Mermaid stateDiagram-v2 |
| Data entities and relations | Mermaid erDiagram |
| Ordered work with dependencies | Mermaid flowchart or gantt |
| Options compared on several dimensions | Markdown table |
| Custom layout Mermaid cannot express | Hand-written SVG |
Prefer Mermaid in Markdown. It is text, renders on GitHub, and is reviewable in a diff. Use SVG only when Mermaid cannot express the layout. Do not use ASCII art for anything with more than a few boxes.
Accuracy
- Draw only what you verified. Every box and arrow must map to a real file, module, function, service, or decision. Use the names from the code.
- Label arrows with what flows or why: a call name, a message, an event.
- If part of the diagram is a proposal or a guess, mark it, for example with a
dashed edge or a
(proposed)label, and say so in the text. - Put the source paths for the main nodes in the text below the diagram.
Readability
- Keep to about 12 nodes. Split a larger picture into an overview plus one diagram per area.
- Use one direction of flow, such as top to bottom or left to right.
- Group related nodes with
subgraphinstead of adding colour. - Do not rely on colour alone to carry meaning. Use labels or line styles too.
- Keep labels short. Put detail in the text below.
- In SVG, include a
<title>and<desc>, use readable font sizes, keep contrast high, and do not load external fonts, images, or scripts.
Output
- One sentence that says what the diagram shows.
- The diagram.
- A short key or notes: source paths, anything proposed or uncertain, and anything left out on purpose.
04 同仓库更多 Skills
verification-before-completion
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
using-beryl
暂无简介
understand-codebase
Teach a developer how a repository, subsystem, execution path, migration, diff, commit, branch, or pull request works. Use when the user asks to understand, explain, map, walk through, explore, or quiz themselves on code, or asks for an interactive HTML understanding artifact.
test-driven-development
Use when implementing any feature or bugfix, before writing implementation code
systematic-debugging
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
simplifying-code
Use when code in a specific module or area is hard to understand or change, when the user asks to simplify, refactor, clean up, or improve the design or architecture of some code, or when a maintenance program hands over a refactor slice. Finds unmanaged complexity from evidence and removes it with small, behavior-preserving changes.