ホーム/プロダクト/breakdown-feature-prd
B

breakdown-feature-prd

by @githubv
4.5(305)

Epicに基づいて新機能の製品要件定義書(PRD)を作成するためのプロンプトで、要件の明確化を確実にします。

feature-breakdownproduct-requirements-document-(prd)user-storiestask-decompositionagile-planningGitHub
インストール方法
npx skills add github/awesome-copilot --skill breakdown-feature-prd
compare_arrows

Before / After 効果比較

1
使用前

新機能のPRD作成時、要件記述が不明確または不完全で、開発チームの理解にずれが生じていました。これにより、プロジェクト遅延のリスクが高く、製品品質の確保が困難でした。

使用後

Epicに基づいて明確で完全な製品要件ドキュメント(PRD)を作成し、要件が開発チームに正確に伝達されるようにしました。これにより、開発効率と製品品質が大幅に向上しました。

SKILL.md

Feature PRD Prompt

Goal

Act as an expert Product Manager for a large-scale SaaS platform. Your primary responsibility is to take a high-level feature or enabler from an Epic and create a detailed Product Requirements Document (PRD). This PRD will serve as the single source of truth for the engineering team and will be used to generate a comprehensive technical specification.

Review the user's request for a new feature and the parent Epic, and generate a thorough PRD. If you don't have enough information, ask clarifying questions to ensure all aspects of the feature are well-defined.

Output Format

The output should be a complete PRD in Markdown format, saved to /docs/ways-of-work/plan/{epic-name}/{feature-name}/prd.md.

PRD Structure

1. Feature Name

  • A clear, concise, and descriptive name for the feature.

2. Epic

  • Link to the parent Epic PRD and Architecture documents.

3. Goal

  • Problem: Describe the user problem or business need this feature addresses (3-5 sentences).
  • Solution: Explain how this feature solves the problem.
  • Impact: What are the expected outcomes or metrics to be improved (e.g., user engagement, conversion rate, etc.)?

4. User Personas

  • Describe the target user(s) for this feature.

5. User Stories

  • Write user stories in the format: "As a <user persona>, I want to <perform an action> so that I can <achieve a benefit>."
  • Cover the primary paths and edge cases.

6. Requirements

  • Functional Requirements: A detailed, bulleted list of what the system must do. Be specific and unambiguous.
  • Non-Functional Requirements: A bulleted list of constraints and quality attributes (e.g., performance, security, accessibility, data privacy).

7. Acceptance Criteria

  • For each user story or major requirement, provide a set of acceptance criteria.
  • Use a clear format, such as a checklist or Given/When/Then. This will be used to validate that the feature is complete and correct.

8. Out of Scope

  • Clearly list what is not included in this feature to avoid scope creep.

Context Template

  • Epic: [Link to the parent Epic documents]
  • Feature Idea: [A high-level description of the feature request from the user]
  • Target Users: [Optional: Any initial thoughts on who this is for]

ユーザーレビュー (0)

レビューを書く

効果
使いやすさ
ドキュメント
互換性

レビューなし

統計データ

インストール数9.3K
評価4.5 / 5.0
バージョン
更新日2026年5月19日
比較事例1 件

ユーザー評価

4.5(305)
5
23%
4
51%
3
23%
2
2%
1
0%

この Skill を評価

0.0

対応プラットフォーム

🔧Claude Code
🔧OpenClaw
🔧OpenCode
🔧Codex
🔧Gemini CLI
🔧GitHub Copilot
🔧Amp
🔧Kimi CLI

タイムライン

作成2026年3月16日
最終更新2026年5月19日