# Np Design

> 体験設計の壁打ちと UI デザイン案の提案。「こういう機能を作る」「この画面を良くしたい」を受けて、 どんな体験にするかを壁打ちして体験方針に合意し、方針に沿った UI 案を デザイン憲法（DESIGN.md）とトークンに準拠した 1 枚の HTML で提示する。 Use when: - /np-design を実行した場合 - 「デザイン案がほしい」「この画面のデザインを考えて」「どんな体験にすべきか相談したい」等の依頼 - 実装前にデザイン・体験の方向性を検討したいとき NOT for: - 実装そのもの（このスキルは提案まで。採用後の実装は別タスク） - 文言だけの微修正

- Skill: `kayac/np-design` (Agent Skill)
- Install (CLI): `npx skillmds@latest add kayac/np-design`
- Raw SKILL.md: https://api.skillmd.com/api/skills/kayac/np-design/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: kayac (https://skillmd.com/u/kayac)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/kayac/np-design

---


# 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 に転記する**（機能固有の決定はここに残る）