mermaid-sequence-diagramslisted

# Mermaid Sequence Diagrams Generate, review, and fix Mermaid sequence diagrams that are syntactically correct, visually clear, and follow established best practices. This skill is intentionally Mermaid-specific: keep the output in Mermaid `sequenceDiagram` syntax. ## Generating a New Diagram 1. Identify participants. List every system, service, or actor involved. Assign short IDs with descriptive aliases: `participant OMS as Order Management Service`. 2. Use `actor` for human users (renders stick figure), `participant` for services, `database` for data stores, `queue` for message brokers. 3. Determine the flow type: - Synchronous request/response → `->>` / `-->>` arrows. - Async fire-and-forget → `-)` / `--)` arrows. - Failed/rejected → `-x` / `--x` arrows. - Bidirectional (v11+) → `<<->>` / `<<-->>` arrows. 4. Declare all participants explicitly at the top to control left-to-right ordering. Place the initiator on the far left. 5. Write messages one per line. Keep message labels concise (e.g., `POST /orders`, `201 Created`). Move payload details to `Note` blocks. 6. Add `autonumber` when the diagram has 5+ messages. 7. Use `+`/`-` shorthand for activations on arrows (e.g., `->>+Server` to activate, `-->>-Client` to deactivate). 8. Model error paths with `alt`/`else`. Never produce a happy-path-only diagram — always include at least one failure branch. 9. Use control flow blocks as needed — read `references/02-control-flow-and-notes.md` for `alt`, `opt`, `loop