← 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-vigilanceskill: 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-designagent skill — for the design-quality discipline. Each primitive must hit the “distinctive, production-grade” bar; generic AI aesthetics fail DD.maintain-design-mdskill — every primitive references locked design tokens, never invents values.
Open Questions
- 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). - 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?
- Discoverability — how does a user (or Claude on their behalf) browse the library? A
/design-systempage like astro-knots sites already maintain? An MCP-accessible registry? - 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?
- 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.
- 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?
Related
- [[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-designagent skill.maintain-design-mdskill.theme-systemskill.astro-knotsskill.context-vigilanceskill — for the fork-and-cross-reference discipline this spec exists to honor.