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

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

使い方（雛形の埋め方）:

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

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

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

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

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

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

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

個人・組織のデザイン判断基準（例: 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等）と同期する。

ビジュアル言語

アートディレクション（判断軸は art-direction）

モーション言語（判断軸は animation-principles）

声・トーン（コピーの語り口）

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

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

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

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

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

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

よくある落とし穴

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