Project Design Language

---
name: project-design-language
user-invocable: false
description: "【穴埋め雛形】このプロジェクト固有の「存在設計・体験設計」のSSOT。judgment-harness のプロジェクト層スキルとして、立ち上げ時に本ファイルを埋めて使う（雛形のままなら未確定＝推測で決めない）。デザイン/UI/モーション/コピーの方針判断、見た目や体験のトーン決め、画面・コンポーネント設計の前段で必ず参照する。"
---

# project-design-language — このプロジェクトの存在設計・体験設計 SSOT（穴埋め雛形）

このスキルは、**このプロジェクトに固有の決定（what / why）**を1か所に束ねるプロジェクト層スキル。
汎用の判断軸（how）は既存スキルに委譲し、ここには**このプロジェクトだけの値・方針**を書く。

> **使い方（雛形の埋め方）**:
> - プロジェクト立ち上げ時に `{...}` を対話で埋める（`judgment-harness` の発酵ループ参照）。
> - **推測で埋めない**。決まっていない項目は `TBD` と明記し、確定したものから反映する。
> - プロジェクトに合わせて name / description / 本文の呼称を書き換えてよい（例: `design-language`）。

## 発火条件（適用タイミング）

- デザイン/UI/トーン&マナー/コピー/モーションの**方針判断**をするとき
- 画面・コンポーネント設計の**前段**（汎用スキルを当てる前に、固有の前提を確認する）
- 「らしさ」「世界観」「雰囲気」「ブランド」「印象」に関わる相談
- 固有値（色/フォント/余白/動き/語り口）を**決める・参照する**とき

## 参照（howは汎用スキルに委譲）

固有の決定を下すときの「判断ロジック」は以下を併用する。**重複して書かない**。

| 観点 | 委譲先スキル |
|---|---|
| 描く瞬間の規律（コンセプト導出線/材質/引き算/シグネチャ表現） | `art-direction` |
| 情報設計・状態・コンポーネント/トークン化 | `ui-designer` |
| なぜ動かす/どう動かす（モーションの原則） | `animation-principles` |
| 音・触覚・空間など視覚外チャネル | `sensory-design` |
| 表現品質（動き/触感/視線誘導）の実装制約化 | `creative-coder` |
| デザインツール→壊れない実装への翻訳 | `frontend-implementation` |
| アクセシビリティ（セマンティクス/コントラスト/操作） | `accessibility-engineer` |
| 認知負荷・エラー防止・学習コスト | `usability-psychologist` |
| 想定ユーザー像の言語化 | `persona-designer` |
| 視覚テイスト等の固有の作法（演出層スキルを作った場合） | `{演出層スキル名 / なければ削除}` |

> ルール: 「どう判断するか」は上記。「このプロジェクトでは結局どう決めたか」は**本ファイル**。

## 外部デザイン知識ベース（任意）

> 個人・組織のデザイン判断基準（例: design-brain）を持っている場合にパスを記入する。
> テンプレートには「欄」だけを置き、中身は各自の環境に属する（OSS配布物に個人の審美眼を埋め込まない）。
> 未記入なら本セクションはスキップしてよい。

- **知識ベースのパス**: {例: /path/to/design-brain} | 未使用
- **読み込みの優先順**: {例: personal-style → anti-patterns → principles → patterns → references → trends} | TBD
- **必読**: {例: personal-style/core.md（判断の核）と anti-patterns/（禁止事項）} | TBD
- **還流**: プロト・実装で「効いた/効かなかった」が出たら知識ベース側の {例: feedback/} へ記録する

---

## 基本方針（存在設計の核）

- **誰のためのプロダクトか**: {想定ユーザー像。複数いる場合は優先関係も}
- **何を良しとするか（一言）**: {このプロジェクトの北極星}
- **核となる構造**: {例: 来訪者タイプ間の衝突をどう解くか、第一印象と導線の関係 等}
- **単一メタファー宣言**: {依頼文・ドメイン・雰囲気語から拾った手がかりを1つのメタファーへ束ねる（例:「◯◯の世界」）。以後の全表現判断の単一光源にする。手がかりが弱ければ推測せず候補提示→人間選定}: {…} | TBD

