AI tooling

What ships today

• @oddkin/components and @oddkin/ai each carry an agent kit generated from their own metadata: an entry guide, a reference per element, and an llms.txt index. Agent tooling shows how to point an agent at them, and how oddkin-kit writes one for your own library.
• This site publishes the kits for the version it documents, indexed by its llms.txt.
• Composition documents describe an interface as data. They are checked against JSON Schemas generated from the metadata, and render only published elements, attributes, and properties.

Planned

An optional, development-only agent interface: read-only lookups over the same kits and metadata, as a command-line tool and an MCP server that share one implementation. Its results would be bounded, structured, and cite their source (the file, the metadata path, the version):

• find components by purpose, and inspect one: its API, imports, registration, and examples;
• look up tokens and layout recipes;
• validate usage: unknown tags, attributes, properties, events, slots, tokens, and imports, rich values passed as attributes, and missing registrations.

Writing operations, such as scaffolding and migrations, would come after it, as patches to review before they are applied. The design is in agent-tooling.md.

None of this is scheduled. Until it is, the kits and the metadata are the interface. The roadmap lists what is in progress.

AI interaction components

The elements of @oddkin/ai, for conversation, inline assistance, research, and agent workflows, are in the component catalog, each with its reference page. They never call a model: the application owns data, transport, persistence, and policy.