show-melisted

# show-me Pick the *smallest* view that makes the point, set it beside one or two lines of text, stop. One view per question; two if a second genuinely adds an axis. Never all of them. ## Pick the view | The question is about | Show | |---|---| | an algorithm, branching, an invariant | pseudocode | | runtime order, who calls whom | call tree | | UI structure, state ownership | component tree — JSX plus the hooks and module paths that matter | | where code lives, refactor scope | shallow file tree, one-line responsibility per entry | | interaction across processes or time | Mermaid `sequenceDiagram` / `stateDiagram` | | the shape of an API before writing it | type signatures only, no bodies | | a change to any of the above | that same view, as a `diff` | | a layout, or a comparison too dense for the above | one self-contained HTML file | ## Render target decides the format Terminals do not draw Mermaid — a ```mermaid block in a chat reply is source code the user has to compile in their head. ASCII trees render everywhere. - **Reply in the terminal** → indentation and box-drawing trees, pseudocode, diffs. - **Output lands in a file that renders** — Obsidian note, GitHub PR or issue, markdown doc → Mermaid is worth it. Say where it will render. - **HTML** is the last resort, for layout, spatial comparison, or an interactive explainer. Match the product's colors, type, and spacing; use real labels and real data. Write it outside the project tree (`$TMPDIR`) unless the