## 体験原則（迷ったらこの順で優先）

> 規範（守る）と逸脱（意図的に外す）を**対で**書く。"らしさ"は逸脱から生まれる（`judgment-harness` 参照）。

1. {原則1}
2. {原則2}
3. {原則3 …確定するたびに追記。検証中のものは「ドラフト」と明記}

---

## 固有値レジストリ（このプロジェクトの決定）

> 確定するたびにここを更新する。**値が入るまでは実装で勝手に決めない（推測禁止）**。
> 確定した値は最終的に `doc/input/design/` のSSOT（tokens等）と同期する。

### ビジュアル言語
| 項目 | 決定 | 状態 |
|---|---|---|
| 全体の質感ワード（3語） | {…} | TBD |
| 材質（コンセプトの手触り。影/ハイライト/彩度の導出元） | {例: マット・紙・水彩} | TBD |
| 背景・基調トーン | {…} | TBD |
| キーカラー / アクセント | {…} | TBD |
| 角丸・線・影の方針 | {…} | TBD |
| 余白の刻み（spacing scale） | {…} | TBD |
| タイポ（見出し / 本文 / 和欧） | {…} | TBD |

### アートディレクション（判断軸は `art-direction`）
| 項目 | 決定 | 状態 |
|---|---|---|
| タグライン（体験を一文で。画面にも打つ） | {…} | TBD |
| シグネチャ表現（テーマ由来の固有表現を主要インタラクションのどこに） | {…} | TBD |
| 引き算の禁止則（このプロジェクト固有。無ければ `art-direction` の既定を使う） | {例: 情報はカードで囲わない / 塗りは主CTAのみ} | TBD |

### モーション言語（判断軸は `animation-principles`）
| 項目 | 決定 | 状態 |
|---|---|---|
| モーションの役割（演出主体 / 補助のみ） | {…} | TBD |
| 基準デュレーション / イージング | {…} | TBD |
| 遷移の質感（カット / フェード / 連続変形 など） | {…} | TBD |
| reduced-motion 時の代替挙動 | {…} | TBD |

### 声・トーン（コピーの語り口）
| 項目 | 決定 | 状態 |
|---|---|---|
| 一人称 / 二人称 / 文体 | {…} | TBD |
| 語り口（ユーザータイプ別にあれば分ける） | {…} | TBD |
| 多言語方針 | {…} | TBD |

---

## 判断軸（具体の決めごとで迷ったとき）

- {例: 価値Aと価値Bで割れたら → その画面の主目的を先に決める。両取りしようとして薄めない}
- **トーンが揺れたら** → 固有値レジストリに照合。レジストリに無いなら"まだ決めていない"＝この場で勝手に決めず確認 or 暫定明記。
- **アクセシビリティと表現が衝突したら** → 表現側を作り替える（諦めるのではなく、誰も置き去りにしない形に再設計）。

## 進め方（最初に確認する問い）

- この画面/要素の主対象は誰か？立てたい第一印象（らしさ）の一言は？
- 固有値レジストリに必要な値はあるか？無ければ今決めるか、TBDで進めるか？

## 出力フォーマット（方針提示時）

1. 対象ユーザーと画面の主目的
2. 適用した体験原則（番号で）と固有値（レジストリ参照、TBDは明示）
3. 具体提案（汎用スキルへの委譲点を明記）
4. アクセシビリティ/パフォーマンス上の留意
5. 次アクション（プロトタイプ→値の確定→SSOT同期）

## よくある落とし穴

- 固有値が未確定なのに、実装側が**その場の勘で色やフォントを決める**（→ プロダクト全体が揺れる）。本ファイル/SSOTに集約する。
- 演出を「すごいから」入れて、意味の伝達や操作性を犠牲にする。
- 複数の価値を**1画面で両取り**しようとして、どちらにも刺さらない無難なデザインになる。
- reduced-motion / コントラスト / キーボード操作を後回しにし、表現と両立できなくなってから慌てる。