| name | imprint |
| description | Use after building or changing UI — when new components were added and the design system could drift (buttons, spacing, colors, badges diverging across pages). Use when you suspect UI inconsistency has crept in across sessions. |
imprint
Overview
Across sessions, UI silently drifts — slightly different buttons, off spacing, one-off colors. imprint captures new component patterns into a UI registry and reconciles the codebase against it, so the design system stays coherent without you eyeballing every page.
When to use
- After building any new UI component or page.
- When you've built UI across several sessions and want to catch drift.
- Before shipping a UI-heavy feature.
Process
- Capture new patterns. For each new component, record it in the UI registry (e.g.
context/ui-registry.md): its purpose + the exact classes/tokens it uses.
- Match before inventing. If a similar component already exists in the registry, reuse its classes exactly. Build new only when nothing matches — and build it from the UI tokens + UI rules, then add it to the registry.
- Scan for drift. Sweep the codebase for inconsistencies against the registry and tokens: hard-coded hex values, off-scale spacing, duplicate-but-different components, ad-hoc styles.
- Produce a fix list. Report inconsistencies (do not auto-fix): what's off, where, and the registry/token value it should use.
Requires
A ui-tokens file (colors, spacing, radius, type scale as variables) and a ui-rules file (how components look/behave). The registry is the living index imprint maintains on top of them.
Common mistakes
- Hard-coded hex values → always reference tokens. This is the #1 drift source.
- Building a new component when a registry match exists → match first.
- Letting the registry go stale → capture every new pattern as you build it, not "later".
