Imprint

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 — Detect the Styling Approach

Before extracting patterns, identify how this project handles styles. The approach determines what you capture.

• Utility classes (Tailwind, UnoCSS) — capture class names (e.g., bg-gray-900, rounded-xl)
• CSS custom properties / design tokens — capture variable names (e.g., var(--color-surface), var(--radius-md))
• CSS / SCSS / CSS Modules — capture the values and the selectors/variables that define them (e.g., $color-primary: #1a1a2e, .card { border-radius: 8px })
• CSS-in-JS / styled-components — capture theme tokens and style object patterns
• Mixed — capture whatever the project uses. Note the mix.

This step happens once per project. If ui-registry.md already has a Styling approach header, use that.

Step 2 — 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 3 — Extract What Matters for Consistency

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

Extract these:

• Background — what value, variable, or class is used for the container, cards, panels
• Border — border color, width, style — as values, tokens, or classes
• Border radius — the radius value, variable, or class used for this component type
• Text colors — primary text, secondary text, muted text — as values, tokens, or classes
• Text sizes and weights — for headings, body, labels, captions
• Spacing — padding inside the component, gap between elements
• Interactive states — hover, focus, active styles — how they are implemented
• Shadow — if used, capture the value or token
• Accent or brand color usage — how accent colors are applied
• Accessibility patterns — focus ring style, aria patterns, keyboard interaction if applicable
• Theme-aware values — if the project supports dark/light mode, note which properties change between themes and which stay constant

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 4 — Capture Composition Patterns

Beyond visual properties, capture how this component type is internally structured. Consistent structure matters as much as consistent visuals.

• What sections does this component always have? (e.g., header → content → footer)
• What is the consistent ordering of elements?
• Are there required vs optional sections?
• How does this component type handle empty states?

This tells the agent not just "what does it look like" but "how is it put together."

Step 5 — Write to ui-registry.md

Open ui-registry.md in the project root. If it does not exist, create it with a header noting the styling approach:

# UI Registry

Styling approach: [utility classes / CSS variables / SCSS / CSS-in-JS / mixed]
Last updated: [date]

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         | Value / Token                   |
| ---------------- | ------------------------------- |
| Background       | [value, variable, or class]     |
| Border           | [value, variable, or class]     |
| Border radius    | [value, variable, or class]     |
| Text — primary   | [value, variable, or class]     |
| Text — secondary | [value, variable, or class]     |
| Spacing          | [value, variable, or class]     |
| Hover state      | [value, variable, or class]     |
| Focus ring       | [value, variable, or class]     |
| Shadow           | [value or none]                 |
| Accent usage     | [value or none]                 |
| Theme-aware      | [yes/no — what changes]         |

**Composition pattern:**
[How this component type is internally structured —
what sections it always has and in what order.
e.g., "Header (icon + title) → Body (content) → Footer (actions, right-aligned)"]

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

Step 6 — Confirm What Was Captured

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

Imprinted [Component Name] → ui-registry.md

Captured:
- Styling approach: [approach]
- Background: [value]
- Border: [value]
- Radius: [value]
- Text: [values]
- Spacing: [values]
- Hover: [value]
- Composition: [brief pattern]

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]

How ui-registry.md Gets Used

The registry is not just a record. It is the consistency enforcer for every future session.

At the start of any session that involves UI work, the agent reads ui-registry.md before writing any component. When building a new card, it checks how existing cards were built. When building a new button, it checks what button patterns already exist. When building a new status badge, it matches the exact values already in use.

The registry grows as the project grows. The more components are imprinted, the more consistent every new component becomes — because the agent always has a precise reference for what already exists.

The Rule

Build a component. Run /imprint. Move on.

Every time. Without exception.

A registry with ten entries is useful. A registry with thirty entries is powerful. A registry that is sometimes updated is unreliable.

Consistency is a habit, not a feature.

Audit Mode — /imprint audit

Run this when the UI already exists and consistency is uncertain. Instead of capturing from one component, it scans the entire codebase, finds conflicts, and establishes a clean baseline before any further capturing happens.

