design-system-synclisted

## What It Does When a token, component, or breakpoint is added to source (Tailwind theme entry, design-token export, new component file), this skill updates the matching contract clause in `docs/instructions/design-system/*` so the contract stays in step with reality. Mirror of `canonical-doc-sync`, scoped to the design system. ## Use This When Use this from the `documentation_sync` stage of `feature-development.yaml` whenever the diff touches: - `src/design-tokens/**` - `tailwind.config.*` - `src/components/**` (added/removed components) - A CSS-in-JS theme provider definition Also runs during `design-test` Step 5 when a finding's resolution implies the contract should expand (e.g. a `documentation-drift` finding noting a token used in code but not declared). ## Inputs - Read the diff (`git diff --name-only HEAD`). - Read the current `docs/instructions/design-system/*.md` files. - Read `references/sync-rules.md`. ## Procedure Proposal generation is deterministic — the scripts produce unified-diff hunks ready for the Decision Pause Contract. The LLM never hand-writes the diff. 1. Capture the current diff: `git diff HEAD > /tmp/sync.diff` (or read from the workflow's staged diff). 2. Run `scripts/detect-token-additions.sh /tmp/sync.diff` → `<key>\t<value>` rows for every added token-shaped entry (accepts identifier and quoted-numeric keys; only token-shaped values: hex/px/rem/em). 3. Pipe those rows into `scripts/propose-tokens-diff.sh` → a unified-diff hunk targeti