← Corpus / dididecks-ai / spec

Dididecks-AI: Visual and Diagram Component Library

DD-grade decks lean on a wide universe of recurring visual primitives — concept diagrams, mental models, classification schemes, frameworks. A reusable, AI-composable library of these primitives is what lets each new deck reach 'wow' without re-drawing from scratch.

Path
specs/Dididecks-AI-Visual-and-Diagram-Component-Library.md
Authors
Michael Staton
Augmented with
Claude Code (Opus 4.7)
Tags
Visual-Library · Diagrams · Mental-Models · Frameworks · Infographics · Dididecks · Component-Library

Dididecks-AI: Visual and Diagram Component Library

Stub — 2026-05-11. Sibling spec to [[Dididecks-AI-Slide-Decks-as-Code]]. Forked out preemptively per the anxiety-trigger principle in the context-vigilance skill: the visual-component universe is large enough to deserve its own design space rather than bloating the parent spec.

The Question This Spec Will Answer

What set of reusable, AI-composable visual primitives does Dididecks-AI need so that every new deck can reach DD-grade conceptual clarity without redrawing the same diagrams from scratch — and what’s the architecture for letting Claude compose these primitives intelligently from a narrative description?

The North Star

A managing partner says to the embedded chat: “Show this as a 2x2 with traction on the x-axis and conviction on the y-axis, our four target companies plotted, with the two we already passed on shown in muted grey.” — and within seconds, that slide exists, in the firm’s brand, with the right components composed. That is the bar. No drag-and-drop. No fiddling with shape coordinates. Conversation in, composed-visual out, every time, reliably.

Why this is its own spec (and not a section in the parent)

The parent spec, [[Dididecks-AI-Slide-Decks-as-Code]], names a “universe of diagrams / visuals / mental models” as Input #3 of the design rationale. But the visual-library design space — primitive taxonomy, composition grammar, brand-aware theming, AI-composition prompting — is large enough that putting it inline would bloat the parent past the comfortable-reading threshold. Forked out preemptively. See ~/.claude/skills/context-vigilance/references/philosophy.md“On capability ≠ wisdom-to-use-it” for the rationale.

What this spec covers (placeholder section list — to be developed)

Headers only. Each will be filled through discussion.

The Primitive Taxonomy

Composition Grammar

Brand-Aware Theming

AI Composition Prompting

Authoring vs. Library Storage

Export Fidelity

Cross-Deck Reuse

Prior Art

  • astro-knots/context-v/sitemap/components/Component__Message-Hierachy-Bare-Component — a primitive already in our component sitemap; canonical example of the kind of thing this library catalogues.
  • astro-knots/context-v/sitemap/components/Component__Rapid-Slide-Search-&-Nav — adjacent; navigation rather than visualization, but the sitemap pattern itself is the model for cataloguing.
  • astro-knots/context-v/strategy/Exploring-Publishing-Component-Library-for-VC-Firms — closest existing strategic thinking; directly upstream.
  • dididecks-ai/client-sites/calmstorm-decks/src/ — the most recent live implementation of slide-as-component patterns; the candidates for “promotion to library” are in there.
  • frontend-design agent skill — for the design-quality discipline. Each primitive must hit the “distinctive, production-grade” bar; generic AI aesthetics fail DD.
  • maintain-design-md skill — every primitive references locked design tokens, never invents values.

Open Questions

  1. Library substrate — Astro components? Vanilla SVG with a JSON schema? A new format? Probably Astro components inside a shared package (next step beyond @knots/* workspace-local pattern packages).
  2. Versioning — primitives evolve. A deck published in May 2026 should still render correctly in May 2028. How do we version primitives without breaking deployed decks?
  3. Discoverability — how does a user (or Claude on their behalf) browse the library? A /design-system page like astro-knots sites already maintain? An MCP-accessible registry?
  4. Long-tail customization — when a client wants a primitive that isn’t in the library, what’s the workflow? Per-deck custom component → promotion to library if recurring? Or per-firm extension namespace?
  5. AI composition reliability — how do we make the “say a description, get the right primitive” path boringly reliable rather than impressively wonky? Test corpus of natural-language → expected-primitive mappings, evaluated continuously.
  6. Skill packaging — does this whole library ship as one agent-skill (dididecks-visual-library), several composable skills (one per primitive family), or as MCP-served tools?
  • [[Dididecks-AI-Slide-Decks-as-Code]] — parent spec.
  • [[Dididecks-AI-DD-Ready-Citation-and-Source-Access]] — adjacent sibling spec. Charts and KPI primitives straddle both — citation-grounded quantitative components live in the citation spec; concept/mental-model diagrams live here.
  • [[../explorations/Dididecks-AI-Business-Model]] — relevant because a curated library is part of the hosted-tier value-add.
  • frontend-design agent skill.
  • maintain-design-md skill.
  • theme-system skill.
  • astro-knots skill.
  • context-vigilance skill — for the fork-and-cross-reference discipline this spec exists to honor.