imprint

UI 一致性不会自动实现。只有在构建每个组件时都考虑到已有内容，才能做到这一点。

AI 构建界面的问题在于，每个组件都是孤立构建的。Agent 不会记得三个会话前构建了什么。于是间距逐渐偏离，颜色略有差异，边框圆角也不一致。整个应用看起来就像由多个品味各异的人共同构建。

这项技能可以解决这个问题。构建任何 UI 组件后都运行它。它会读取刚构建的内容，提取影响一致性的关键模式并保存下来，让后续每个组件都能保持一致。

一条命令。每次都运行。整个流程就这么简单。

---

如何调用

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

/imprint

指定特定文件：

/imprint [filepath]

审查现有代码库中的不一致之处：

/imprint audit

如果没有提供文件路径，这项技能会自动识别最近创建或修改的组件文件，并从中提取内容。

何时使用审查模式：

• 项目 UI 已经存在，但不确定是否一致
• 多个会话过去了，却一直没有运行 /imprint
• 某些地方看起来不太对，但难以找出原因
• 首次在现有项目中创建 ui-registry.md 之前

如果某个项目从一开始就没有跟踪 UI，在该项目上运行 /imprint 之前，先运行 /imprint audit。

---

步骤 1 — 找出刚构建的内容

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

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

如果不确定要从哪些文件中提取内容，请询问开发者：

Which component should I capture patterns from?

---

步骤 2 — 提取影响一致性的内容

读取组件代码。只提取会影响整个界面视觉一致性的类和取值。无需提取所有内容，只提取能让组件看起来风格统一的部分。

提取以下内容：

• 背景 — 容器、卡片、面板使用的 bg- 类
• 边框 — 边框颜色、宽度和样式
• 边框圆角 — 此类组件使用的 rounded- 类
• 文本颜色 — 主要文本、次要文本和弱化文本的类
• 文本大小和字重 — 标题、正文、标签、说明文字的样式
• 间距 — 组件内边距、元素之间的间隔
• 交互状态 — hover、focus、active 类
• 阴影 — 若有使用
• 强调色或品牌色的使用方式

不要提取以下内容：

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

---

步骤 3 — 写入 ui-registry.md

打开 ui-registry.md。如果文件不存在，则创建该文件。

为刚提取的组件添加一条新记录。不要覆盖现有记录，而是追加到注册表中。

如果该组件类型已有记录，则更新该记录，不要重复添加。

记录格式

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

---

步骤 4 — 确认提取内容

写入 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]

---

ui-registry.md 的使用方式

注册表不只是记录。它是确保未来每次会话保持一致的保障。

在任何涉及 UI 工作的会话开始时，Claude 都会先读取 ui-registry.md，然后再编写组件。构建新卡片时，会检查现有卡片的构建方式。构建新按钮时，会检查已有的按钮模式。构建新状态徽章时，会使用完全相同的现有类。

注册表会随着项目的增长而扩展。记录的组件越多，每个新组件就越一致——因为 Claude 始终有一份准确的参考，了解现有内容。

---

规则

构建组件。运行 /imprint。继续下一步。

每次都要执行，不得例外。

包含 10 条记录的注册表很有用。包含 30 条记录的注册表则非常强大。偶尔才更新的注册表并不可靠。

一致性是一种习惯，而不是一项功能。

---

审计模式 — /imprint audit

当 UI 已经存在，但一致性不确定时，运行此命令。它不会只从一个组件中采集信息，而是会扫描整个代码库，找出冲突，并在继续采集信息之前建立一个干净的基线。

步骤 1 — 扫描所有 UI 组件

找出项目中的每个组件文件。逐一阅读，全面了解整个界面当前使用的视觉模式。

步骤 2 — 找出冲突

对于影响一致性的每个视觉属性，列出发现的所有变体：

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

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

步骤 3 — 等待开发者确认

提交审计报告。不要修复任何内容，也不要立即更新 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.

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

开发者确认后，将双方同意的基线写入 ui-registry.md，作为基础。清楚地标注：

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

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

写入基线后，生成修复清单，列出每个偏离基线的组件：

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

开发者现在可以有条理地修复这些问题，也可以在遇到每个组件时逐一修复。无论采用哪种方式，基线都已确立，之后可以使用 /imprint 来确保新组件保持一致。