Build with the toolkit

Start with the quick reference, then the exact reference of every component, class or token you use. Read the nearest AGENTS.md and the existing source before editing. Component source owns behavior, CSS owns values and Markdown owns the public explanation; when they disagree, reconcile them instead of inventing an API.

The DS publishes generated views of the same sources: /llms.txt lists every page, /ai-context.md assembles the quick reference and the build guides, /component-manifest.json gives exact props and /tokens.json gives token roles and values. Each page's Markdown path, such as /components/button.md, returns the original file. A deployed version can differ from a local checkout; check version before mixing evidence.

Start a new app from the boilerplate. Follow the quick reference shell and rules, adapt the collection or form recipe where it fits, and implement the applicable states of the state contract with recovery paths. Check long labels and content, not only demo data.

Proceed with routine, reversible decisions within the request. Ask before changing a public API, the shared visual language, accessibility behavior or compatibility, and before publishing anything. Present rendered comparisons for significant visual decisions; passing checks is not human approval.

Run the workspace checks, which type-check application code and reject unknown props, and the app build, then follow accessibility verification. Explain what changed, why, what was verified and what was not. A change to @dg/ui itself follows the maintenance process and starts with pnpm check:toolkit.

Measuring whether a fresh agent can build from these sources uses the independent evaluation protocol; running it requires the user's authorization.