Step 1 — Detect the styling approach

Same as the regular mode — identify how this project does styling.

Step 2 — Scan all UI components

Find every component file in the project. Read each one. Build a complete picture of what visual patterns are currently in use across the entire interface.

Step 3 — Check for a typography scale

Look for a consistent sizing hierarchy across the project:

• Is there a clear scale for headings (h1 → h2 → h3)?
• Are body, label, and caption sizes consistent?
• Are font weights used consistently for emphasis?

If a typography scale exists, capture it. If sizing is inconsistent, flag it.

Step 4 — Identify conflicts

For each visual property that matters for consistency, list every variation found:

## UI Consistency Audit

Styling approach: [what the project uses]

### Typography scale
[If found: the consistent scale]
[If inconsistent: the variations found]

### Conflicts found

**Border radius**
[List every variant found and which components use it]
Recommendation: [which one to standardise on and why]

**Background colors**
[List every value found — flag any hardcoded values that bypass tokens]
Recommendation: [which token or value should be standard]

**Text colors**
[List every text color found — flag any that bypass the design system]
Recommendation: [which token or value should be standard]

**Spacing**
[List padding and gap variations found]
Recommendation: [which values to standardise on]

**Border colors**
[List every border color found]
Recommendation: [which token or value to standardise on]

**Interactive states**
[List hover, focus, active variations found]
Recommendation: [which pattern to standardise on]

**Accessibility**
[Focus ring consistency, aria pattern consistency]
Recommendation: [what to standardise on]

### Hardcoded values found
[List every hardcoded value that should use a design token instead —
with the file and line where it appears]
These should be replaced with design system tokens or variables.

### Theme inconsistencies
[If the project supports themes — list any values that don't
properly adapt between themes]

### Recommended baseline
[The correct pattern for each property —
based on what the majority already uses correctly
and what the design system defines]

Step 5 — Wait for developer confirmation

Present the audit report. Do not fix anything. Do not update ui-registry.md yet.

Ask the developer:

Audit complete. [X] conflicts found across [Y] properties.

Before I establish the baseline in ui-registry.md:
1. Do the recommendations above look correct?
2. Are there any conflicts you want to resolve differently?
3. Should I flag the hardcoded values as issues to fix?

Confirm the baseline and I will write it to ui-registry.md.

Step 6 — Write the confirmed baseline

After the developer confirms — write the agreed baseline to ui-registry.md as the foundation. Label it clearly:

# UI Registry

Styling approach: [what the project uses]
Last updated: [date]

## Baseline — Established [date]

[Note: This baseline was established via /imprint audit]

### Typography scale
| Level     | Size / Token   | Weight         |
| --------- | -------------- | -------------- |
| Heading 1 | [value/token]  | [value/token]  |
| Heading 2 | [value/token]  | [value/token]  |
| Heading 3 | [value/token]  | [value/token]  |
| Body      | [value/token]  | [value/token]  |
| Label     | [value/token]  | [value/token]  |
| Caption   | [value/token]  | [value/token]  |

### Visual tokens
| Property         | Correct value / token |
| ---------------- | --------------------- |
| Card background  | [value/token]         |
| Card border      | [value/token]         |
| Card radius      | [value/token]         |
| Button primary   | [value/token]         |
| Button secondary | [value/token]         |
| Text primary     | [value/token]         |
| Text secondary   | [value/token]         |
| Text muted       | [value/token]         |
| Input background | [value/token]         |
| Input border     | [value/token]         |
| Focus ring       | [value/token]         |

### Theme behavior
[Which properties change between themes and how]

Step 7 — List what needs fixing

After writing the baseline, produce a fix list — every component that deviates from it:

## Components to fix

These components deviate from the confirmed baseline
and should be updated:

- [Component file] — [what is wrong] → [what it should be]
- [Component file] — [what is wrong] → [what it should be]

The developer can now fix these systematically — or fix them as they encounter each component. Either way, the baseline is established and /imprint can be used going forward to keep new components consistent.