firehose/sequence-diagram-skill/skill/SKILL.md

name, description

name	description
sequence-diagram	Generate a Mermaid sequence diagram showing message flow across module boundaries for an Elixir/Phoenix interaction. Use when asked to diagram, trace, or visualize a user interaction, request flow, or feature path through the codebase.

Sequence Diagram Skill

Generate a Mermaid sequenceDiagram that traces a specific user interaction across module boundaries in an Elixir/Phoenix codebase.

Your Task

Given a description of an interaction (e.g., "user clicks a tag on a blog post") and access to the source files, produce a Mermaid sequence diagram that accurately shows the message flow between modules.

Process

1. Identify the entry point. What triggers this interaction? (HTTP request, LiveView event, PubSub message, etc.)
2. Read the router to find which controller/live module handles the route.
3. Read the controller/live module to find which functions are called and which domain modules they delegate to.
4. Read the domain modules to understand what they return and how.
5. Read templates/components if the rendering path matters.
6. Emit the diagram. Use sequenceDiagram with participants named after actual modules. Show function calls as messages.

Output Format

Respond with ONLY a fenced Mermaid code block. No preamble, no explanation, no code review, no suggestions. Just the diagram.

sequenceDiagram
    participant Browser
    participant Router as FirehoseWeb.Router
    ...

Rules

• Participants must be real modules from the codebase. Never invent modules.
• Messages must be real function calls or HTTP verbs. Use the actual function names you found in the source (e.g., blog.posts_by_tag(tag), not "get posts").
• Show the return path. Responses flow back: module returns data, controller renders, browser receives HTML.
• Distinguish compile-time from runtime. If a module uses NimblePublisher or module attributes, the data is compiled into the BEAM — there is no runtime file I/O. Show this as a note, not as a message to the filesystem.
• Stay on task. Do NOT review the code. Do NOT suggest improvements. Do NOT mention potential issues. Your only job is the diagram.
• Keep it readable. Use Note over for context. Use short aliases for long module names in the participant declaration.