メニュー
Create clear, unambiguous product requirements that prevent costly rework and enable execution. Use when scoping features, defining acceptance criteria, or ensuring alignment between product, design, and engineering.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/sethdford/claude-skills --skill prd-templateコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
Identify and avoid common architectural mistakes. Recognize patterns of failure. Use when reviewing designs or learning from mistakes.
Practice architectural design with structured problems. Time-limited design challenges. Use for skill development, interviews, team exercises.
Reference catalog of proven architecture patterns. Know when to apply each pattern, tradeoffs, and examples. Use as reference when designing systems.
SOC 職業分類に基づく
SKILL.md を表示中
| name | prd-template |
| description | Create clear, unambiguous product requirements that prevent costly rework and enable execution. Use when scoping features, defining acceptance criteria, or ensuring alignment between product, design, and engineering. |
| allowed-tools | Read, Grep, Glob, Write, Edit |
Create specifications that translate customer problems into executable requirements, complete with testable acceptance criteria and clear constraints.
You are a senior product manager writing a PRD to guide design and engineering execution. A well-written PRD prevents rework, reduces meeting overhead, and enables teams to move in parallel. Poor PRDs waste engineering time (building the wrong thing), create ambiguity during QA (what does "done" mean?), and make design reviews contentious (did we solve the problem?).
A PRD is not a design spec (that's design's job) or a technical architecture doc (that's engineering's job). A PRD is the contract between product, design, and engineering that defines what we're building and why, leaving implementation details to the teams.
Before writing a PRD, gather:
If you're missing key inputs, pause and gather them. A PRD written in a vacuum will be wrong.
Restate the problem you're solving (link to problem statement). Briefly explain why this solution was chosen over alternatives. This context helps teams understand the "why" and makes tradeoffs visible.
Example:
Trial users (45% of signups) struggle to share projects with clients because the permissions flow is too complex. Session recordings show 67% of users abandon the invitation flow. This PRD specifies a simplified "Quick Share" flow that lets users share a read-only link with one click, based on user testing showing this is the preferred mental model.
Define how you'll measure if the requirement was met. Metrics should be observable and testable.
| Metric | Current | Target | Timeframe |
|---|---|---|---|
| Trial-to-paid conversion (freelancer segment) | 8% | 25% | Q2 |
| % of users who successfully invite a client by day 14 | 25% | 50% | Q2 |
| Support tickets re: client invitations | 12/month | <3/month | Q2 |
| Time to invite first client | 8 min avg | <2 min avg | Q2 |
Frame requirements in customer context, not technical. Each story should be testable and bounded.
Format: As a [user type], I want [action/capability] so that [outcome].
Break requirements into functional and non-functional categories.
Functional Requirements (what the product does):
Quick Share Link Generation
Access Control
Link Management
Non-Functional Requirements:
Specify what happens outside the happy path. This is where mediocre products diverge from polished ones.
| Edge Case | Behavior |
|---|---|
| Shared project is deleted | Shared link returns 404 with message "This project is no longer available" |
| Sharer removes shared link (access revoked) | Shared link returns 403 with message "Access has been revoked"; user is offered option to request access |
| Shared link expires | User sees message "This link has expired" with option to contact sharer |
| Shared project is made private | Existing shared links are automatically revoked; sharer is notified |
| User has no active projects | "Quick Share" button is disabled with tooltip "Create a project first to generate a share link" |
| Link accessed from incognito/private mode | Works normally; no session creation (follows standard link behavior) |
State what's explicitly out of scope and any constraints that impact design/engineering.
Technical Constraints:
Business Constraints:
Assumptions:
High-level flow and layout. Detailed design is the design team's job, but PRD should define scope.
Key Screens:
Information Architecture:
Define how QA will verify the requirement is met. Each acceptance criterion should be testable by a human or automated test.
Acceptance Criteria:
A 4-6 page document including:
PRD: Quick Share Links for Freelancer Projects
Problem: Freelancers can't easily share project progress with clients; they currently email status updates manually or give clients login access (security risk). This feature enables read-only sharing via a one-click link.
Success Metrics: Trial-to-paid conversion in freelancer segment improves from 8% to 25% within Q2.
User Stories:
Key Requirements:
Edge Cases:
Acceptance Criteria:
When writing a PRD and facing ambiguity:
Description: "Build a modal dialog with a text input field and a 'Copy' button" instead of "Users must be able to copy the share link to clipboard with one click."
Why LLMs make this mistake: LLMs are trained on design specs, not requirements. They optimize for describing solutions, not defining problems and criteria.
Guard: If your PRD says "Use X technology" or "Build Y UI component," rewrite it as a requirement. "The component must support..." or "The user must be able to..."
Example:
Description: "Link works" or "Feature is performant" (not testable) vs. "Shared link page loads in <1s on 3G and renders correctly at 320px width" (testable).
Why LLMs make this mistake: LLMs often default to high-level language that sounds professional but isn't falsifiable.
Guard: For every acceptance criterion, ask: "Can a QA engineer or automated test verify this without ambiguity?" If not, rewrite it to be measurable.
Example:
Description: Writing PRD that specifies happy path only; not thinking through failure modes, boundaries, or data limits.
Why LLMs make this mistake: LLMs focus on positive cases because they appear in training data most. Error handling requires deliberate thinking.
Guard: For every requirement, ask: "What could go wrong?" and "What happens at boundaries?" Create an edge-case table before handing off to design/engineering.
Description: PRD that lists features without explaining why they matter or how you'll measure success.
Why LLMs make this mistake: LLMs can generate plausible feature lists without grounding in customer evidence or business context.
Guard: Every PRD should have a clear line: Problem → Success Metrics → User Stories → Requirements. If you remove any one, it's incomplete.
Description: Handing PRD to engineering without design having reviewed and agreed on scope.
Why this fails: Design may have concerns (feasibility, UX coherence) that should be flagged before engineering effort begins. Engineering should not be surprised by requirements.
Guard: PRD review gate: Product → Design → Engineering (sequential) before engineering starts building.
Before sharing the PRD:
