Wardn HubTrusted MCP server directory.

Registry

  • MCP Servers
  • Skills
  • Categories

Resources

  • API docs
  • Score method

Contribute

  • Submit server
  • Advertise
© 2026 Wardn Hub
Wardn Hub
MCP ServersSkillsCategoriesAPI docsSubmit server
Submit server
skills/mohitagw15856/pm-claude-skills/sequence-diagram

sequence-diagram

1
mohitagw15856/pm-claude-skills·Audit passed·Snapshot a38f8f402603

Summary

This source did not publish a separate summary. Review SKILL.md before using the skill.

SKILL.md

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. Declare participant X as Label (or actor) up front.
  • Solid arrow ->> = call/request; dashed -->> = response/return; -) = async message.
  • Use Note over A,B: ... for context and alt/else/end for 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.

    Related skills

    capacity-planningcompetitor-teardowncontext-engineering-reviewrunbook-writerreceipts-audit