design-tokens

# design-tokens ## Language Rule Follow an explicit artifact or audience language when provided. Otherwise, write rationale, specimen labels, and user-facing reports in the conversation language according to `<agent-home>/roles/response-policy.md`. Preserve canonical token names, values, CSS identifiers, paths, and native tool IDs. ## Resolve and Check State Find `design_state.yaml` under `<artifact-root>/designs/<name>/` or `<artifact-root>/spec/design/`. - Require `phases.refs: done`; do not invent tokens without a brief. - Read `00_init/asset_inventory.md` and locate existing `tokens.css`, `tailwind.config.ts`, `app/globals.css`, or equivalent project-owned token files. ## Single Token Contract The canonical token source is the file the application actually imports: one of `<project_root>/app/globals.css` with `@theme`, `styles/tokens.css`, `tailwind.config.ts`, or the stack-equivalent source. The design workflow owns edits to that file; code workflows consume it. Keep only rationale and visual evidence under `02_tokens/`: `tokens.md` and the specimen. Do not create a second competing token-value source. Set `design_state.tokens_path` to the actual application file. Seed from the codebase before designing. Extract colors, fonts, spacing, radii, and repeated inline hex or pixel values from the real token file and components. Promote the current implementation into an explicit contract, then refine it; do not start from a blank palette when a working system exists. ...