AI-first by design

Slipstream treats an AI coding agent as a first-class consumer. Instead of hoping a model infers the API from source, every component publishes a contract and a validator checks the generated JSX before it ships. 109 components (92 core, 17 AI) ship that contract today.

The problem

Agents trained on the open web guess at component APIs. The result is usually the same three failures: a prop that does not exist, an enum value that was never in the type, or a required prop that never appears. Documentation written for humans does not close that gap, because the model never sees it at the moment it writes the code.

The contract

Each component directory ships a manifest beside its source. The manifest is small enough to load into a prompt and explicit enough to validate against:

{
  "id": "stepper",
  "name": "Stepper",
  "tier": "molecule",
  "description": "Multi-step flow indicator...",
  "props": [
    { "name": "current", "type": "number", "required": true },
    { "name": "orientation", "type": "'horizontal' | 'vertical'",
      "defaultValue": "horizontal", "enum": ["horizontal", "vertical"] },
    { "name": "variant", "type": "'numbered' | 'dots'",
      "defaultValue": "numbered", "enum": ["numbered", "dots"] }
  ],
  "examples": [{ "title": "Onboarding wizard", "code": "<Stepper ... />" }],
  "antiPatterns": [{ "title": "Don't use it for progress percentage", ... }],
  "accessibility": [{ "feature": "Sequence + state", ... }],
  "compositionRules": [{ "component": "Form", ... }],
  "relatedComponents": ["Progress", "Tabs", "Form"]
}

The manifest is not a copy of the TypeScript types. It adds intent, anti-patterns, and accessibility requirements that types cannot express. A drift checker compares the two on every run, so the contract cannot silently fall behind the code.

The loop

1. search_components("multi-step form")
     -> Stepper, Progress, Tabs

2. get_component_manifest("stepper")
     -> exact props, defaults, required flags, examples

3. the agent writes JSX
     <Stepper current={step} orientation="vertical" steps={steps} />

4. validate_usage({
     componentId: "stepper",
     code: "<Stepper current={step} orientation='vertical' steps={steps} />"
   })
     -> { valid: true, issues: [] }

5. emit only after validation passes

The validator reports unknown props, values outside a documented enum, and missing required props. It also returns the manifest's anti-patterns so the agent can re-check intent, not only syntax.

Four surfaces, one source

Pick your entry point

What stays in sync

• TypeScript ↔ manifest: prop names, optionality, and enums are compared; drift fails CI.
• Manifest ↔ registry: the registry is generated from manifests, so a published component cannot omit its contract.
• Manifest ↔ markdown: the LLM index and per-component pages are generated, and a check gate fails when they are stale.
• Manifest ↔ MCP: the server loads the installed manifests at startup, not a cached snapshot.

pnpm validate:manifests   # schema + TS drift + versions + counts
pnpm generate:registry    # /registry/*.json
pnpm generate:llm-docs    # /llm/*.md, llms.txt, llms-full.txt
pnpm check:llm            # fail if generated docs are stale

What the validator does not do

validate_usage is a contract check, not a compiler or a design review. It does not type-check expressions, run your app, or judge visual composition. Keep your normal tsc, tests, and axe runs in the loop; the validator catches the class of mistakes that type-checking never sees because the generated code imports the real types only after it is emitted.

Next