prd-development

目的

問題の枠組み設定、ユーザーリサーチの統合、ソリューションの定義、成功基準を調整して一貫性のあるドキュメントにまとめ、プロダクトマネージャーによる構造化された PRD（製品要件ドキュメント）の作成を支援します。散在したメモや Slack のスレッドを、ステークホルダー間の認識をそろえ、エンジニアリングに必要な背景情報を提供し、信頼できる情報源となる、明確で包括的な PRD にまとめる際に活用してください。曖昧さ、スコープクリープ、「頭の中にあるものをそのまま作る」という落とし穴を避けられます。

これはウォーターフォール型の仕様書ではありません。戦略的背景、顧客の課題、提案するソリューション、成功基準を記録し、開発を通じて学びながら進化する、生きたドキュメントです。

入力

最も効果的な情報： PRD の対象となる機能または取り組み。 あると役立つ情報： ディスカバリーのメモ、問題の記述、ユーザーリサーチ、成功指標、制約条件。すでにあるものは何でも貼り付けてください。このワークフローで適切なフェーズに組み込み、回答済みの項目はスキップします。

呼び出し時に与えられた情報は、スキル名の後に続くテキスト、貼り付けたコンテキストの一括入力、追記された ARGUMENTS: 行を含め、すべて回答済みとして扱います。その情報を活用し、該当する項目は質問し直さないでください。

手元に何もなくても大丈夫です。 このワークフローでは、問題の定義から始め、そこから内容を組み立てていきます。

呼び出し例： セルフサービスのワークスペースプロビジョニングに関する PRD を作成してください。ディスカバリーメモと、その取り組みが紐づく OKR を記載します。

主な概念

PRD とは？

PRD（製品要件ドキュメント）は、次の問いに答える構造化されたドキュメントです。

1. どのような問題を解決するのか？（問題の記述）
2. 誰のためか？（ターゲットユーザー／ペルソナ）
3. なぜ今なのか？（戦略的背景、ビジネスケース）
4. 何を作るのか？（ソリューションの概要）
5. 成功をどのように測定するのか？（指標、成功基準）
6. 要件は何か？（ユーザーストーリー、受け入れ基準、制約条件）
7. 何を作らないのか？（対象外）

PRD の構成（標準テンプレート）

# [Feature/Product Name] PRD

## 1. Executive Summary
- One-paragraph overview (problem + solution + impact)

## 2. Problem Statement
- Who has this problem?
- What is the problem?
- Why is it painful?
- Evidence (customer quotes, data, research)

## 3. Target Users & Personas
- Primary persona(s)
- Secondary persona(s)
- Jobs-to-be-done

## 4. Strategic Context
- Business goals (OKRs)
- Market opportunity (TAM/SAM/SOM)
- Competitive landscape
- Why now?

## 5. Solution Overview
- High-level description
- User flows or wireframes
- Key features

