tkc310 · Oct 21, 2026 · Oct 21, 2026
diff --git a/.claude/skills/design-adjust/SKILL.md b/.claude/skills/design-adjust/SKILL.md
@@ -5,22 +5,10 @@ description: 既存のデザインシステムまたは DESIGN.md を調整・
 
 # 既存デザインシステム調整
 
-`design-principles` スキルの「モード 2: 既存の調整」を実行する。
+`design-principles` スキルの「モード 2: 既存の調整」を直接呼ぶ入口。
 
-## 実行内容
+1. `../design-principles/SKILL.md` を読み、「ルールの優先順位」と手順 1（前提条件のヒアリング。既存の DESIGN.md から分かることは聞かない）を行う
+2. `../design-principles/mode-2-adjust.md` を読み、調整する領域に関係する `references/` だけを読む
+3. トークンやコンポーネントを追加・変更し、DESIGN.md を更新する（成果物は mode-2-adjust.md）
 
-1. design-principles スキルを読み込む
-2. **前提条件のヒアリング**: 既存の DESIGN.md とリポジトリ内の情報を確認し、変更点や追加の制約をユーザーに質問する
-3. UI の方向性が適切か確認する（ドメインと対象ユーザーが変わった場合は見直す）
-4. 調整が必要な領域に関係するルールを参照する
-5. トークンやコンポーネントの追加・変更を行う
-6. DESIGN.md を更新する
-
-**ルールへのフィードバック**: 対話中にルールの改善点が見つかった場合、ユーザーに伝え、`docs/design-principles/` への編集を提案する。正本は `docs/design-principles/`（スキルの `references/` はそこへのシンボリックリンク）。
-
-## 成果物
-
-- UI の方向性の確認結果（変更がある場合は新しい方向性と理由）
-- 追加・変更したトークンとコンポーネントの定義
-- 必須ルールを外した場合の理由の追記
-- 既存ルールとの整合性確認結果
+ルールのギャップに気づいたら `../design-principles/feedback.md` の手順でユーザーに伝える。
diff --git a/.claude/skills/design-init/SKILL.md b/.claude/skills/design-init/SKILL.md
@@ -5,26 +5,10 @@ description: 新しいデザインシステムまたは DESIGN.md を作成す
 
 # 新規デザインシステム作成
 
-`design-principles` スキルの「モード 1: 新規作成」を実行する。
+`design-principles` スキルの「モード 1: 新規作成」を直接呼ぶ入口。
 
-## 実行内容
+1. `../design-principles/SKILL.md` を読み、「ルールの優先順位」と手順 1（前提条件のヒアリング）を行う
+2. `../design-principles/mode-1-init.md` を読み、その「読む順序」で必要な `references/` だけを読む
+3. UI の方向性 → 特化ルール → 原則 → WCAG の順でルールを適用し、DESIGN.md を作る（成果物は mode-1-init.md）
 
-1. design-principles スキルを読み込む
-2. **前提条件のヒアリング**: リポジトリ内の既存情報を確認し、推測できない項目をユーザーに質問する
-3. UI の方向性を決める（オブジェクト指向 UI かタスク指向 UI か）
-4. 該当するサービス種別を選ぶ（管理画面、社内向けツール、SaaS、toC）
-5. UI の方向性 → 特化ルール → 原則 → WCAG の順でルールを適用する
-6. DESIGN.md を作成する
-
-**ルールへのフィードバック**: 対話中にルールの改善点が見つかった場合、ユーザーに伝え、`docs/design-principles/` への編集を提案する。正本は `docs/design-principles/`（スキルの `references/` はそこへのシンボリックリンク）。
-
-## 成果物
-
-次を含む DESIGN.md：
-
-- プロダクトの UI の方向性（オブジェクト指向 UI かタスク指向 UI か）と選択理由
-- 画面領域ごとの UI の方向性（一つのプロダクトに両方の画面があるときは領域ごとに書く）
-- 画面領域ごとのサービス種別（管理画面、社内向けツール、SaaS、toC）
-- 採用したルール（優先順位順）
-- トークン名とコンポーネント名の対応
-- 必須ルールを外した項目がある場合、その理由
+ルールのギャップに気づいたら `../design-principles/feedback.md` の手順でユーザーに伝える。
diff --git a/.claude/skills/design-principles/SKILL.md b/.claude/skills/design-principles/SKILL.md
@@ -5,194 +5,62 @@ description: ウェブの画面設計ルール。新規デザインシステム
 
 # デザイン原則スキル
 
