mermaiddoc

Mermaiddoc Skill

Command: /mermaiddoc

mermaiddoc is a diagram helper, not a repository-documentation workflow.

Use it when a specific document or question is clearer with one focused Mermaid diagram. It may return a Mermaid block for insertion into an existing document, or write/update a file when the user names an output location.

It does not own a default docs/diagrams/ tree and should not create one unless the user explicitly asks for standalone diagram files.

Preferred Diagram Types

Prefer:

flowchart LR
sequenceDiagram

Use flowchart LR for:

• components and dependencies
• request/data/process flow
• module boundaries
• build or deployment flow
• simple decision flow

Use sequenceDiagram for:

• interactions over time
• request/response sequences
• service calls
• retries and important failure paths
• user/system interaction

Use another standard Mermaid diagram only when it is materially better for the requested concept and is likely to render in GitHub.

Do not use Mermaid C4 syntax.

Scope

One diagram should answer one question.

Examples:

• “How does an incoming request reach persistence?”
• “Which modules depend on the domain package?”
• “What happens during token refresh?”
• “How does the worker process a queued job?”

Do not attempt to visualize the entire repository unless the user explicitly requests that scope and the result can remain readable.

Repository Evidence

When the diagram represents repository behavior:

1. inspect only the files needed for the requested diagram
2. prefer current code/config/tests and existing architecture docs
3. use docs/archdoc/ and docs/adr/ as context when present
4. distinguish inferred relationships from verified ones in surrounding prose when it matters
5. do not invent missing components, calls, or rationale to make a diagram look complete

For a purely conceptual diagram supplied by the user, repository inspection is unnecessary.

Diagram Rules

Keep diagrams deliberately small.