## 6. Success Metrics
- Primary metric (what we're optimizing for)
- Secondary metrics
- Targets (current → goal)

## 7. User Stories & Requirements
- Epic hypothesis
- User stories with acceptance criteria
- Edge cases, constraints

## 8. Out of Scope
- What we're NOT building (and why)

## 9. Dependencies & Risks
- Technical dependencies
- External dependencies (integrations, partnerships)
- Risks and mitigations

## 10. Open Questions
- Unresolved decisions
- Areas requiring discovery

この方法が有効な理由

• 認識合わせ： 全員（PM、デザイン、エンジニアリング、ステークホルダー）が「なぜ」を理解できるようにします
• 背景情報の保持： リサーチと戦略的な根拠を、後で参照できるように記録します
• 意思決定ログ： 対象範囲、対象外の項目、その理由を記録します
• 実行の明確化： ユーザーストーリーと受け入れ基準をエンジニアリングに提示します

アンチパターン（この文書ではないもの）

• 詳細な仕様書ではありません： PRD は問題とソリューションの枠組みを定めるものであり、UI をピクセル単位で指定するものではありません
• ウォーターフォール型ではありません： PRD は学びに応じて進化するものであり、変更できない契約ではありません
• コラボレーションの代わりではありません： PRD は対話を補完するものであり、対話に取って代わるものではありません

この方法を使う場面

• 大規模な機能や製品の取り組みを始めるとき
• スコープと要件について、部門横断チームの認識をそろえるとき
• 将来参照できるように意思決定を記録するとき
• 新しいチームメンバーにプロジェクトの概要を伝えるとき

この方法を使わない場面

• 小規模なバグ修正や些細な機能の場合（やりすぎです）
• 問題とソリューションがすでに明確で、認識もそろっている場合（ユーザーストーリーだけを書いてください）
• 継続的なディスカバリー実験の場合（代わりに Lean UX Canvas を使ってください）

---

ファシリテーションに関する信頼できる情報源

このワークフローをガイド付きの対話として進める場合は、対話プロトコルとして workshop-facilitation を使用してください。

次の内容を定義しています。

• セッションの事前案内と開始モード（ガイド付き、コンテキストの一括入力、最善の推測）
• 平易な言葉でのプロンプトによる、1 回につき 1 つの質問
• 進捗ラベル（例：Context Qx/8、Scoring Qx/5）
• 中断への対応と一時停止／再開の動作
• 意思決定ポイントでの番号付き推奨事項
• 通常の質問に対する、番号付きのクイック選択回答オプション（必要に応じて Other (specify) を含める）

このファイルでは、ワークフローの順序と、領域固有の出力を定義しています。矛盾がある場合は、このファイルのワークフローのロジックに従ってください。

アプリケーション

記入用ドキュメントとして template.md を使用します。テンプレートには以下が含まれています。

• セクションごとのガイダンスブロック — 各セクションに独自の「手順」「ステップ」「関連スキル」「アクティビティ」があり、このワークフローがなくてもテンプレートを見ながら進められます。
• 未解決事項のインラインタグ付け — すべての未解決事項に、🔶 仮定（もっともらしいものの、検証されていない）または 🔵 未解決の質問（不明で、調査が必要）のタグを付けます。未解決事項が現れる箇所にインラインでタグを付け、最後にまとめて付けるだけにしないでください。
• セクション間の推奨事項プロンプト — 各セクションを完了した後の「次に進む前に」ブロックで、前のセクションとの整合性を確認し、次のセクションで必要になる情報を示します。
• 自己評価 — セクション 10 の後に、最も優れたセクション、最も弱いセクション、検証が必要な主な仮定、PRD を共有する前に推奨される次のステップを診断します。
• スキル参照表 — 15 個のスキルと、それぞれが関連する具体的なセクションを対応付けます（例：problem-framing-canvas → セクション 2、epic-breakdown-advisor → セクション 7）。

このワークフローでは、複数のコンポーネントスキルと対話型スキルを使い、2～4 日間で8 つのフェーズを進めます。以下のフェーズでは進行手順を説明し、成果物はテンプレートに記録します。

---

フェーズ 1：エグゼクティブサマリー（30 分）

目標： 概要を知りたい人向けに、1 段落の概要を作成します。

アクティビティ

1. エグゼクティブサマリーの作成

• 形式：「[ソリューション] を構築し、[ペルソナ] が抱える [問題] を解決することで、[効果] を実現します。」

• 例：

  「技術的な知識のない小規模事業者のオーナー向けに、ガイド付きオンボーディングチェックリストを構築し、ガイダンス不足によって最初の 24 時間で 60% が離脱する問題を解決します。これにより、アクティベーション率を 40% から 60% に引き上げ、解約率を 10% 削減します。」

• 参加者： PM

• 所要時間： 30 分

• 成果物： 1 段落の概要

ヒント： 最初に書くと明確になりますが、ほかのセクションを完成させてから最後に見直してください。

---

フェーズ 2：問題定義（60 分）

目標： 顧客の問題を、根拠に基づいて定義します。

アクティビティ

1. 問題定義の作成

• 使用： skills/problem-statement/SKILL.md（コンポーネント）
• 入力： skills/discovery-process/SKILL.md または skills/problem-framing-canvas/SKILL.md から得られたディスカバリーの知見
• 参加者： PM
• 所要時間： 30 分
• 成果物： 構造化された問題定義

問題定義の例：

## 2. Problem Statement

### Who has this problem?
Non-technical small business owners (solopreneurs, 1-10 employees) who sign up for our SaaS product.

### What is the problem?
60% of users abandon onboarding within the first 24 hours because they don't know what to do first. They see an empty dashboard with no guidance, get overwhelmed by options, and leave.

### Why is it painful?
- **User impact:** Wastes time (30-60 min trying to figure out product), never reaches "aha moment," churns before experiencing value
- **Business impact:** 60% activation rate → high churn, low LTV, poor word-of-mouth

### Evidence
- **Interviews:** 8/10 churned users said "I didn't know what to do first" (discovery interviews, Feb 2026)
- **Analytics:** 60% of signups complete 0 actions within 24 hours (Mixpanel, Jan 2026)
- **Support tickets:** "How do I get started?" is #1 support question (350 tickets/month)
- **Customer quote:** "I logged in, saw an empty dashboard, and thought 'now what?' I gave up and went back to my spreadsheet."

2. 補足情報の追加（任意）

• カスタマージャーニーマップ： 問題が複数のタッチポイントにまたがる場合
• 使用： skills/customer-journey-mapping-workshop/SKILL.md の成果物
• ジョブ理論： 動機が重要な場合
• 使用： skills/jobs-to-be-done/SKILL.md の成果物

フェーズ 2 の成果物

• 問題定義： 誰が、何に、なぜ困っているか、その根拠
• 補足資料： ジャーニーマップ、JTBD（該当する場合）

---

フェーズ 3：ターゲットユーザーとペルソナ（30 分）

目標： 誰のために構築するのかを定義します。

アクティビティ

1. ペルソナの記述

• 使用： skills/proto-persona/SKILL.md（コンポーネント）の成果物
• 参加者： PM
• 所要時間： 30 分
• 形式： ペルソナの名前、役割、目標、課題、行動を記載します

例：

## 3. Target Users & Personas

### Primary Persona: Solo Entrepreneur Sam
- **Role:** Freelance consultant, solopreneur
- **Company size:** 1 person (no IT support)
- **Tech savviness:** Low (uses email, spreadsheets, basic SaaS)
- **Goals:** Get value from software fast without technical expertise
- **Pain points:** Overwhelmed by complex UIs, no time to watch tutorials, needs immediate value
- **Current behavior:** Signs up for products, tries for 1 day, churns if not immediately useful

### Secondary Persona: Small Business Owner (5-10 employees)
- **Role:** Owner-operator, manages team
- **Needs:** Onboard team members quickly
- **Differs from primary:** More tolerant of complexity, willing to invest setup time

フェーズ 3 の成果物

• 主要ペルソナ： 詳細なプロフィール
• 副次ペルソナ：（該当する場合）

---

フェーズ 4：戦略的背景（45 分）

目標： これがビジネスにとって重要な理由と、今取り組む理由を説明します。

アクティビティ

1. ビジネス目標を文書化する

• 情報源： 会社のOKR、戦略メモ、ロードマップ
• 形式： 機能とビジネス成果を関連付ける
• 例：

  「この取り組みは、Q1のOKRである『チャーン率を15%から8%に削減する』の達成を支援します。オンボーディングのアクティベーションを改善することは、リテンションに直接影響します。」

2. 市場機会を算出する（任意）

• 使用するもの： skills/tam-sam-som-calculator/SKILL.md（インタラクティブ）の出力
• タイミング： 大規模な取り組み、新製品、経営幹部向けプレゼンテーションの場合
• 例：

  「TAM：世界の中小企業5,000万社。SAM：SaaSツールを利用する500万社。SOM：対象セグメントの個人事業主50万人。オンボーディングの改善により、SAMの30%（潜在顧客150万人）を獲得できる可能性があります。」

3. 競争環境を文書化する（任意）

• 情報源： 競合調査、G2/Capterraのレビュー
• 例：

  「競合他社（競合A、B）はガイド付きオンボーディングを提供しています。解約者アンケートでは、ガイダンスの不足が解約理由として挙げられています。」

4. 「なぜ今なのか？」を説明する

• 根拠： なぜ後ではなく今、これを優先するのか？
• 例：

  「Q4にチャーン率が15%まで急増しました。主な要因はオンボーディングで、最初の30日以内の解約の60%を占めています。リテンションOKRを達成するには、この問題の解決が不可欠です。」

フェーズ4の成果物

• ビジネス目標： OKRまたは戦略的取り組み
• 市場機会： TAM/SAM/SOM（該当する場合）
• 競争環境： 競合他社の対応方法
• なぜ今なのか： 緊急性の根拠

---

フェーズ5：ソリューション概要（60分）

目標： 構築するものを説明します（詳細な仕様ではなく、概要レベル）。

アクティビティ

1. ソリューションの説明を書く

• 形式： 概要レベルの説明、2～3段落
• 例：

## 5. Solution Overview

We're building a **guided onboarding checklist** that walks new users through core workflows step-by-step when they first log in.

**How it works:**
1. User signs up and logs in for the first time
2. Modal appears: "Let's get you set up! Complete these 3 steps to get started."
3. Checklist shows:
   - ☐ Create your first project
   - ☐ Invite a teammate (optional)
   - ☐ Complete a sample task
4. As user completes each step, checklist updates with checkmarks
5. After completion, celebration modal: "You're all set! Here's what to do next."

**Key features:**
- Minimal: Only 3 core steps (not overwhelming)
- Dismissible: Users can skip if they prefer to explore
- Progress tracking: Visual progress bar (1/3, 2/3, 3/3)
- Celebration: Positive reinforcement when complete

2. ユーザーフローまたはワイヤーフレームを追加する（任意）

• 使用するもの： デザインツール（Figma、Sketch）、または手描きのスケッチ
• タイミング： 視覚的な説明が必要な複雑な機能の場合
• 成果物： PRDへの埋め込み、またはリンク

3. ストーリーマップを参照する（任意）

• 使用するもの： skills/user-story-mapping-workshop/SKILL.md の出力
• タイミング： 複数のリリーススライスを含む複雑な機能の場合
• 成果物： ストーリーマップへのリンク

フェーズ5の成果物

• ソリューションの説明： 概要レベルの説明
• ユーザーフロー／ワイヤーフレーム：（該当する場合）
• ストーリーマップ：（該当する場合）

---

フェーズ6：成功指標（30分）

目標： 成功をどのように測定するかを定義します。

アクティビティ

1. 主要指標を定義する

• 質問： この機能によって必ず変化させるべき指標は何ですか？
• 例：「アクティベーション率（24時間以内に最初のアクションを完了したユーザーの割合）」
• 目標：「40%から60%に増加させる」

2. 副次指標を定義する

• 質問： 最適化の対象にはしないものの、ほかに何を監視すべきですか？
• 例：
  • 最初のアクションまでの時間（3日から1日に短縮）
  • オンボーディングチェックリストの完了率（目標：80%）
  • サポートチケット数（「始め方を教えてください」という問い合わせを50%削減）

3. ガードレール指標を定義する

• 質問： 悪化させてはいけない指標は何ですか？
• 例：「サインアップのコンバージョン率（サインアップのフローに摩擦を加えない）」

例：

## 6. Success Metrics

### Primary Metric
**Activation rate** (% of users completing first action within 24 hours)
- **Current:** 40%
- **Target:** 60%
- **Timeline:** Measure 30 days after launch

### Secondary Metrics
- **Time-to-first-action:** Reduce from 3 days to 1 day
- **Onboarding checklist completion rate:** 80% of users complete all 3 steps
- **Support tickets:** Reduce "How do I get started?" tickets from 350/month to 175/month

### Guardrail Metrics
- **Sign-up conversion rate:** Maintain at 10% (don't add friction to signup)

フェーズ6の成果物

• 主要指標： 最適化の対象
• 副次指標： 追加の成功指標
• ガードレール指標： 悪化させてはいけない指標

---

フェーズ7：ユーザーストーリーと要件（90～120分）

目標： ソリューションを、受け入れ条件を含むユーザーストーリーに分解します。

アクティビティ

1. エピックの仮説を書く

• 使用するもの： skills/epic-hypothesis/SKILL.md（コンポーネント）
• 参加者： PM
• 所要時間： 30分
• 成果物： エピックの仮説文

例：

「非技術系ユーザー向けのガイド付きオンボーディングチェックリストを追加すれば、アクティベーション率が40％から60％に上がると考えています。現在、ユーザーはガイダンスが不足しているため途中で離脱しているからです。リリースから30日後のアクティベーション率で成功を測定します。」

2. エピックをユーザーストーリーに分解する

• 使用するもの： skills/epic-breakdown-advisor/SKILL.md（リチャード・ローレンスの9つのパターンを用いたインタラクティブなツール）
• 参加者： PM、デザイン、エンジニアリング
• 所要時間： 90分
• 成果物： パターン（ワークフロー、CRUD、ビジネスルールなど）ごとに分解されたユーザーストーリー

3. ユーザーストーリーを書く

• 使用するもの： skills/user-story/SKILL.md（コンポーネント）
• 参加者： PM
• 所要時間： ストーリーごとに30分
• 形式： ユーザーストーリー＋受け入れ基準

ユーザーストーリーの例：

## 7. User Stories & Requirements

### Epic Hypothesis
We believe that adding a guided onboarding checklist for non-technical users will increase activation rate from 40% to 60% because users currently drop off due to lack of guidance.

### User Stories

**Story 1: Display onboarding checklist on first login**
As a new user, I want to see a guided checklist when I first log in, so I know what to do first.

**Acceptance Criteria:**
- [ ] When user logs in for the first time, modal appears with checklist
- [ ] Checklist shows 3 steps: "Create project," "Invite teammate," "Complete task"
- [ ] Modal is dismissible (close button)
- [ ] If dismissed, checklist doesn't reappear (user preference saved)

**Story 2: Track checklist progress**
As a new user, I want to see my progress as I complete checklist steps, so I feel a sense of accomplishment.

**Acceptance Criteria:**
- [ ] When user completes step 1, checkmark appears next to "Create project"
- [ ] Progress bar updates (1/3 → 2/3 → 3/3)
- [ ] Checklist persists across sessions (if user logs out and back in)

**Story 3: Celebrate checklist completion**
As a new user, I want to receive positive feedback when I complete the checklist, so I feel confident using the product.

**Acceptance Criteria:**
- [ ] When user completes all 3 steps, celebration modal appears
- [ ] Message: "You're all set! Here's what to do next: [suggested next actions]"
- [ ] Confetti animation (optional, nice-to-have)

4. 制約とエッジケースを記録する

• 技術的制約： プラットフォームの制限、ブラウザーのサポートなど
• エッジケース： ユーザーがステップ2をスキップした場合はどうなるか？ステップを順不同で完了した場合はどうなるか？

フェーズ7の成果物

• エピックの仮説： 検証可能な文
• ユーザーストーリー： 受け入れ基準を含む3～10件のストーリー
• 制約： 技術的制限、エッジケース

---

フェーズ8：対象外項目と依存関係（30分）

目標： 開発しないものと依存するものを定義します。

アクティビティ

1. 対象外項目を記録する

• 形式： 対象外とする機能や要望を明記したリスト
• 理由： なぜ今は開発しないのか？

例：

## 8. Out of Scope

**Not included in this release:**
- **Advanced onboarding personalization** (e.g., different checklists per persona) — Adds complexity, test simple version first
- **Video tutorials embedded in checklist** — Resource-intensive, validate checklist concept first
- **Gamification (badges, points)** — Nice-to-have, focus on core workflow guidance

**Future consideration:**
- Mobile-optimized onboarding (desktop-first for now)

2. 依存関係を記録する

• 技術的依存関係： 必要なプラットフォームのアップグレード、API の変更
• 外部依存関係： サードパーティとの連携、パートナーシップ
• チーム間の依存関係： デザインの引き継ぎ、データパイプラインの作業

例：

## 9. Dependencies & Risks

### Dependencies
- **Design:** Wireframes for checklist UI (ETA: Week 1)
- **Engineering:** No technical dependencies (uses existing modals framework)

### Risks & Mitigations
- **Risk:** Users dismiss checklist immediately, never see it
  - **Mitigation:** Track dismissal rate; if >50%, iterate on messaging or timing
- **Risk:** Checklist steps are too generic, don't resonate with all personas
  - **Mitigation:** Start with primary persona (Solo Entrepreneur Sam), personalize later

3. 未解決の質問を記録する

• 未解決の決定事項： 調査や議論が必要な領域

例：

## 10. Open Questions

- Should checklist be mandatory or optional? (Decision: Optional, dismissible)
- Should we A/B test checklist vs. no checklist? (Decision: Yes, show to 50% of new users)
- What happens if user completes steps out of order? (Decision: Allow any order, update checklist dynamically)

フェーズ8の成果物

• 対象外項目： 開発しないもの
• 依存関係： 着手前に必要なもの
• リスク： 想定される障害要因と軽減策
• 未解決の質問： 未解決の決定事項

---

ワークフロー全体：エンドツーエンドの概要

Day 1:
├─ Phase 1: Executive Summary (30 min)
├─ Phase 2: Problem Statement (60 min)
│  └─ Use: skills/problem-statement/SKILL.md
├─ Phase 3: Target Users & Personas (30 min)
│  └─ Use: skills/proto-persona/SKILL.md
└─ Phase 4: Strategic Context (45 min)
   └─ Use: skills/tam-sam-som-calculator/SKILL.md (optional)

Day 2:
├─ Phase 5: Solution Overview (60 min)
│  └─ Use: skills/user-story-mapping-workshop/SKILL.md (optional)
├─ Phase 6: Success Metrics (30 min)
└─ Phase 7: User Stories & Requirements (90-120 min)
   ├─ Use: skills/epic-hypothesis/SKILL.md
   ├─ Use: skills/epic-breakdown-advisor/SKILL.md
   └─ Use: skills/user-story/SKILL.md

Day 3:
├─ Phase 8: Out of Scope & Dependencies (30 min)
└─ Review & Refine (60 min)
   └─ Read full PRD, polish, get feedback

Day 4 (Optional):
└─ Stakeholder Review & Approval
   └─ Present PRD to stakeholders, incorporate feedback

所要時間の合計：

• 短縮コース： 1.5～2日（単純な機能で、要件が明確な場合）
• 標準： 2～3日（ディスカバリーの統合、ステークホルダーによるレビューを含む）
• 複雑なケース： 3～4日（大規模な取り組み、複数のペルソナ、幅広いユーザーストーリー）

---

例

PRD の全体例については、examples/sample.md をご覧ください。

ミニ例の抜粋：

## 2. Problem Statement
- 60% of trial users drop off in first 24 hours
## 6. Success Metrics
- Activation rate: 40% → 60%

よくある落とし穴

落とし穴1：PRDを単独で作成する

症状： PM が PRD を一人で書き上げ、完成した文書をチームに提示する

結果： 賛同が得られず、チームが根拠を理解できない

対策： フェーズ7（ユーザーストーリー）でデザインとエンジニアリングのメンバーと協力し、最終化する前にPRDのドラフトをレビューする

---

落とし穴2：問題の記述に根拠がない

症状： 「ユーザーはこの問題を抱えていると考えています」（データも引用もない）

結果： チームが、問題が実在するのか疑問に思う

対策： skills/discovery-process/SKILL.md のディスカバリーで得た知見を活用し、顧客の引用、分析データ、サポートチケットを含める

---

落とし穴3：ソリューションを細かく指定しすぎる

症状： PRD で正確な UI、ピクセル単位の寸法、ボタンの色まで指定する

結果： デザインとの協業が妨げられ、ウォーターフォール型の仕様書になる

対策： フェーズ5は大まかな内容にとどめ、UIの詳細はデザインチームに任せる

---

落とし穴4：成功指標がない

症状： PRD で問題とソリューションを定義しているが、指標がない

結果： 機能が成功したか検証できない

対策： フェーズ6で必ず主要指標（最適化の対象）を定義する

---

落とし穴5：対象外項目を記録していない

症状： 開発しないものについてのセクションがない

結果： スコープが膨らみ、ステークホルダーが予定にない機能を期待する

対策： フェーズ8で対象外項目を明記する

---

参考資料

関連スキル（このワークフローで連携）

フェーズ 2：

• skills/problem-statement/SKILL.md（コンポーネント）
• skills/problem-framing-canvas/SKILL.md（インタラクティブ、コンテキスト用）
• skills/customer-journey-mapping-workshop/SKILL.md（インタラクティブ、任意）

フェーズ 3：

• skills/proto-persona/SKILL.md（コンポーネント）
• skills/jobs-to-be-done/SKILL.md（コンポーネント、任意）

フェーズ 4：

• skills/tam-sam-som-calculator/SKILL.md（インタラクティブ、任意）

フェーズ 5：

• skills/user-story-mapping-workshop/SKILL.md（インタラクティブ、任意）

フェーズ 7：

• skills/epic-hypothesis/SKILL.md（コンポーネント）
• skills/epic-breakdown-advisor/SKILL.md（インタラクティブ）
• skills/user-story/SKILL.md（コンポーネント）

外部フレームワーク

• Martin Eriksson, "How to Write a Good PRD"（2012）— PRD の構成
• Marty Cagan, Inspired（2017）— プロダクト仕様の原則
• Amazon, "Working Backwards"（PR/FAQ 形式）— PRD に代わる方法

Dean の取り組み

• [Dean に PRD テンプレートがあれば、ここにリンクを記載]

---

スキルの種類： ワークフロー 推奨ファイル名： prd-development.md 推奨配置場所： /skills/workflows/ 依存関係： 8 つのフェーズにわたる 8 つ以上のコンポーネントスキルおよびインタラクティブスキルを連携します