-このスキルは、ウェブの画面を設計するときのルールを提供する。設計作業、DESIGN.md の作成・更新、デザインレビュー時に使う。
-
-## いつ使うか
-
-次のいずれかの作業を行うときに、このスキルを読み込む：
-
-- 新しいデザインシステムを作成する
-- プロジェクトの DESIGN.md を書く
-- 既存のデザインシステムや DESIGN.md を調整する
-- 画面デザインをレビューする
-- デザイン段階でアクセシビリティを評価する
+ウェブの画面を設計するときのルールを提供する。設計作業、DESIGN.md の作成・更新、デザインレビューのときに使う。
+ルールの本文は `references/`（このリポジトリの `docs/design-principles/` へのシンボリックリンク）にある。**この本体には手順の骨組みだけを置き、詳細は作業モードを決めてから読む。**
 
 ## ルールの優先順位
 
-画面を設計するときは、次の順でルールを適用する。後のルールは、前のルールが書いていない判断にだけ使う。
+次の順で適用する。後のルールは、前のルールが書いていない判断にだけ使う。
 
-1. **UI の方向性** - 画面をオブジェクト指向 UI にするかタスク指向 UI にするかを、ドメインと対象ユーザーから決める
+1. **UI の方向性** - オブジェクト指向 UI かタスク指向 UI かを、ドメインと対象ユーザーから決める
 2. **サービス別の特化ルール** - 管理画面、社内向けツール、SaaS、toC のいずれかに当たる画面では、特化ルールを満たす
-3. **ウェブデザインの原則** - UI の方向性と特化ルールが書いていない判断に使う
-4. **WCAG 2.2 の達成基準** - この必須は、UI の方向性、特化ルール、原則のいずれからも緩めない
-
-### ルールの強さ
-
-各ルールには「必須」と「推奨」がある。DESIGN.md での扱いは次のとおり：
+3. **ウェブデザインの原則** - 1 と 2 が書いていない判断に使う
+4. **WCAG 2.2 の達成基準** - この必須は、1〜3 のいずれからも緩めない
 
 | ルール | DESIGN.md での扱い |
 | --- | --- |
 | WCAG の必須 | 外せない。緩めることもできない |
 | 特化ルールと原則の必須 | 原則として採る。外すときは、外す理由を DESIGN.md に書く |
 | 推奨 | プロダクトごとに採るかどうかを決める |
 
-## 前提条件のヒアリング
-
-**すべての作業モードで、アウトプットを作る前に前提条件をヒアリングする。**
-
-`references/hearing.md` に従い、次の手順で進める：
-
-1. リポジトリ内の既存情報を確認する（DESIGN.md、コード、既存のトークンやコンポーネント）
-2. 推測できない項目だけをユーザーに質問する（短いリストにまとめる）
-3. ユーザーの回答を要約し、理解が正しいか確認する
-4. 確認した前提条件を DESIGN.md に記録する
-
-## 作業モード
-
-作業の目的に応じて、次のいずれかのモードを選ぶ。
-
-### モード 1: 新規作成（新しいデザインシステム / DESIGN.md）
-
-**目的**: これから作るプロジェクトの DESIGN.md を書く、または新しいデザインシステムを定義する。
-
-**読み込む順序**:
-
-1. `references/README.md` - 全体の構造と読み順を確認する
-2. `references/ui-orientation.md` - 画面の方向性（オブジェクト指向 UI かタスク指向 UI か）を、ドメインと対象ユーザーから決める
-3. `references/services/README.md` - 画面の目的に合う特化ルールを選ぶ
-4. 選んだ特化ルール（`references/services/admin.md`、`internal.md`、`saas.md`、`consumer.md` のいずれか）
-5. `references/principles.md` - UI の方向性と特化ルールが書いていない判断を補う
-6. `references/wcag-for-designers.md` - 必須の達成基準を確認する
-
-**成果物**:
-
-DESIGN.md に次を含める：
-
-- プロダクトの UI の方向性（オブジェクト指向 UI かタスク指向 UI か）と選択理由
-- 画面領域ごとの UI の方向性（一つのプロダクトに両方の画面があるときは領域ごとに書く）
-- 画面領域ごとのサービス種別（管理画面、社内向けツール、SaaS、toC）
-- 採用したルール（UI の方向性 → 特化ルール → 原則 → WCAG の順）
-- トークン名とコンポーネント名の対応
-- 必須ルールを外した項目がある場合、その理由
-
-**複数のプロダクトで共有する基盤のデザインシステムの場合**: UI の方向性とサービス種別は基盤では決めず、各プロダクトの DESIGN.md で決める。基盤の DESIGN.md には、原則の各ルールとトークン・コンポーネントの対応表、テーマごとの WCAG の確認結果、プロダクト側の DESIGN.md の雛形を含める。手順は `references/README.md` の「複数のプロダクトで共有する基盤のデザインシステムを作る」に従う。
-
-### モード 2: 既存の調整（既存 DS / DESIGN.md の調整）
-
-**目的**: 既にあるデザインシステムや DESIGN.md を見直す。トークンやコンポーネントを追加・変更する。
-
-**読み込む順序**:
-
-1. 既存の DESIGN.md または設計資料を確認する
-2. `references/README.md` - 読み順を確認する
-3. `references/ui-orientation.md` - 画面の方向性が適切か確認する（ドメインと対象ユーザーが変わった場合は見直す）
-4. 調整が必要な領域に関係する特化ルール（`references/services/` から該当するもの）
-5. `references/principles.md` の該当箇所
-6. `references/wcag-for-designers.md` の該当箇所
-
-**成果物**:
-
-- UI の方向性の確認結果（変更がある場合は新しい方向性と理由）
-- 追加・変更したトークンとコンポーネントの定義
-- 必須ルールを外した場合の理由の追記
-- 既存ルールとの整合性確認
+## 手順
 
