sequence-diagram
GitHub将API流程、认证握手或集成交互转化为Mermaid序列图。明确参与者、同步/异步消息及错误路径,确保图表可渲染并附带边缘情况说明。
触发场景
安装
npx skills add mohitagw15856/pm-claude-skills --skill sequence-diagram -g -y
SKILL.md
Frontmatter
{
"name": "sequence-diagram",
"description": "Diagram an interaction as a sequence of messages between participants over time. Use when asked to show an API flow, request\/response, auth handshake, integration, or 'what calls what in what order'. Produces a ready-to-render Mermaid sequence diagram (renders live, exportable as PNG\/SVG) plus notes on edge cases and failure paths."
}
Sequence Diagram Skill
When the question is "in what order do these things talk to each other?", a sequence diagram is the clearest answer. This skill turns a described interaction — an API call chain, an auth handshake, a webhook flow — into a correct Mermaid sequence diagram with participants, ordered messages, return values, and the important error/timeout paths.
Required Inputs
Ask for these only if they aren't already provided:
- The participants — the actors/services/systems involved (client, API, DB, third party…).
- The messages — what each one sends to the next, in order; what comes back.
- Sync vs async — which calls block on a response vs fire-and-forget.
- Edge cases — the failure, timeout, or alternative path worth showing.
Output Format
[Interaction name] — sequence
One line on what flow this traces.
sequenceDiagram
actor U as User
participant W as Web app
participant A as API
participant D as Database
U->>W: Click "Sign in"
W->>A: POST /login
A->>D: Lookup user
D-->>A: User record
A-->>W: 200 + token
W-->>U: Logged in
Note over A,D: On miss, return 401
Notes — failure/timeout handling, retries, idempotency, anything async (-) ).
Mermaid Rules (so it renders)
- Start with
sequenceDiagram. Declareparticipant X as Label(oractor) up front. - Solid arrow
->>= call/request; dashed-->>= response/return;-)= async message. - Use
Note over A,B: ...for context andalt/else/endfor alternative paths if needed. - Keep message text short; no colons that aren't the message separator.
Quality Checks
- Participants are declared and ordered to match the real call flow
- Requests and responses are distinguished (solid vs dashed arrows)
- At least one failure/edge path is shown or noted (not just the happy path)
- Sync vs async messages are visually distinct
- The Mermaid block renders without edits
Anti-Patterns
- Do not show only the happy path when a failure path matters — note the 401/timeout/retry
- Do not blur requests and returns — use
->>vs-->> - Do not reorder messages for neatness — sequence order is the whole point
- Do not put colons inside message text — it breaks parsing
- Do not invent participants — model only the systems actually involved
Based On
UML sequence diagramming (lifelines, sync/async messages, alt fragments), expressed as renderable Mermaid.
版本历史
- a38bc30 当前 2026-07-05 11:28


