---
name: sequence-diagram
description: 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.

```mermaid
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.