55 lines
2.3 KiB
Markdown
55 lines
2.3 KiB
Markdown
---
|
|
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.
|