prd-development

目的

プロダクトマネージャーが、課題の明確化、ユーザー調査の統合、ソリューションの定義、成功基準の設定を調整し、一貫性のあるドキュメントにまとめながら、構成化された PRD（製品要求仕様書）を作成できるようにします。散在するメモや Slack のスレッドを、関係者の認識をそろえ、エンジニアリングに必要な背景を示し、信頼できる唯一の情報源となる、明確で包括的な PRD にまとめる際に活用してください。曖昧さ、スコープの肥大化、「頭の中にあるものをそのまま作る」という落とし穴を避けられます。

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

主要な概念

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 を使用してください）

---

ファシリテーションの手順

このワークフローを対話形式で進める場合は、次の手順に従ってください。

• 最初に一行で概要を伝え、次に進め方として ガイド形式（一度に質問を1つ）、コンテキストの一括提示（ユーザーが最初にすべてを貼り付ける）、または 最善の推測（トピックだけをもとに進める）を提示します。
• 平易な言葉で、1ターンにつき質問を1つします。次の質問をする前に回答を待ちます。複数の質問をまとめてはいけません。
• 質問ごとに進捗を示します（例：Context Qx/8 や Scoring Qx/5）。
• 各質問には、番号付きの回答選択肢と推奨するデフォルトを提示します。有用な場合は Other (specify) も含めます。
• 中断にも柔軟に対応し、一時停止と再開を可能にします。
• 意思決定の場面では、単一の見解ではなく、番号付きの推奨案を提示します。

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

適用方法

入力する構成全体については template.md を使用してください。

このワークフローでは、複数のコンポーネントスキルと対話型スキルを使い、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 の成果物
• ジョブ理論（Jobs-to-be-done）： 動機が重要な場合
• 使用： 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、戦略メモ、ロードマップ
• 形式： 機能をビジネス成果に結び付けます
• 例：

  「この取り組みは、第1四半期の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のレビュー
• 例：

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

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

• 理由： なぜ後ではなく今、優先するのでしょうか？
• 例：

  「第4四半期にチャーンが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（インタラクティブ形式。Richard Lawrenceの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 日（大規模な取り組み、複数のペルソナ、広範なユーザーストーリーがある場合）

---

Notion MCP（任意）

フェーズ 8 を完了し、完全な PRD をチャットに出力した後、notion-query-data-sources を実行してください。結果が返されれば、Notion に接続されています。保存手順を実行してください。失敗する場合や利用できない場合は、スキップしてアラートを追記してください。

Notion に接続されている場合：

PRD は共同で更新していくドキュメントであり、Notion はその保管場所として最適です。チーム全体が閲覧、コメント、進捗管理できるよう、完全な PRD を保存してください。

1. notion-search を呼び出し、ワークスペースに既存の Product Specs または PRDs データベースがあるか検索します
2. 見つかった場合：notion-create-pages を呼び出し、そのデータベースに新しいページとして PRD を保存します。プロパティは Name、Status（選択肢：Draft / In Review / Approved / Shipped）、Owner（人物）、Launch Date（日付）、Epic（リッチテキスト）とします
3. 見つからない場合：notion-create-database を呼び出し、これらのプロパティを含む Product Specs データベースを初期化してから、notion-create-pages を呼び出して保存します
4. notion-get-users を呼び出し、オーナー名に対応するワークスペースユーザーを特定して、Owner プロパティに割り当てます
5. 8 つのフェーズにわたって改訂する場合：重複を作成せず、既存の PRD ページを更新するために notion-update-page を呼び出します。Name で照合してください
6. 次のように確認します：「✅ PRD を Notion に保存しました → [ページタイトル]。ステータス：Draft。レビュアーは Notion で直接割り当ててください。」

接続されていない場合：

💡 Notion に接続されていません — PRD はチャットにのみ出力されます。Notion MCP コネクターを接続すると、チームがコメントや進捗管理を行える共有の製品仕様データベースに PRD が自動保存されます。セットアップ：notion-mcp-server

---

例

完全な 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、「優れた PRD の書き方」（2012）— PRD の構成
• Marty Cagan、『Inspired』（2017）— プロダクト仕様の原則
• Amazon、「Working Backwards」（PR/FAQ 形式）— PRD の代替 依存関係： 8 つのフェーズにわたって、8 つ以上のコンポーネントスキルおよびインタラクティブスキルをオーケストレーションします