菜单
Generate mermaid diagrams — flowcharts for architecture, sequence diagrams for interactions. This skill SHOULD be used when the user asks to "create a diagram", "draw an architecture diagram", "sequence diagram", "flowchart", "visualize the system", or "generate mermaid".
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | sc-mermaid |
| description | Generate mermaid diagrams — flowcharts for architecture, sequence diagrams for interactions. This skill SHOULD be used when the user asks to "create a diagram", "draw an architecture diagram", "sequence diagram", "flowchart", "visualize the system", or "generate mermaid". |
| argument-hint | [flowchart | sequence] <system or flow description> |
Generate mermaid diagrams for architecture visualization and interaction flows.
Input: $ARGUMENTS
Parse $ARGUMENTS to determine diagram type:
| Signal | Mode |
|---|---|
flowchart, architecture, system, component relationships | Flowchart |
sequence, flow, interaction, request/response patterns | Sequence |
| Ambiguous | Ask the user or infer from context |
[Rectangle] — services, applications[(Database)] — data stores (PostgreSQL, Redis, OpenSearch)((Circle)) — external services, APIs[[Subroutine]] — modules, workers, background jobs{Rhombus} — decision points, routing logic{{Hexagon}} — gateways, proxies, middleware{descriptive-name}.mmd)mmdc -i <file>.mmd --parseOnly (fix errors if any)mmdc -i <file>.mmd -o preview.png)Generate diagrams compatible with mermaid-ascii for terminal rendering.
Works:
sequenceDiagram # REQUIRED first line
participant A as Alice # aliases (optional)
"Quoted Name" # spaces in names
A->>B: message # solid arrow (colon REQUIRED)
A-->>B: message # dotted arrow (colon REQUIRED)
A->>A: self # self-message (use for notes)
%% comment # ignored by parser
Fails:
A->B: msg # wrong arrow (needs ->>)
A-->B: msg # wrong arrow (needs -->>)
A->>B # missing colon
Note over A # not implemented
loop/alt/opt # not implemented
activate A # not implemented
A->>B: text works, A->>B failsA->>A: (thinking) instead of Note%% Phase 1: or %% alt: if X then Ycat <file> | mermaid-ascii -f -%% Flow: [title]
%% Render: cat <file> | mermaid-ascii -f -
sequenceDiagram
participant A as ActorOne
participant B as ActorTwo
%% Phase 1: [description]
A->>B: request
B-->>A: response
%% Flow: API authentication
%% Render: cat api-auth.mmd | mermaid-ascii -f -
sequenceDiagram
participant C as Client
participant G as Gateway
participant A as Auth
participant S as Service
C->>G: POST /api/data
G->>A: validate token
A-->>G: valid
G->>S: forward request
S-->>G: response
G-->>C: 200 OK
%% alt: invalid token
%% A-->>G: 401
%% G-->>C: 401 Unauthorized
Before saving, ALWAYS test with:
cat <<'EOF' | mermaid-ascii -f -
[your diagram here]
EOF
If it errors, fix the syntax. Common fixes:
A->>B -> A->>B:A->B: -> A->>B:Write diagram to {descriptive-name}.mmd in the current directory (or ask user for location).
Include in the file:
$ARGUMENTS
Use when writing or editing a Slack message, email, pull request body, GitHub issue, Reddit post, agenda, or doc. Enforces a direct, warm, unfilled tone and removes AI tells. Always scores the final draft and runs a self-audit pass before delivery.
Reframe code design through functional programming principles for agent-assisted development. This skill SHOULD be used when the user says "think functional", "think FP", "make this pure", "separate effects", "where should this side effect go", "this function does too much", "how should I structure this for agents", "make this easier to review", "reduce context needed", or when planning module structure, store design, or code that agents will write and humans will review. Applies FP discipline within any language to maximize agent effectiveness and human reviewability.
Use when designing AI features and the real opportunity may be perception support, not delegated conversational work.
Lift-and-shift port of a repository, library, API, protocol, or other software artifact to a different language, runtime, or platform, with the original source available as a reference. This skill SHOULD be used when the user says "port from X to Y", "lift and shift", "rewrite in Go", "rewrite in Rust", "translate this codebase", "convert to TypeScript", "language migration", "rewrite in another language", "carry over the algorithms", "borrow techniques from", "dirty room", "dirty-room design", "sc-dirty-room", or wants to reimplement an existing artifact while studying its internals to preserve algorithms, data structures, or idioms worth keeping. NOT for legally-constrained reimplementation — use /sc-clean-room when copyright isolation matters.
Audit and improve project memory files (CLAUDE.md, AGENTS.md, .claude.local.md) — assess against a quality rubric, then apply additions and removals. This skill SHOULD be used when the user asks to audit, improve, edit, fix, tighten, rewrite, or update a memory file, or to check whether one is too long, stale, or bloated.
Clean-room reimplementation of a repository, library, API, protocol, or other software artifact. This skill SHOULD be used when the user wants to create a functionally equivalent implementation of an existing artifact without copying its internal design or expression. NOT for refactoring existing code.