feat: new plugin — on-demand visualization router (/visualize)

[kyle-sexton]

Problem

There is no on-demand way to ask Claude Code to render the right visual for wherever the
conversation currently is. Today a user has to specify both the form (mermaid diagram, table,
chart, ASCII, HTML page) and the medium (inline terminal vs a published Artifact) by hand. The
recurring real-world ask is simply: "visualize this" — and let the assistant infer the target,
pick a fitting form, and pick the right medium.

The craft of a good chart or a good artifact is already owned elsewhere (a chart-craft/dataviz
capability; an artifact-design capability; the Artifact tool's own contract). What is missing is the
router that sits in front of them: infer the target, choose form + medium, and only ask the
human when genuinely ambiguous.

Proposed shape

A new single-skill plugin (precedent: naming, bug-report, context7) whose one skill is a
form + medium router:

• Infers what to visualize from the current conversation position.
• Picks the form (mermaid diagram family, markdown table, inline-SVG/HTML chart, ASCII/Unicode,
  dashboard, ...) via a decision matrix over content type x complexity.
• Picks the medium (terminal vs Artifact) via the same matrix plus a user-configurable default.
• Asks the user only when the target/form is ambiguous and no form was specified; otherwise good
  defaults.
• Exposes a userConfig scalar for the preferred medium (auto / terminal / artifact).
• Cites the craft capabilities generically and presence-gated (seam-phrasing convention) — never
  duplicates or hard-couples to them. When a chart-craft or artifact-design capability is installed,
  route to it for the craft; otherwise fall back to the built-in native rendering surfaces.

Config posture: preferred medium is user-configurable via the plugin's native config surface, not
hardcoded.

Mandated research phase (must precede design)

Ground the decision matrix in verified current facts, official docs first:

1. Built-in Claude Code rendering surfaces (terminal GFM markdown/tables/code; artifact native
   mermaid; image display) — verified against official docs.
2. Zero-external-dependency visualization forms (mermaid diagram families; artifact HTML/SVG/CSS
   under the no-external-hosts CSP; ASCII/Unicode terminal graphics; markdown tables).
3. In-fleet + harness craft capabilities (a dataviz/chart-craft capability, an artifact-design
   capability, the Artifact tool contract) — cite, do not copy.
4. Third-party visualization plugin options, if any credible ones exist — trust-assessed; prefer
   recommending none over an unvetted dependency.

Research findings + decision-matrix derivation recorded in the PR body.

Acceptance criteria

• Single-skill plugin under plugins/<name>/, conforming to docs/PLUGIN-PHILOSOPHY.md and the
  per-plugin migration gate.
• Skill is a router: infers target, picks form + medium, asks only on genuine ambiguity.
• userConfig preferred-medium scalar with a zero-config default.
• Craft citations are capability-generic and presence-gated per the seam-phrasing convention; no
  duplication of upstream craft content.
• Marketplace entry + generated catalog + README updated; claude plugin validate --strict passes;
  skill-quality gate + markdownlint pass.
• Skill/plugin name decided via a blind naming pass with a human final call before merge.

Notes

Skill and plugin name are provisional until the naming pass completes; the human makes the final
call before merge.