np-design

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。

入口は機能起点（新機能の体験設計）でも画面起点（既存画面の改善）でもよい。 途中下車可: ゲート①の方針合意だけで終了してよい。壁打ちの記録なので、残すかどうか・ どこに残すかは決め打ちせず利用者に確認する。

必読（作業前に必ず読む）

1. DESIGN.md — ブランド人格・原則・文言の話者基準
2. shared/src/styles/index.css — トークン実値（成果物 HTML に inline する）
3. 対象領域の既存実装 — 類似画面・類似セクションを必ず読んでから案を出す（新方式を出す前に既存と比較する）

ワークフロー

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 枚に）:

1. 課題と目的 + 合意した体験方針（ゲート①の合意内容を記録）
2. 調査メモ（既存実装・参考事例、出典付き）
3. 各案のフルレンダリング
4. 比較表（狙い / 長所 / 短所 / 実装コスト）
5. 推奨案と理由
6. 実装メモ（使用トークン・使う 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 に転記する（機能固有の決定はここに残る）