yuxuanhui
91861565bb
- Introduced API guidelines for interface contracts and request handling. - Added design tokens usage guidelines for consistent styling across the project. - Established DTO guidelines for defining request parameters and response data types. - Created frontend structure guidelines to clarify directory organization and code placement rules. - Compiled a comprehensive frontend development guideline document covering various aspects of the development process. - Implemented quality guidelines to ensure code maintainability and adherence to best practices.
41 lines
1.1 KiB
Markdown
41 lines
1.1 KiB
Markdown
---
|
|
name: pm-requirement-review
|
|
description: Review raw user or business requirements from a PM perspective. Use when Codex needs to assess whether an intake or user requirement is clear, valuable, scoped, testable, and ready for refinement into requirement analysis and scenario analysis.
|
|
---
|
|
|
|
# PM Requirement Review
|
|
|
|
Review the input as a PM before refinement.
|
|
|
|
## Inputs
|
|
|
|
- Intake document or raw user request.
|
|
- Existing UR, RA, or SA if available.
|
|
|
|
## Process
|
|
|
|
1. Identify the target user, business goal, and triggering problem.
|
|
2. Check whether the requested outcome is measurable.
|
|
3. Separate in-scope, out-of-scope, and unknown items.
|
|
4. Identify missing context, ambiguous terms, hidden assumptions, and decision points.
|
|
5. Check whether acceptance direction can be verified.
|
|
|
|
## Output
|
|
|
|
Produce a review note with:
|
|
|
|
- Summary.
|
|
- Confirmed facts.
|
|
- Ambiguities.
|
|
- Missing information.
|
|
- Scope risks.
|
|
- Scenario gaps.
|
|
- Recommended next questions.
|
|
- Gate decision: `pass`, `pass-with-questions`, or `rework`.
|
|
|
|
## Constraints
|
|
|
|
- Do not invent business facts.
|
|
- Mark assumptions explicitly.
|
|
- Prefer concrete questions over broad advice.
|