菜单
体験設計の壁打ちと UI デザイン案の提案。「こういう機能を作る」「この画面を良くしたい」を受けて、 どんな体験にするかを壁打ちして体験方針に合意し、方針に沿った UI 案を デザイン憲法（DESIGN.md）とトークンに準拠した 1 枚の HTML で提示する。 Use when: - /np-design を実行した場合 - 「デザイン案がほしい」「この画面のデザインを考えて」「どんな体験にすべきか相談したい」等の依頼 - 実装前にデザイン・体験の方向性を検討したいとき NOT for: - 実装そのもの（このスキルは提案まで。採用後の実装は別タスク） - 文言だけの微修正
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Manages verification of markdown files against live web pages. Tracks progress (Unverified/In Progress/Verified), logs changes, and facilitates side-by-side editing. Use when: - User wants to check markdown documentation against a website - User asks to "start verification" or "compare files with the web" - Validation of scraped content is needed NOT for: - Creating new markdown files from scratch - PDF-only verification (PDF の扱いは references/pdf-handling.md を参照)
コード変更の品質ゲート。lint・テスト・ビルド検証 → コード品質レビューを実行する。
stripHeaders 文脈欠落チェックの検知ロジック・重症度判定・出力フォーマットのリファレンス。エントリポイントは /np:chunk-context-check コマンド。
GitHub Projects PM Agent。議事録からタスク抽出・Issue化、Projects初期セットアップを行う。キラーUX:「雑に議事録を投げるとタスク化してくれる」
テストを書く前に発動。仕様から観点とテストケースを導出するための 3 軸チェックリストと技法カタログ。実装の翻訳ではなく仕様の検証になるテストを設計する。
ねっぷちゃん本番環境の利用分析レポート。会話数・ユーザー数・週別推移・トピック分析・印象的な話題を D1 から集計。
| name | np-design |
| description | 体験設計の壁打ちと UI デザイン案の提案。「こういう機能を作る」「この画面を良くしたい」を受けて、 どんな体験にするかを壁打ちして体験方針に合意し、方針に沿った UI 案を デザイン憲法（DESIGN.md）とトークンに準拠した 1 枚の HTML で提示する。 Use when: - /np-design を実行した場合 - 「デザイン案がほしい」「この画面のデザインを考えて」「どんな体験にすべきか相談したい」等の依頼 - 実装前にデザイン・体験の方向性を検討したいとき NOT for: - 実装そのもの（このスキルは提案まで。採用後の実装は別タスク） - 文言だけの微修正 |
デザイナーの思考プロセスを 2 段階承認で再現する: 「こういう機能を作る」→ ①どんな体験にするか壁打ちして体験方針に合意 → ②方針に沿った UI 案を 2〜3 案提示して承認 → 判断を DESIGN.md へ還元。 成果物は「調査・体験方針・デザイン案・仕様が 1 枚に」まとまった HTML。
入口は機能起点（新機能の体験設計）でも画面起点（既存画面の改善）でもよい。 途中下車可: ゲート①の方針合意だけで終了してよい。壁打ちの記録なので、残すかどうか・ どこに残すかは決め打ちせず利用者に確認する。
DESIGN.md — ブランド人格・原則・文言の話者基準shared/src/styles/index.css — トークン実値（成果物 HTML に inline する）お題・対象（web / lp / widget / dashboard / 新規）・機能の内容・制約を整理する。 曖昧点があれば AskUserQuestion で 1 回にまとめて 質問する。明確なら聞かずに進む。
合意するまで UI 案を作らない。 機能の説明を受けて、次を対話で言語化する:
これを 体験方針 1〜3 行 に要約して提示し、合意を得る。 壁打ちで意見が割れたら選択肢を並べて判断を仰ぐ。自分の推奨と理由も添える。
self-contained な単一 HTML として出力する。
規模に比例させる。 フル構成は画面・機能級のお題のみ。セクション 1 つ程度の小さいお題では §2 調査や状態並置を省略してよい（体験方針と案の比較だけは必ず残す）。
構成（この順で 1 枚に）:
作り込み度:
スタイルの書き方:
shared/src/styles/index.css の内容を <style> に inline し、プレーン CSS + var(--…) で書く（Tailwind ビルドなしで単体表示できるようにするため）<link> で読み込む。オフライン閲覧はフォールバックで許容SendUserFile で HTML を送り、ローカルのブラウザで確認してもらう。配信・URL 共有はしない。
採用が決まったら、終了前に必ず次を行う:
index.css / shared への追加を提案する