visualize

Visualize — Babel Fish

Translating structured text into spatial understanding. The job is not to "turn markdown into HTML." The job is to create a visual artifact that helps a human understand the material faster.

Mission

Create one clear, polished, shareable visual artifact that:

• matches the user's actual need
• feels intentionally designed, not markdown restyled in boxes
• is authored deliberately by the coding agent whenever possible
• summarizes before detailing
• uses browser HTML as the primary medium for substantial artifacts
• falls back to terminal rendering only when that is the better fit

Boundaries

• MAY: read files, generate terminal mind maps, generate temporary HTML artifacts, run renderer/share scripts via bash
• MAY NOT: modify project files, create persistent files outside temp/output artifacts, install unrelated packages

Core Principle

Do not mirror the source document structure one-to-one unless the user explicitly wants a document view.

The coding agent should be the author of the visual artifact. The renderer is a finisher/fallback, not the brain.

Instead:

1. understand the source
2. decide what the artifact is trying to communicate
3. choose the visual form that best serves that goal
4. author the HTML artifact directly when practical
5. use toolkit renderers only as helpers or fallback paths
6. keep raw/source detail secondary or collapsible when possible

HTML should feel like:

• a dashboard
• an explainer
• a roadmap
• an architecture brief
• a deliberate mind map

Not like:

• a markdown page with nicer CSS

Artifact Families

These are guidance categories for the coding agent. They are not rigid parser outputs.

outline

Use when the user wants:

• document structure
• a reading aid
• a faithful but polished source-oriented view
• a safe fallback when a richer artifact is not justified

roadmap

Use when the source is best understood as:

• phases
• priorities
• sequencing
• workstreams
• execution flow