-### モード 3: 評価・レビュー（画面/デザインの評価）
+1. **前提条件をヒアリングする**（すべてのモードで、アウトプットを作る前に）。`references/hearing.md` に従い、リポジトリから分かることは聞かず、推測できない項目だけを短いリストで聞く。回答を要約して確認し、DESIGN.md に記録する
+2. **作業モードを選び、そのモードの文書だけを読む**
 
-**目的**: 既存の画面デザインやモックアップをレビューする。ルール違反を見つけ、改善提案をする。
+   | 目的 | モード | 読む文書 |
+   | --- | --- | --- |
+   | これから作るプロダクトの DESIGN.md を書く・新しいデザインシステムを定義する | 1. 新規作成 | [mode-1-init.md](./mode-1-init.md) |
+   | 既存のデザインシステムや DESIGN.md を見直す・トークンやコンポーネントを足す | 2. 既存の調整 | [mode-2-adjust.md](./mode-2-adjust.md) |
+   | 画面やモックアップを評価し、違反と改善案を出す | 3. 評価・レビュー | [mode-3-review.md](./mode-3-review.md) |
 
-**読み込む順序**:
+3. **モードの文書が指す `references/` のファイルを、必要な範囲だけ読む**（下の「読む範囲を絞る」）
+4. ルールにギャップや曖昧さを見つけたら、[feedback.md](./feedback.md) の手順でユーザーに伝える
 
-1. レビュー対象の画面を確認する
-2. `references/README.md` - 評価基準の優先順位を確認する
-3. `references/ui-orientation.md` - 画面の方向性（オブジェクト指向 UI かタスク指向 UI か）が適切か、チェックリストを使って確認する
-4. 画面の目的に合う特化ルール（`references/services/` から）
-5. `references/principles.md` の適用ルール
-6. `references/wcag-for-designers.md` の必須項目
+## 読む範囲を絞る
 
-**成果物**:
+すべてのルールを一度に読まない。
 
-評価レポートを、次の構造で作成する：
-
-#### 0. UI の方向性の適合性
-
-画面の方向性が適切か確認する。
-
-- **現在の方向性**: オブジェクト指向 UI かタスク指向 UI か
-- **判断**: ドメインと対象ユーザーに照らして、現在の方向性が適切か
-- **チェックリスト結果**: `ui-orientation.md` のチェックリストに沿った確認結果
-- **提案**: 方向性の変更が必要な場合、理由とともに提案する
-
-#### 1. WCAG 必須違反
-
-達成基準を満たさない項目。必ず修正が必要。
-
-- **項目**: 該当する達成基準（例: 1.4.3 コントラスト（最低限））
-- **問題**: 何がどう基準を満たしていないか
-- **修正方法**: 具体的な改善案
-
-#### 2. 必須ルール違反
-
-UI の方向性、特化ルール、または原則の必須を満たさない項目。修正が必要（外す場合は理由を明記）。
-
-- **項目**: 該当するルール（例: 原則「操作の幾何」）
-- **問題**: どのルールに反しているか
-- **修正方法**: 具体的な改善案
-
-#### 3. 推奨からの提案
-
-推奨ルールに沿った改善提案。プロダクトの方針に応じて採用を検討する。
-
-- **項目**: 該当するルール
-- **提案**: より良くするための提案
-- **根拠**: なぜその提案が有効か
-
-## プログレッシブディスクロージャー
-
-すべてのルールを一度に読まない。作業モードと画面の種類に応じて、必要なファイルだけを読む。
-
-- **画面の方向性の決定**: ui-orientation.md だけを読む（特化ルールや原則は読まない）
-- **画面の種類が決まっている**: その特化ルールだけを読む（他の特化ルールは読まない）
-- **レビュー対象が部分的**: 該当する適用ルールだけを読む（principles.md の全体は読まない）
-- **WCAG の確認だけ**: wcag-for-designers.md だけを読む
-
-## ルールへのフィードバック
-
-対話中にルールの改善点が見つかった場合、ユーザーに伝え、このリポジトリの `docs/design-principles/` への具体的な編集を提案する（`references/` は `docs/design-principles/` へのシンボリックリンクなので、正本は `docs/design-principles/` である）。
-
-**改善が必要な場合**:
-- ルールにギャップがある（判断基準が書かれていない）
-- ルールが曖昧で解釈に迷う
-- ルールが特定の状況に適合しない
-- 同じ例外を繰り返し認める必要がある
-
-**提案の手順**:
-1. 問題を具体的に説明する
-2. `docs/design-principles/` のどのファイルの、どの箇所を、どう変更するか提案する
-3. ユーザーの承認を得てから、PR を通じて変更する
-
-**プロダクト固有の例外**: 共有ルールではなく、そのプロダクトの DESIGN.md に記録する。
+- **画面の方向性を決めるだけ**: `references/ui-orientation.md` だけ（特化ルールや原則は読まない）
+- **画面の種類が決まっている**: その特化ルール（`references/services/` の 1 ファイル）だけ
+- **レビュー対象が部分的**: `references/principles.md` の該当する適用ルールの節だけ（見出しで探して読む）
+- **WCAG の確認だけ**: `references/wcag-for-designers.md` の該当する達成基準だけ
 
 ## 注意事項
 
