From pdm-design-doc
PdMとしてDesign Docを作成・仕様書に変換するワークフロースキル。「Design Docを作りたい」「機能の仕様を整理したい」「ユーザーの声から問題定義したい」「仕様書を書きたい」「何を作るか整理したい」など、プロダクト開発の上流設計が絡む作業では必ずこのスキルを参照すること。アイデア段階でも、「〇〇を作りたいんだけど」という曖昧な入力から始めてよい。
How this skill is triggered — by the user, by Claude, or both
Slash command
/pdm-design-doc:pdm-design-docThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
アイデア・ユーザーの声・問題の断片から出発し、**Design Doc → 仕様書** まで一貫して作るワークフロー。
アイデア・ユーザーの声・問題の断片から出発し、Design Doc → 仕様書 まで一貫して作るワークフロー。
ユーザーがどこから始めるかは毎回異なる。状況を見て適切なフェーズに飛び込む:
| ユーザーの状態 | 始めるフェーズ |
|---|---|
| 「〇〇を作りたい」「ユーザーが困っている」などアイデア段階 | Phase 1(ディスカッション) |
| 問題はある程度整理されている | Phase 2(Design Docドラフト) |
| Design Docはある、仕様書が欲しい | Phase 3(仕様書変換) |
まず何でもいいので話してもらう。粗くて大丈夫。以下の3ステップで整理していく。
「どんなことを解決したいですか?」と聞いて、頭の中にあるものをすべて吐き出してもらう。完璧な説明は不要。
以下の問いを状況に応じて使い、曖昧な部分を明確にしていく。全部聞く必要はない。核心に近い問いを選ぶ。
ユーザーを具体化する問い
問題を掘り下げる問い
解決策と問題を分離する問い
ゴールを明確にする問い
スコープを絞る問い
ディスカッションで出てきた内容を整理し、Design Docのドラフトに移る。
以下のテンプレートに沿って生成する。空欄・不明点は [要確認] とマークして残す。推測で埋めない。
# Design Doc|[機能・施策名]
## Background
なぜ今これに取り組むのか。経緯・背景・前提。
## Problem
解決する問題を定義する(定性・定量の両面)。
「誰が」「どんな状況で」「何に困っているか」を明確に。
## Goals
施策で達成したいことを箇条書きで。
成功指標(KPI/OKR)を含める。
## Non-Goals
今回スコープに含めないことを明示する。
「やらないことを決める」はGoalと同じくらい重要。
## User Story
形式: 「[ユーザー] は [したいこと] したい。なぜなら [理由] だから。」
## UX Flow
ユーザーの行動フローを順番に記述。
分岐・エラー状態・エッジケースも含める。
## Technical Notes
実装上の制約・考慮事項・依存関係。
不明点は [要確認] とマーク。
## Metrics
リリース後に何を計測するか。
Before/Afterの比較ができる指標を設定。
生成したら必ず以下を確認してユーザーに問い返す:
| 失敗パターン | 対処 |
|---|---|
| 最初から「この画面を作りたい」と解決策の話になる | 「その画面を使って、ユーザーは何を達成したいですか?」 |
| 問題が「UX全体を改善したい」など広すぎる | 「今最もユーザーが困っている場面を一つ選ぶとしたら?」 |
| GoalSが「〇〇機能をリリースする」になっている | 「リリースした結果、何が変わっていれば成功ですか?」 |
| Non-Goalsがない | 「今回やらないことを明示してください」 |
| Metricsが「ユーザーが満足する」など定性的 | 「それは何の数字で確認できますか?」 |
Design Docの「What & Why」を、エンジニアが実装に使える「How」の文書に変換する。
# 仕様書|[機能・施策名]
## 概要
Design DocのProblem + Goalsを1段落で圧縮。
「何のために・何を・誰向けに作るか」が3秒でわかること。
形式: 〇〇という課題を抱える[ユーザー]向けに、〇〇を実現する機能を実装する。
これにより〇〇が改善される。
## 対象ユーザー
- ロール・権限(「ログイン済みユーザー」はNG。具体的に)
- 利用シーン
- 技術リテラシー
## 機能要件
### [機能名]
- **概要**: 「ユーザーが〇〇する → システムが〇〇する」を一文で
- **ハッピーパス**: 正常系の操作フローを順番に(ユーザーの操作とシステムの反応を交互に)
- **エッジケース・例外処理**:
- 入力が空のとき
- 上限を超えたとき
- 権限がないユーザーがアクセスしたとき
- ネットワークが切れたとき
- **バリデーション**: 必須/任意・型・文字数制限・重複チェックの有無
## 非機能要件
- **パフォーマンス**: 応答時間の目標・想定負荷
- **セキュリティ**: 認証・認可・データの機密性
- **アクセシビリティ**: 準拠レベル・キーボード操作
- **対応環境**: ブラウザ・デバイス・OS
## やらないこと(スコープ外)
Design DocのNon-Goalsから引用し、理由を必ず添える。
## UI/UX仕様
- **表示状態**: デフォルト・ローディング・エラー・空状態・成功状態
- **画面遷移**: 遷移元・完了後の遷移先・キャンセル時の挙動
## データ仕様
| フィールド名 | 型 | 制約 | 備考 |
|---|---|---|---|
## 計測・ログ
| 指標 | 問い | イベント例 |
|---|---|---|
| 採用率 | 機能を使っているか | `feature_opened` |
| 継続率 | 使い続けているか | 7日後・28日後の再利用 |
| 完了率 | 目的を達成できているか | フロー最終ステップ到達 |
| エラー率 | どこで詰まっているか | `error_shown` |
## Open Questions
| # | 問い | 担当 | 期限 |
|---|---|---|---|
よくある漏れ
PdMが判断・責任を持つべきこと(AIには任せない)
AIが知らない情報(ユーザーが持ち込む必要がある)
AIとのディスカッションが盛り上がっても「検証完了」ではない。内部ロジックの整合性を整えるのが役割。
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub hico-mrmgn/skills --plugin pdm-design-doc