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は汎用スキルに委譲）

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

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

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

---

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

• 誰のためのプロダクトか: {想定ユーザー像。複数いる場合は優先関係も}
• 何を良しとするか（一言）: {このプロジェクトの北極星}
• 核となる構造: {例: 来訪者タイプ間の衝突をどう解くか、第一印象と導線の関係 等}

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

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

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

---

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

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

ビジュアル言語

項目	決定	状態
全体の質感ワード（3語）	{…}	TBD
背景・基調トーン	{…}	TBD
キーカラー / アクセント	{…}	TBD
角丸・線・影の方針	{…}	TBD
余白の刻み（spacing scale）	{…}	TBD
タイポ（見出し / 本文 / 和欧）	{…}	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 / コントラスト / キーボード操作を後回しにし、表現と両立できなくなってから慌てる。