Index.how: A Shared Design Vocabulary for Your AI Coding Agents

What Index.how Actually Is

Index.how is a design vocabulary you can install into your AI coding agent. The pitch is blunt: "Say precisely what you mean." You run `npx skills add index-how/vocabulary` and it adds a reference of design terms your agent can draw on. It's documented to support Claude Code, Codex, Cursor, and others.

The content itself is a structured glossary of the words designers use when they know what they're looking at. Typography covers things like kerning versus tracking, leading, optical kerning, tabular numerals, type scales, x-height, clamp-based fluid sizing, widows and orphans. Color covers sRGB, P3, OKLCH, semantic tokens, contrast ratios, tinted neutrals, chroma versus opacity, and dark-mode layering. Each entry is short and opinionated, with the kind of caveat a working designer would add ("reducing chroma keeps the color alive; reducing opacity turns it grey and lifeless").

This isn't a code library or a component kit. It's vocabulary. The bet is that an agent armed with precise terms produces better, more consistent design output than one guessing from vague instructions.

Why Shared Vocabulary Matters for Automation

The context that surfaced this is a workflow for making animated diagrams with Claude Code and Remotion. The author's process isn't a single magic prompt. It's a pipeline: find an input language the model already knows well (Mermaid for flowcharts), build components that bake in guardrails like layout rules and animation patterns, then describe what you want in plain English and let the agent translate it into that input language. The component handles the rest.

The key observation is this line: "It really helps to have a shared vocabulary with your agent." When they say "rise in fast on enter," the agent knows that means fade in while translating up, from a set offset, faster than the default, with a specific easing curve. That phrase is doing the work of a paragraph of instructions, and it does it the same way every time.

That's the practical case for something like Index.how. If you're automating any kind of generated output—UI, diagrams, documents, slides—the failure mode isn't usually the model's raw ability. It's drift. Ask for spacing five times and you get five interpretations. A defined vocabulary collapses that ambiguity. "Tighten the tracking on the uppercase label" is a precise instruction with one correct meaning; "make the heading look better" is not. Whether you're prompting interactively or wiring an agent step into a flow built on n8n or Make, repeatable language is what makes the output predictable enough to trust.

Where It Fits and What to Watch

Think of Index.how as the layer below a design system, not a replacement for one. A design system gives the agent components and tokens to use. A vocabulary gives it the language to reason about why one choice beats another—why a tinted neutral reads as deliberate where pure grey reads as a placeholder, or why OKLCH avoids the muddy midpoint that sRGB gradients fall into. The two complement each other. In the Remotion example, the vocabulary is what lets plain-English requests map cleanly onto the guardrailed components.

A few honest caveats. First, this is reference material, not enforcement. Installing the skill makes the words available; it doesn't guarantee the agent applies them correctly or that your output passes a contrast check. You still review. Second, the value scales with how much design work you actually push through an agent. If you generate the occasional one-off, a glossary skill is overhead. If you run a repeatable pipeline producing UI, diagrams, or branded assets, a stable shared language pays back quickly. Third, vocabulary is general; your house style is specific. You'll likely want to layer your own conventions—your version of "rise in fast on enter"—on top, the same way the diagram workflow defined its own animation shorthand.

It's worth noting the broader pattern here, because Index.how is one instance of it. The author also points to community efforts in the same spirit, like work shared by Matt Pocock and by Emil Kowalski. The common thread is teaching agents the precise terms of a domain so plain-English requests resolve to one outcome instead of many. Design is a natural first target because the vocabulary is already rich and well-defined—designers spent decades arguing about what kerning means so you don't have to.

The takeaway for builders is small but useful: before you reach for more elaborate prompting or fine-tuning, check whether you and your agent even share the words. A skill like Index.how is a cheap way to find out, and `npx skills add index-how/vocabulary` is a low-commitment test. If your generated output gets more consistent, you've learned where the real bottleneck was.

If you want help wiring shared-vocabulary agents into a working automation pipeline, browse the provider directory to find someone who can put it to work.