imprint

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

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.

UI一致性并非偶然形成。它源于每个组件的构建都充分考虑了已有的设计。

AI构建界面的问题在于每个组件都是孤立开发的。Agent无法记住它在三个会话前构建的内容。因此间距会逐渐偏移，颜色略有差异，圆角半径不一致。整个应用看起来像是由不同审美偏好的多人开发而成。

本Skill解决了这个问题。在构建任意UI组件后运行它，它会读取刚构建的内容，提取对一致性至关重要的模式并保存下来，让未来的所有组件都能与之匹配。

只需一条命令。每次构建后都运行它。这就是完整的系统。

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.

构建任意UI组件后，运行：

/imprint

若要指定特定文件：

/imprint [filepath]

若要审核现有代码库中的不一致问题：

/imprint audit

如果未指定文件路径，该Skill会自动识别最近创建或修改的组件文件并从中提取模式。

何时使用审核模式：

项目UI已存在，但一致性无法保证
多次会话未运行
```
/imprint
```
视觉效果看起来不协调，但难以确定原因
在现有项目中首次建立
```
ui-registry.md
```
之前

对于那些从一开始就未跟踪UI的项目，在运行

/imprint

之前先运行

/imprint audit

。

Step 1 — Find What Was Just Built

步骤1 — 定位刚构建的内容

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?

如果提供了文件路径 — 直接读取该文件。

如果未提供文件路径 — 识别本次会话中最近创建或修改的组件文件。查看components目录以及其他通常存放UI文件的位置，读取这些文件。

如果无法确定要从哪些文件提取，询问开发者：

Which component should I capture patterns from?

Step 2 — Extract What Matters for Consistency

步骤2 — 提取对一致性至关重要的内容

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

读取组件代码。仅提取影响界面视觉一致性的类和值。并非所有内容都要提取 — 只提取那些能让组件看起来浑然一体的元素。

需要提取的内容：

背景 — 容器、卡片、面板使用的bg-类
边框 — 边框颜色、边框宽度、边框样式
圆角半径 — 该类型组件使用的rounded-类
文本颜色 — 主文本、次要文本、弱化文本的类
文本大小和字重 — 标题、正文、标签、说明文字的相关设置
间距 — 组件内部的内边距、元素之间的间隙
交互状态 — hover、focus、active类
阴影 — 如果使用的话
任何强调色或品牌色的使用

无需提取的内容：

宽度和高度 — 过于依赖上下文，不适合作为一致性规则
Flex和Grid布局 — 属于结构层面，非视觉层面
定位 — absolute、relative、z-index — 依赖上下文
动画和过渡时长 — 除非是值得强制执行的模式
响应式断点变体 — 仅提取基础模式

Step 3 — Write to ui-registry.md

步骤3 — 写入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.

打开

ui-registry.md

。如果文件不存在，则创建它。

为捕获的组件添加新条目。不要覆盖现有条目 — 追加到注册表中。

如果该类型组件的条目已存在 — 更新它而非重复添加。

Entry format

条目格式

markdown

undefined

markdown

undefined

[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]

---

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

步骤4 — 确认捕获的内容

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]

写入ui-registry.md后，向开发者确认：

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.

如果在提取过程中发现任何不一致或异常情况 — 标记出来：

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

How ui-registry.md Gets Used

ui-registry.md的使用方式

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, Claude 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 classes already in use.

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

该注册表不仅是记录，更是未来所有会话中的一致性执行者。

在任何涉及UI工作的会话开始时，Claude会先读取ui-registry.md，再编写任何组件。构建新卡片时，它会查看现有卡片的构建方式；构建新按钮时，它会检查已有的按钮模式；构建新状态徽章时，它会匹配已在使用的精确类。

注册表会随着项目的发展而不断完善。被记录的组件越多，新组件的一致性就越强 — 因为Claude始终拥有精确的已有设计参考。

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.

构建组件。运行

/imprint

。继续开发。

每次都要这样做。无一例外。

包含10个条目的注册表是有用的。包含30个条目的注册表则是强大的。偶尔更新的注册表是不可靠的。

一致性是一种习惯，而非特性。

Audit Mode — /imprint audit

审核模式 — /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.

当UI已存在且一致性无法保证时运行此命令。它不会从单个组件提取模式，而是扫描整个代码库，找出冲突，并在后续提取操作前建立清晰的基准。

Step 1 — Scan all UI components

步骤1 — 扫描所有UI组件

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 2 — Identify conflicts

步骤2 — 识别冲突

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

undefined

对于每个对一致性至关重要的视觉属性，列出发现的所有变体：

undefined

UI Consistency Audit

Conflicts found

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

Background colors [List every bg- class found — flag any hardcoded hex values] Recommendation: [which token classes should replace them]

Text colors [List every text- color class found — flag any that bypass the design system] Recommendation: [which token classes should replace them]

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

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

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

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

Background colors [List every bg- class found — flag any hardcoded hex values] Recommendation: [which token classes should replace them]

Text colors [List every text- color class found — flag any that bypass the design system] Recommendation: [which token classes should replace them]

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

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

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

Hardcoded values found

[List every hardcoded hex value, raw color class, or non-token value found — with the file and line where it appears] These must be replaced with design system tokens.

Recommended baseline

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

undefined

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

undefined

Step 3 — Wait for developer confirmation

步骤3 — 等待开发者确认

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.

提交审核报告。不要修复任何内容。暂时不要更新ui-registry.md。

询问开发者：

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 4 — Write the confirmed baseline

步骤4 — 写入确认后的基准

After the developer confirms — write the agreed baseline to

ui-registry.md

as the foundation. Label it clearly:

markdown

undefined

开发者确认后 — 将商定的基准写入

ui-registry.md

作为基础。清晰标注：

markdown

undefined

Baseline — Established [date]

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

Property	Correct class
Card background	[class]
Card border	[class]
Card radius	[class]
Button primary	[class]
Button secondary	[class]
Text primary	[class]
Text secondary	[class]
Text muted	[class]
Input background	[class]
Input border	[class]

undefined

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

Property	Correct class
Card background	[class]
Card border	[class]
Card radius	[class]
Button primary	[class]
Button secondary	[class]
Text primary	[class]
Text secondary	[class]
Text muted	[class]
Input background	[class]
Input border	[class]

undefined

Step 5 — List what needs fixing

步骤5 — 列出需要修复的内容

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

undefined

写入基准后，生成修复列表 — 所有偏离基准的组件：

undefined

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.

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]


开发者现在可以系统地修复这些问题 — 或者在遇到每个组件时再修复。无论哪种方式，基准已建立，后续可以使用`/imprint`来保持新组件的一致性。