| name | np-design |
| description | 体験設計の壁打ちと UI デザイン案の提案。「こういう機能を作る」「この画面を良くしたい」を受けて、
どんな体験にするかを壁打ちして体験方針に合意し、方針に沿った UI 案を
デザイン憲法（DESIGN.md）とトークンに準拠した 1 枚の HTML で提示する。
Use when:
- /np-design を実行した場合
- 「デザイン案がほしい」「この画面のデザインを考えて」「どんな体験にすべきか相談したい」等の依頼
- 実装前にデザイン・体験の方向性を検討したいとき
NOT for:
- 実装そのもの（このスキルは提案まで。採用後の実装は別タスク）
- 文言だけの微修正
|
np-design — 体験設計の壁打ちとデザイン案の提案
デザイナーの思考プロセスを 2 段階承認で再現する:
「こういう機能を作る」→ ①どんな体験にするか壁打ちして体験方針に合意 →
②方針に沿った UI 案を 2〜3 案提示して承認 → 判断を DESIGN.md へ還元。
成果物は「調査・体験方針・デザイン案・仕様が 1 枚に」まとまった HTML。
入口は機能起点（新機能の体験設計）でも画面起点（既存画面の改善）でもよい。
途中下車可: ゲート①の方針合意だけで終了してよい。壁打ちの記録なので、残すかどうか・
どこに残すかは決め打ちせず利用者に確認する。
必読（作業前に必ず読む）
DESIGN.md — ブランド人格・原則・文言の話者基準shared/src/styles/index.css — トークン実値（成果物 HTML に inline する）- 対象領域の既存実装 — 類似画面・類似セクションを必ず読んでから案を出す（新方式を出す前に既存と比較する）
ワークフロー
1. 前提確認
お題・対象（web / lp / widget / dashboard / 新規）・機能の内容・制約を整理する。
曖昧点があれば AskUserQuestion で 1 回にまとめて 質問する。明確なら聞かずに進む。
2. 調査
- 既存の類似画面・shared 部品を読み、再利用できるものを列挙する
- 必要に応じて参考事例を WebSearch する（出典 URL を成果物に記録する）
3. 体験設計の壁打ち（承認ゲート ①）
合意するまで UI 案を作らない。 機能の説明を受けて、次を対話で言語化する:
- 誰が使うか（村民か・村外ファンか・管理者か）
- どんな状況で使うか（文脈・デバイス・頻度）
- 使い終わったとき、どんな状態・気持ちになっていてほしいか
- この体験で やらないこと（例: 選択肢を増やさない、説明で埋めない）
これを 体験方針 1〜3 行 に要約して提示し、合意を得る。
壁打ちで意見が割れたら選択肢を並べて判断を仰ぐ。自分の推奨と理由も添える。
4. 案出し（2〜3 案）
- 全案が合意した体験方針に従う。方針の解釈が異なる案を混ぜない
- 差は 情報構成・レイアウト・導線 のレベルでつける。色や書体で差をつけない（全案トークン内で表現する）
- 各案に狙いを 1 文で言語化する（例: 「案A: 一覧性優先」「案B: 対話導線優先」）
5. 成果物 HTML
self-contained な単一 HTML として出力する。
規模に比例させる。 フル構成は画面・機能級のお題のみ。セクション 1 つ程度の小さいお題では
§2 調査や状態並置を省略してよい（体験方針と案の比較だけは必ず残す）。
構成（この順で 1 枚に）:
- 課題と目的 + 合意した体験方針（ゲート①の合意内容を記録）
- 調査メモ（既存実装・参考事例、出典付き）
- 各案のフルレンダリング
- 比較表（狙い / 長所 / 短所 / 実装コスト）
- 推奨案と理由
- 実装メモ（使用トークン・使う shared 部品・新規に必要な部品）
作り込み度:
- 静的レンダリングのみ。JS のインタラクションは作らない（動きの検証は実装後）
- モバイル幅とデスクトップ幅を並置する（村民はスマホ主体のためモバイルを主に）
- 判断に効く状態（ローディング / エラー / 空）はバリエーションとして並べて見せる
スタイルの書き方:
shared/src/styles/index.css の内容を <style> に inline し、プレーン CSS + var(--…) で書く（Tailwind ビルドなしで単体表示できるようにするため）- フォントは Google Fonts（Zen Maru Gothic / M PLUS Rounded 1c）を
<link> で読み込む。オフライン閲覧はフォールバックで許容
- 生の hex・トークン外の色・任意値は禁止。DESIGN.md の原則に全案準拠する
6. 提示（承認ゲート ②）
SendUserFile で HTML を送り、ローカルのブラウザで確認してもらう。配信・URL 共有はしない。
7. レビューと還元（育てるループ）
採用が決まったら、終了前に必ず次を行う:
- 繰り返し使える判断（UI の判断・体験方針のうち一般化できるもの）があれば、DESIGN.md「原則」への追加を提案する（追加は人間の承認を得てから。追加より削除を優先し、追加時は代わりに消せるものを探す）
- 新しいトークン・共有部品が必要なら、
index.css / shared への追加を提案する
- 採用案の実装をタスク化するか確認する。タスク化時は体験方針 1〜3 行と採用理由を Issue / PR description に転記する（機能固有の決定はここに残る）
