create-prd
新規プロジェクトや既存システム改修において、市場分析、機能定義、成功指標を盛り込み、製品アイデアを詳細な製品要求仕様書(PRD)としてまとめ上げるSkill。
📜 元の英語説明(参考)
Create comprehensive Product Requirements Documents (PRD) from high-level product ideas with structured market analysis, feature definition, and success metrics for both greenfield and brownfield contexts. Use when defining product vision for new projects (greenfield) or formalizing requirements for existing systems (brownfield).
🇯🇵 日本人クリエイター向け解説
新規プロジェクトや既存システム改修において、市場分析、機能定義、成功指標を盛り込み、製品アイデアを詳細な製品要求仕様書(PRD)としてまとめ上げるSkill。
※ jpskill.com 編集部が日本のビジネス現場向けに補足した解説です。Skill本体の挙動とは独立した参考情報です。
下記のコマンドをコピーしてターミナル(Mac/Linux)または PowerShell(Windows)に貼り付けてください。 ダウンロード → 解凍 → 配置まで全自動。
mkdir -p ~/.claude/skills && cd ~/.claude/skills && curl -L -o create-prd.zip https://jpskill.com/download/9704.zip && unzip -o create-prd.zip && rm create-prd.zip
$d = "$env:USERPROFILE\.claude\skills"; ni -Force -ItemType Directory $d | Out-Null; iwr https://jpskill.com/download/9704.zip -OutFile "$d\create-prd.zip"; Expand-Archive "$d\create-prd.zip" -DestinationPath $d -Force; ri "$d\create-prd.zip"
完了後、Claude Code を再起動 → 普通に「動画プロンプト作って」のように話しかけるだけで自動発動します。
💾 手動でダウンロードしたい(コマンドが難しい人向け)
- 1. 下の青いボタンを押して
create-prd.zipをダウンロード - 2. ZIPファイルをダブルクリックで解凍 →
create-prdフォルダができる - 3. そのフォルダを
C:\Users\あなたの名前\.claude\skills\(Win)または~/.claude/skills/(Mac)へ移動 - 4. Claude Code を再起動
⚠️ ダウンロード・利用は自己責任でお願いします。当サイトは内容・動作・安全性について責任を負いません。
🎯 このSkillでできること
下記の説明文を読むと、このSkillがあなたに何をしてくれるかが分かります。Claudeにこの分野の依頼をすると、自動で発動します。
📦 インストール方法 (3ステップ)
- 1. 上の「ダウンロード」ボタンを押して .skill ファイルを取得
- 2. ファイル名の拡張子を .skill から .zip に変えて展開(macは自動展開可)
- 3. 展開してできたフォルダを、ホームフォルダの
.claude/skills/に置く- · macOS / Linux:
~/.claude/skills/ - · Windows:
%USERPROFILE%\.claude\skills\
- · macOS / Linux:
Claude Code を再起動すれば完了。「このSkillを使って…」と話しかけなくても、関連する依頼で自動的に呼び出されます。
詳しい使い方ガイドを見る →- 最終更新
- 2026-05-18
- 取得日時
- 2026-05-18
- 同梱ファイル
- 1
📖 Skill本文(日本語訳)
※ 原文(英語/中国語)を Gemini で日本語化したものです。Claude 自身は原文を読みます。誤訳がある場合は原文をご確認ください。
Create PRD Skill
目的
高レベルの製品アイデアから包括的な Product Requirements Documents (PRD) を作成します。このスキルは、体系的な要件収集、市場分析、機能定義、および成功指標のドキュメント化をガイドし、アーキテクチャ設計またはエピックの分解に対応できる PRD を作成します。
コア原則:
- 構造化された要件の引き出し
- 市場主導の機能の優先順位付け
- 明確な成功指標と KPI
- ユーザー中心の設計アプローチ
- グリーンフィールド (新規製品) とブラウンフィールド (既存システム) の両方のコンテキストをサポート
前提条件
- 製品ビジョンまたは初期コンセプトが定義されていること
- ステークホルダーからのインプットへのアクセス (利用可能な場合)
- ターゲット市場とユーザーの理解
- PRD ストレージ用の workspace/ ディレクトリが存在すること
ワークフロー
ステップ 1: 要件収集
アクション: 構造化された問い合わせを通じて、製品ビジョン、目標、および制約を引き出します。
主要な活動:
-
製品ビジョンと価値提案
- これはどのような問題を解決しますか?
- ユーザーにどのような価値を提供しますか?
- 何がユニークまたは異なりますか?
-
ターゲットユーザーとペルソナ
- 主なユーザーは誰ですか?
- 彼らの目標、ニーズ、課題は何ですか?
- どのようなユーザーセグメントが存在しますか?
-
ビジネス目標
- ビジネス目標は何ですか?
- これは戦略とどのように一致しますか?
- 予想される ROI または影響は何ですか?
-
制約と考慮事項
- タイムラインの制約
- 予算の制限
- 技術的な制約
- 法規制の要件
- チームの能力
質問例:
- "ユーザーのためにどのような問題を解決していますか?"
- "ユーザーはどのようにこれを発見し、アクセスしますか?"
- "6か月後の成功はどのように見えますか?"
- "明示的に構築しないものは何ですか?"
出力: コア要件のドキュメント化 (ビジョン、ユーザー、目標、制約)
参照: 包括的な引き出し手法については、references/elicitation-guide.md を参照してください。
ステップ 2: 市場分析
アクション: 競合状況と市場ポジショニングを分析します。
主要な活動:
-
競合状況
- 直接的な競合他社は誰ですか?
- 間接的な競合他社または代替手段は誰ですか?
- 彼らの強み/弱みは何ですか?
-
市場ポジショニング
- どのように差別化しますか?
- 私たちのユニークな価値提案は何ですか?
- どの市場セグメントをターゲットにしますか?
-
市場参入の考慮事項
- 流通チャネル
- 価格戦略 (該当する場合)
- マーケティングアプローチ
- 発売戦略
-
市場トレンド
- 関連する業界トレンド
- 技術トレンド
- ユーザー行動トレンド
分析例:
競合状況:
- 直接: [Competitor A] (強み: エンタープライズ機能、弱み: UX が貧弱)
- 間接: [Alternative B] (ユーザーは代わりにスプレッドシートを使用)
差別化:
- シンプルで直感的な UX (競合他社の複雑さに対して)
- モバイルファーストのデザイン (デスクトップのみの競合他社に対して)
- AI 搭載の自動化 (独自の機能)
出力: PRD の市場分析セクション
参照: 詳細なフレームワークについては、references/market-analysis-template.md を参照してください。
ステップ 3: 機能定義
アクション: MoSCoW 法を使用して機能を定義し、優先順位を付けます。
主要な活動:
-
コア機能の特定
- 製品は何をしなければなりませんか? (Must-haves)
- 何をすべきですか? (Should-haves)
- 何ができますか? (Could-haves)
- 何をしませんか? (Won't-haves)
-
機能仕様
- 各機能の簡単な説明
- ユーザーの価値/メリット
- 機能間の依存関係
- 技術的な複雑さの見積もり (既知の場合)
-
MoSCoW の優先順位付け
- Must Have: 重要な機能、MVP ブロッカー
- Should Have: 重要ですが、ローンチブロッカーではありません
- Could Have: あると便利なもの、将来の拡張機能
- Won't Have: 明示的に範囲外
-
機能の検証
- 各機能はユーザーの問題を解決しますか?
- 各機能は目標と一致していますか?
- Must-haves は制約内で達成可能ですか?
機能定義の例:
MUST HAVE (MVP):
1. ユーザー登録とログイン
- ユーザーはメール/パスワードでアカウントを作成できます
- パーソナライズとデータセキュリティを有効にします
- 依存関係: データベース、認証サービス
2. ダッシュボードの概要
- ユーザーは主要な指標を一目で確認できます
- ログイン時に即時の価値を提供します
- 依存関係: データ収集、視覚化
SHOULD HAVE:
3. 高度なフィルタリング
- ユーザーは複数の条件でデータをフィルタリングできます
- データ検出を改善します
- 依存関係: ダッシュボード、検索インフラストラクチャ
COULD HAVE:
4. データエクスポート (CSV, PDF)
- ユーザーはレポートをエクスポートできます
- 利便性機能、コアバリューではありません
- 依存関係: ダッシュボード、レポート生成
WON'T HAVE (v1):
5. リアルタイムコラボレーション
- v1 の範囲外、v2 で計画
- 非常に複雑な技術
出力: 仕様を含む優先順位付けされた機能リスト
参照: 詳細な優先順位付けフレームワークについては、references/moscow-prioritization-guide.md を参照してください。
ステップ 4: 成功指標
アクション: 測定可能な成功基準と KPI を定義します。
主要な活動:
-
ユーザー導入指標
- サインアップ、アクティブユーザー (DAU/MAU/WAU)
- ユーザーリテンション (D1, D7, D30 リテンション)
- ユーザーエンゲージメント (セッション、サイト滞在時間)
- 機能の導入率
-
ビジネスインパクト指標
- 収益 (該当する場合)
- コンバージョン率
- コスト削減
- 市場シェア
- 顧客満足度 (NPS, CSAT)
-
技術パフォーマンス指標
- ページロード時間
- API 応答時間
- アップタイム/可用性
- エラー率
- スケーラビリティ指標
-
成功基準
- 各指標の具体的な目標
- 達成までの期間
- 指標の測定方法
- ベースライン値と目標値
成功指標の例:
USER ADOPTION:
- 最初の月に 1,000 件のサインアップ
- 60% の D7 リテンション
- 40% の MAU エンゲージメント
BUSINESS IMPACT:
- 70% のコンバージョン率 (無料 → 有料)
- NPS スコア >40
- 6 か月までに $100K ARR
TECHNICAL PERFORMANCE:
- <2 秒のページロード時間 (p95)
- 99.9% のアップタイム SLA
- <1% のエラー率
出力: 成功
📜 原文 SKILL.md(Claudeが読む英語/中国語)を展開
Create PRD Skill
Purpose
Create comprehensive Product Requirements Documents (PRD) from high-level product ideas. This skill guides systematic requirements gathering, market analysis, feature definition, and success metrics documentation to produce PRDs ready for architecture design or epic breakdown.
Core Principles:
- Structured requirements elicitation
- Market-driven feature prioritization
- Clear success metrics and KPIs
- User-centric design approach
- Supports both greenfield (new products) and brownfield (existing systems) contexts
Prerequisites
- Product vision or initial concept defined
- Access to stakeholder input (if available)
- Understanding of target market and users
- workspace/ directory exists for PRD storage
Workflow
Step 1: Requirements Gathering
Action: Elicit product vision, objectives, and constraints through structured inquiry.
Key Activities:
-
Product Vision & Value Proposition
- What problem does this solve?
- What value does it provide to users?
- What makes it unique or different?
-
Target Users & Personas
- Who are the primary users?
- What are their goals, needs, pain points?
- What user segments exist?
-
Business Objectives
- What are the business goals?
- How does this align with strategy?
- What's the expected ROI or impact?
-
Constraints & Considerations
- Timeline constraints
- Budget limitations
- Technical constraints
- Regulatory requirements
- Team capabilities
Example Questions:
- "What problem are we solving for users?"
- "How will users discover and access this?"
- "What success looks like in 6 months?"
- "What are we explicitly NOT building?"
Output: Core requirements documented (vision, users, objectives, constraints)
See: references/elicitation-guide.md for comprehensive elicitation techniques
Step 2: Market Analysis
Action: Analyze competitive landscape and market positioning.
Key Activities:
-
Competitive Landscape
- Who are the direct competitors?
- Who are indirect competitors or alternatives?
- What are their strengths/weaknesses?
-
Market Positioning
- How do we differentiate?
- What's our unique value proposition?
- What market segment do we target?
-
Go-to-Market Considerations
- Distribution channels
- Pricing strategy (if applicable)
- Marketing approach
- Launch strategy
-
Market Trends
- Relevant industry trends
- Technology trends
- User behavior trends
Example Analysis:
Competitive Landscape:
- Direct: [Competitor A] (strength: enterprise features, weakness: poor UX)
- Indirect: [Alternative B] (users use spreadsheets instead)
Differentiation:
- Simple, intuitive UX (vs competitor complexity)
- Mobile-first design (vs desktop-only competitors)
- AI-powered automation (unique capability)
Output: Market analysis section for PRD
See: references/market-analysis-template.md for detailed framework
Step 3: Feature Definition
Action: Define and prioritize features using MoSCoW method.
Key Activities:
-
Identify Core Features
- What must the product do? (Must-haves)
- What should it do? (Should-haves)
- What could it do? (Could-haves)
- What won't it do? (Won't-haves)
-
Feature Specifications
- Brief description of each feature
- User value/benefit
- Dependencies between features
- Technical complexity estimate (if known)
-
MoSCoW Prioritization
- Must Have: Critical features, MVP blockers
- Should Have: Important but not launch blockers
- Could Have: Nice-to-haves, future enhancements
- Won't Have: Explicitly out of scope
-
Feature Validation
- Does each feature solve user problem?
- Is each feature aligned with objectives?
- Are must-haves achievable within constraints?
Example Feature Definition:
MUST HAVE (MVP):
1. User Registration & Login
- Users can create accounts with email/password
- Enables personalization and data security
- Depends on: Database, authentication service
2. Dashboard Overview
- Users see key metrics at a glance
- Provides immediate value on login
- Depends on: Data collection, visualization
SHOULD HAVE:
3. Advanced Filtering
- Users can filter data by multiple criteria
- Improves data discovery
- Depends on: Dashboard, search infrastructure
COULD HAVE:
4. Data Export (CSV, PDF)
- Users can export reports
- Convenience feature, not core value
- Depends on: Dashboard, report generation
WON'T HAVE (v1):
5. Real-time Collaboration
- Out of scope for v1, planned for v2
- Significant technical complexity
Output: Prioritized feature list with specifications
See: references/moscow-prioritization-guide.md for detailed prioritization framework
Step 4: Success Metrics
Action: Define measurable success criteria and KPIs.
Key Activities:
-
User Adoption Metrics
- Sign-ups, active users (DAU/MAU/WAU)
- User retention (D1, D7, D30 retention)
- User engagement (sessions, time-on-site)
- Feature adoption rates
-
Business Impact Metrics
- Revenue (if applicable)
- Conversion rates
- Cost savings
- Market share
- Customer satisfaction (NPS, CSAT)
-
Technical Performance Metrics
- Page load time
- API response time
- Uptime/availability
- Error rates
- Scalability metrics
-
Success Criteria
- Specific targets for each metric
- Timeframes for achievement
- How metrics will be measured
- Baseline vs target values
Example Success Metrics:
USER ADOPTION:
- 1,000 sign-ups in first month
- 60% D7 retention
- 40% MAU engagement
BUSINESS IMPACT:
- 70% conversion rate (free → paid)
- NPS score >40
- $100K ARR by month 6
TECHNICAL PERFORMANCE:
- <2s page load time (p95)
- 99.9% uptime SLA
- <1% error rate
Output: Success metrics and KPIs documented
See: references/success-metrics-framework.md for comprehensive metrics catalog
Step 5: PRD Document Generation
Action: Compile all gathered information into comprehensive PRD document.
Document Structure:
-
Executive Summary
- Product overview (1-2 paragraphs)
- Problem statement
- Value proposition
- Target users
-
Product Vision & Objectives
- Vision statement
- Business objectives
- Success criteria
-
User Personas & Stories
- Persona definitions
- User journeys
- Key use cases
-
Market Analysis
- Competitive landscape
- Market positioning
- Differentiation strategy
-
Feature Specifications
- Prioritized feature list (MoSCoW)
- Feature descriptions and user value
- Dependencies and relationships
-
User Flows & Journeys
- Key user flows
- Entry points and conversions
- Edge cases
-
Non-Functional Requirements
- Performance requirements
- Security requirements
- Scalability requirements
- Accessibility requirements
-
Success Metrics & KPIs
- Adoption metrics
- Business impact metrics
- Technical metrics
- Success criteria with targets
-
Timeline & Milestones
- High-level roadmap
- Key milestones
- Launch criteria
-
Assumptions & Constraints
- Technical assumptions
- Business assumptions
- Known constraints
- Dependencies
-
Open Questions & Risks
- Unresolved questions
- Identified risks
- Mitigation strategies
File Location:
- Greenfield:
docs/prd.mdorworkspace/prds/{product-name}-prd.md - Brownfield:
docs/brownfield-prd.md(if updating existing system)
Validation:
- All required sections present
- Features prioritized with clear MoSCoW categories
- Success metrics specific and measurable
- Assumptions and risks documented
- Ready for next phase (architecture or epic breakdown)
Output: Complete PRD document
See: references/prd-template.md for complete PRD template with all sections
Common Scenarios
Scenario 1: Greenfield Product (New Product)
Context: Creating PRD for entirely new product with no existing system.
Approach:
- Focus on user problem and market opportunity
- Emphasize differentiation and unique value
- Start with minimal MVP features
- Plan iterative releases
See: references/greenfield-examples.md for complete examples
Scenario 2: Brownfield Product (Existing System)
Context: Creating PRD for enhancements to existing product.
Approach:
- Document current state briefly
- Focus on gaps and improvements
- Consider migration and compatibility
- Balance new features with technical debt
Note: For comprehensive brownfield PRD generation from codebase analysis, use create-brownfield-prd skill instead.
Scenario 3: Insufficient Information
Context: Stakeholders haven't provided enough detail.
Approach:
- Document known information
- Create "Assumptions" section with reasonable assumptions
- Create "Open Questions" section with specific questions
- Mark PRD as "DRAFT - Pending Stakeholder Input"
- Share with stakeholders for feedback
Scenario 4: Too Many Features
Context: Stakeholders want everything in MVP.
Approach:
- Apply strict MoSCoW prioritization
- Identify true MVP (minimum viable)
- Create phased roadmap (v1.0, v1.1, v2.0)
- Use data/evidence to defend prioritization
- Escalate if stakeholder insists on unrealistic scope
See: references/scope-management-guide.md for scope negotiation strategies
Best Practices
- Be User-Centric - Always frame features in terms of user value, not technical implementation
- Keep It Clear - Use simple language, avoid jargon, be specific and concrete
- Prioritize Ruthlessly - Not everything can be "must have"; be honest about MVP scope
- Be Data-Driven - Use market research, user feedback, and metrics to validate decisions
- Document Assumptions - Make implicit assumptions explicit to avoid misalignment later
- Stay Flexible - PRD is a living document; expect it to evolve as you learn more
- Cross-Reference - Link to other documents (architecture, task specs, user research)
- Get Feedback - Share early drafts with stakeholders for validation and buy-in
Reference Files
references/elicitation-guide.md- Techniques for gathering requirementsreferences/market-analysis-template.md- Competitive and market analysis frameworkreferences/moscow-prioritization-guide.md- Feature prioritization methodologyreferences/success-metrics-framework.md- Comprehensive metrics catalogreferences/prd-template.md- Complete PRD template with all sectionsreferences/greenfield-examples.md- Example PRDs for new productsreferences/scope-management-guide.md- Managing scope and stakeholder expectations
When to Escalate
Escalate to stakeholders when:
- Critical information missing (target users, business objectives)
- Conflicting requirements or priorities
- Unrealistic scope or timeline expectations
- Budget constraints conflict with must-have features
- Regulatory or compliance requirements unclear
Escalate to architect when:
- Technical feasibility of features uncertain
- Significant architectural decisions needed
- Integration requirements complex
Use alternative skill when:
- Existing codebase needs analysis → Use
create-brownfield-prdskill - PRD too large (>100 features) → Use
shard-documentskill after creation - Interactive validation needed → Use
interactive-checklistskill for PO review
Part of BMAD Enhanced Planning Suite