mobile-design-system

mobile-design-system：トークン、テーマ、SAFE/RISK の提案

一貫性のあるシステムを、誠実に提案し、実際のファイルとして記述します。画面は作成しません。

フロー

1. スタックの調査とアプリの基本情報の確認

package.json ／ Tailwind の設定／既存のテーマファイル／MOBILE-DESIGN.md を読み込みます。 スタイリングシステム（NativeWind、StyleSheet、Tamagui、Paper）を検出します。出力形式は それに従います。アプリの種類、対象ユーザー、プラットフォーム方針、調整項目を定めます（各項目を1行で記述し、 MOBILE-DESIGN.md がある場合はそこから引き継ぎます）。カテゴリ別の傾向表を 適用します（mobile-taste SKILL.md 1.A2）。

2. SAFE/RISK の提案

システム全体を一つのパッケージとして明示的に分けて提案します。

SAFE CHOICES - ユーザーが期待するカテゴリの標準です。ほとんどのアプリでは、システムフォント、 ネイティブのクローム、控えめなニュートラルカラーの段階、プラットフォームで一般的な角丸です。これらが安全な選択肢である理由と、ここで安全策が適切な理由（または適切でない理由）を明確に述べます。

RISKS（最低2つ、最大4つ） - 意図的に標準から外れる選択肢。それぞれに次の内容を含めます。

RISK: <the move>            e.g. "true-black OLED dark mode as the primary theme"
gain: <what it buys>        "distinctive night identity, battery on OLED"
cost: <what it costs>       "elevation must come from borders, not shadows"

リスクがゼロの提案はテンプレートであり、すべてがリスクの提案は仮装です。

一貫性の検証 - 2つの選択が衝突する場合（高密度なプロ向けツールと遊び心のある丸みを帯びた書体、プラットフォームごとの方針と完全なカスタムタブバーなど）、1文で指摘し、解決策を提案します。指摘は必ず明示し、黙って「修正」してはいけません。

提案には次の内容を含めます：パレット（セマンティックトークン：background、surface、text-primary、 text-muted、accent、border、destructive。ライトとダーク両方の値）、書体のスケール（display/title/body/caption + SKILL.md 6.1 に従った Dynamic Type の範囲）、スペーシングのスケール、角丸のスケールと形状の固定ルール、エレベーションのトークン（iOS のシャドウと Android の elevation の組み合わせ）、アイコンのファミリーとストロークの太さ、触覚フィードバックの語彙、モーション方針（3つの調整項目がどう反映されるか）、シグネチャー要素の予算。

mobile-taste 6.2 から引き継ぐ厳守事項：アクセントカラーは1色、グレーの系統は1つ、インディゴの配色パイプラインは禁止、彩度はデフォルトで80%未満、両モードを初日から用意、OLED の純粋な黒は意図的な選択として明示した場合のみ使用可。

3. プレビュー（任意。一度だけ提案）

自己完結型の HTML 見本を提案します。外部リクエストのない1ファイルで、スウォッチ形式のパレット（両モード、切り替え可能）、実際のフォント（システムフォントまたは明示したフォント）で表示した書体のスケール、モックコンポーネントに適用した角丸とエレベーションのサンプルを含めます。ローカルで開きます。これはツール不要の方法であり、第一の方法です。画像生成や外部バイナリに依存してはいけません。

4. 実際のファイルを作成

調査したスタックに応じて作成します。

• NativeWind： tailwind.config のテーマ拡張 + theme/tokens.ts（プロジェクトで CSS 変数によるテーマ設定を使っている場合は vars() の連携も含む）+ ダークモードの値。
• StyleSheet： 色、書体、スペーシング、角丸、エレベーションを型付きオブジェクトとして定義した theme/tokens.ts と、useColorScheme に対応する useTheme() フック。
• 既存のトークンファイルがある場合： 既存ファイルを拡張します。既存のトークン名を変更することは、黙って変更してはならない項目の一覧に含まれます（../_shared/references/redesign-protocol.md）。

5. MOBILE-DESIGN.md に保存

## Design System セクションを作成（または差分レポートを添えて更新）し、承認済みの提案、RISK 登録簿、トークンファイルの場所を記載します。以降のセッションと関連スキルは、UI に関する決定を行う前にここを読み込みます。

このスキルを拘束するルール

• 一貫性のある提案を一度だけ行います。5種類のパレットから選ばせるような提案にはしません。ムードボードよりも、名前の付いたリスクを含む1つのシステムのほうが優れています。
• 作成するファイル内のすべての値は、承認済みの提案に由来します。紛れ込んだトークンは禁止です。
• ユーザーが RISK を拒否した場合は、SAFE バージョンに置き換え、変更内容を MOBILE-DESIGN.md に記録します。黙ってそのまま残してはいけません。