-- `references/` 以下のファイルが、実際のルールの置き場所である
-- WCAG の必須は、どの場合も緩めない
 - UI の方向性と特化ルールが原則と食い違うときは、UI の方向性と特化ルールを採る
 - 特化ルールが WCAG より厳しいときは、特化ルールを採る
 - 必須ルールを外すときは、外す理由を必ず DESIGN.md に書く
-- UI の方向性とサービス種別は別の概念である（UI の方向性は OOUI かタスク指向か、サービス種別は管理画面か SaaS かなど）
-
-## ファイル参照パス
-
-`references/` は、このリポジトリの `docs/design-principles/` へのシンボリックリンクである。Claude Code（`.claude/skills/`）、Codex と Cursor（`.agents/skills/` → `.claude/skills/`）のどれから読んでも同じファイルを指す。
-
-- `references/README.md` - ルール全体の構造
-- `references/hearing.md` - 前提条件のヒアリング項目
-- `references/ui-orientation.md` - UI の方向性の選択
-- `references/services/README.md` - サービス別特化ルールの選び方
-- `references/services/admin.md` - 管理画面
-- `references/services/internal.md` - 社内向けツール
-- `references/services/saas.md` - SaaS
-- `references/services/consumer.md` - toC サービス
-- `references/principles.md` - ウェブデザインの原則
-- `references/wcag-for-designers.md` - WCAG 2.2 の達成基準
+- UI の方向性とサービス種別は別の概念である（方向性は OOUI かタスク指向か、サービス種別は管理画面か SaaS かなど）
+- 複数のプロダクトで共有する基盤のデザインシステムでは、UI の方向性とサービス種別を決めない（[mode-1-init.md](./mode-1-init.md) の「共有の基盤の場合」）
+
+## `references/` の中身
+
+| ファイル | 内容 |
+| --- | --- |
+| `README.md` | ルール全体の構造と読み順 |
+| `hearing.md` | 前提条件のヒアリング項目 |
+| `ui-orientation.md` | UI の方向性の選択とチェックリスト |
+| `services/README.md` | 特化ルールの選び方（`admin.md`・`internal.md`・`saas.md`・`consumer.md`） |
+| `principles.md` | ウェブデザインの原則（15 の適用ルール） |
+| `wcag-for-designers.md` | WCAG 2.2 の達成基準 |
diff --git a/.claude/skills/design-principles/feedback.md b/.claude/skills/design-principles/feedback.md
@@ -0,0 +1,18 @@
+# ルールへのフィードバック
+
+対話中にルールの改善点が見つかったときに読む。ルールの正本は `docs/design-principles/`（スキルの `references/` はそこへのシンボリックリンク）。
+
+## 改善が必要な場合
+
+- ルールにギャップがある（判断基準が書かれていない）
+- ルールが曖昧で解釈に迷う
+- ルールが特定の状況に適合しない
+- 同じ例外を繰り返し認める必要がある
+
+## 提案の手順
+
+1. 問題を具体的に説明する
+2. `docs/design-principles/` のどのファイルの、どの箇所を、どう変更するか提案する
+3. ユーザーの承認を得てから、PR を通じて変更する
+
+**プロダクト固有の例外**: 共有ルールではなく、そのプロダクトの DESIGN.md に記録する。