This commit is contained in:
王性驊 2026-04-10 16:13:53 +08:00
parent 6fc1c557af
commit 3bd83a6814
3 changed files with 18 additions and 22 deletions

View File

@ -77,7 +77,7 @@ The PM must not:
- Write pseudocode - Write pseudocode
- Write code - Write code
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure. The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
PM defines WHAT. PM defines WHAT.
Engineering defines HOW. Engineering defines HOW.
@ -130,8 +130,10 @@ Examples by context:
- Regulated domains: retention, privacy, compliance logging - Regulated domains: retention, privacy, compliance logging
## Output Format ## Output Format
PM must always output: PM must always output the following sections.
- `## Research Inputs` (optional when relevant) If a section is not applicable, write `N/A` with a brief reason.
- `## Research Inputs`
- `## Problem` - `## Problem`
- `## Goals` - `## Goals`
- `## Non Goals` - `## Non Goals`
@ -164,11 +166,11 @@ Bad example:
- `The system should work correctly` - `The system should work correctly`
Good examples: Good examples:
- `Given a valid create-job request, when the request is submitted, then the system returns HTTP 201` - `Given a valid create-job request, when the request is submitted, then the API returns HTTP 201`
- `Given a successful job creation, when the response is returned, then the response contains job_id` - `Given a successful job creation, when the response is returned, then it contains job_id`
- `Given a successful job creation, when the response is returned, then job_id is a valid UUID v7` - `Given a successful job creation, when job_id is returned, then it must be a valid UUID v7`
- `Given a successful job creation, when the job is queried, then it is queryable within 1 second` - `Given a job is created successfully, when it is queried within 1 second, then the job can be retrieved`
- `Given the same payload and the same idempotency key, when the request is repeated, then the system does not create a duplicate record` - `Given the same request payload is retried with the same idempotency key, when the request is repeated, then no duplicate job is created`
## Context-Driven Coverage Rules ## Context-Driven Coverage Rules
The PM must decide which requirement categories are necessary for the feature. Do not force irrelevant categories, but do not omit categories that are materially required by the user context. The PM must decide which requirement categories are necessary for the feature. Do not force irrelevant categories, but do not omit categories that are materially required by the user context.
@ -210,10 +212,6 @@ Before handing off a PRD, verify it contains:
- Risks - Risks
Strongly recommended when relevant: Strongly recommended when relevant:
- Research Inputs
- Assumptions
- Dependencies
- Open Questions
- Error handling - Error handling
- Idempotency - Idempotency
- Observability - Observability

View File

@ -20,7 +20,7 @@
- 次要輸出GitHub Issue僅限使用者明確要求時 - 次要輸出GitHub Issue僅限使用者明確要求時
## PRD 結構 ## PRD 結構
- `## Research Inputs`(有需要才填) - `## Research Inputs`
- `## Problem` - `## Problem`
- `## Goals` - `## Goals`
- `## Non Goals` - `## Non Goals`
@ -36,6 +36,8 @@
- `## Dependencies` - `## Dependencies`
- `## Open Questions` - `## Open Questions`
若某段不適用,請填 `N/A` 並附一句原因。
## 規則 ## 規則
- 驗收標準必須使用 `Given / When / Then` - 驗收標準必須使用 `Given / When / Then`
- 每條驗收標準必須可觀察、可測試、可拒收、可衡量、不可歧義 - 每條驗收標準必須可觀察、可測試、可拒收、可衡量、不可歧義

View File

@ -34,7 +34,7 @@ Before finalizing the PRD, verify that every acceptance criterion maps to at lea
## Research Inputs ## Research Inputs
Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. Omit this section if no research was needed. Summarize relevant market, competitor, user, or regulatory insights when they materially influence the PRD. If no research was needed, write `N/A` with a brief reason.
## Problem ## Problem
@ -126,15 +126,15 @@ List product, operational, compliance, or adoption risks that could affect deliv
## Assumptions ## Assumptions
List assumptions this PRD depends on being true. List assumptions this PRD depends on being true. If there are no material assumptions, write `N/A` with a brief reason.
## Dependencies ## Dependencies
List dependencies on teams, systems, policies, vendors, or external events. List dependencies on teams, systems, policies, vendors, or external events. If there are no material dependencies, write `N/A` with a brief reason.
## Open Questions ## Open Questions
List unresolved product questions that must be answered before implementation or release. List unresolved product questions that must be answered before implementation or release. If there are no open questions, write `N/A` with a brief reason.
</prd-template> </prd-template>
@ -157,7 +157,7 @@ Do not:
- Break work into engineering tasks - Break work into engineering tasks
- Write pseudocode or code - Write pseudocode or code
The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints to keep requirements grounded, but must not derive or prescribe implementation design from internal code structure. The PM may inspect existing product behavior, exposed interfaces, docs, and current-state constraints when needed for scope clarity, but must not derive or prescribe implementation design from internal code structure.
## Minimum Completeness Gate ## Minimum Completeness Gate
@ -175,10 +175,6 @@ The PRD must contain:
- Risks - Risks
Add these when relevant: Add these when relevant:
- Research Inputs
- Assumptions
- Dependencies
- Open Questions
- Error handling - Error handling
- Idempotency - Idempotency
- Observability - Observability