imprint

UI の一貫性は、偶然に生まれるものではありません。すべてのコンポーネントが、すでに存在するものを意識して構築されることで実現します。

AI が構築するインターフェースの問題は、各コンポーネントが個別に構築されることです。エージェントは、3 セッション前に構築したものを覚えていません。そのため、間隔にばらつきが生じます。色も微妙に異なります。角丸も統一されません。まるで異なる好みを持つ複数の人が構築したようなアプリになります。

このスキルがその問題を解決します。UI コンポーネントを構築した後に実行してください。直前に構築したものを読み取り、一貫性に重要なパターンを抽出して保存するため、以降のすべてのコンポーネントでそのパターンに合わせられます。

コマンドは 1 つです。毎回実行してください。それがすべてです。

---

実行方法

UI コンポーネントを構築した後に、次を実行します。

/imprint

特定のファイルを対象にする場合：

/imprint [filepath]

既存のコードベースで一貫性を監査する場合：

/imprint audit

ファイルパスを指定しない場合、このスキルは最近作成または変更されたコンポーネントファイルを自動的に特定し、それらからパターンを抽出します。

監査モードを使用するタイミング：

• プロジェクトの UI がすでに存在し、一貫性があるかどうか不明な場合
• /imprint を実行せずに複数のセッションが経過した場合
• 見た目に違和感があるものの、その理由を特定しにくい場合
• 既存プロジェクトで初めて ui-registry.md を作成する前

最初から UI の記録を取っていなかったプロジェクトでは、/imprint を実行する前に /imprint audit を実行してください。

---

ステップ 1 — 直前に構築したものを見つける

ファイルパスが指定されている場合は、そのファイルを直接読み取ります。

ファイルパスが指定されていない場合は、このセッションで最も最近作成または変更されたコンポーネントファイルを特定します。components ディレクトリや、通常 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 つのコンポーネントから情報を取り込むのではなく、コードベース全体をスキャンして競合を見つけ、以降の取り込みを始める前に明確な基準を確立します。

ステップ 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 を使って新しいコンポーネントの一貫性を保てます。