Imprint UI Consistency Registry

UI consistency does not happen by accident. It happens because every component is built with awareness of what already exists.

The problem with AI-built interfaces is that each component gets built in isolation. The agent does not remember what it built three sessions ago. So spacing drifts. Colors vary slightly. Border radius is inconsistent. The app looks like it was built by multiple people with different tastes.

This skill fixes that. Run it after building any UI component. It reads what was just built, extracts the patterns that matter for consistency, and saves them so every future component can match.

One command. Run it every time. That is the whole system.

How to Invoke

After building any UI component, run:

/imprint

To target a specific file:

/imprint [filepath]

To audit an existing codebase for inconsistencies:

/imprint audit

If no filepath is given, the skill identifies recently created or modified component files automatically and captures from those.

When to use audit mode:

• The project UI already exists and consistency is uncertain
• Multiple sessions have passed without running /imprint
• Something looks visually off but it is hard to pinpoint why
• Before establishing ui-registry.md for the first time on an existing project

Run /imprint audit before running /imprint on any project where the UI was not tracked from the beginning.

Step 1 — Find What Was Just Built

If a filepath was provided — read that file directly.

If no filepath was provided — identify which component files were most recently created or modified in this session. Look in the components directory and any other locations where UI files typically live. Read those files.

If it is unclear which files to capture from, ask the developer:

Which component should I capture patterns from?

Step 2 — Extract What Matters for Consistency

Read the component code. Extract only the classes and values that affect visual consistency across the interface. Not everything — only what makes components look like they belong together.

Extract these:

• Background — what bg- class is used for the container, cards, panels
• Border — border color, border width, border style
• Border radius — rounded- class used for this component type
• Text colors — primary text, secondary text, muted text classes
• Text sizes and weights — for headings, body, labels, captions
• Spacing — padding inside the component, gap between elements
• Interactive states — hover, focus, active classes
• Shadow — if used
• Any accent or brand color usage

Do not extract these:

• Width and height — too context-dependent to be a consistency rule
• Flex and grid layout — structural, not visual
• Positioning — absolute, relative, z-index — context-dependent
• Animation and transition timing — unless it is a pattern worth enforcing
• Responsive breakpoint variants — capture the base pattern only

Step 3 — Write to ui-registry.md

Open ui-registry.md. If it does not exist, create it.

Add a new entry for the component that was captured. Do not overwrite existing entries — append to the registry.

If an entry for this component type already exists — update it rather than duplicating.

Entry format

### [Component Name]

File: [filepath]
Last updated: [date]

| Property         | Class           |
| ---------------- | --------------- |
| Background       | [class]         |
| Border           | [class]         |
| Border radius    | [class]         |
| Text — primary   | [class]         |
| Text — secondary | [class]         |
| Spacing          | [class]         |
| Hover state      | [class]         |
| Shadow           | [class or none] |
| Accent usage     | [class or none] |

**Pattern notes:**
[Any important pattern decisions worth noting —
why a specific class was chosen, what this component
should always match, what variations are allowed]

Step 4 — Confirm What Was Captured

After writing to ui-registry.md, confirm to the developer:

Imprinted [Component Name] → ui-registry.md

Captured:
- Background: [class]
- Border: [class]
- Radius: [class]
- Text: [classes]
- Spacing: [classes]
- Hover: [class]

Any future component of this type should match these patterns.

If anything looked inconsistent or surprising during extraction — flag it:

Note: [Something that looked inconsistent or worth the
developer knowing about]