In many Chinese internet companies a feature does not enter development until it passes a requirements review: the product manager presents the PRD, and engineering (研发), testing (测试), design (设计) and operations (运营) challenge it. Reviews fail for predictable reasons: unclear scope, missing edge cases, no tracking plan, or a schedule nobody agreed to. This skill checks the PRD before the meeting, rehearses the questions and runs the meeting to a written conclusion.
Write in Simplified Chinese unless asked otherwise. To write the PRD itself, see prd-template.
What This Skill Produces
- A readiness check of the PRD against what reviewers look for, with gaps to fix before the meeting
- A question bank by role (研发, 测试, 设计, 运营, 数据) with answer points
- A run sheet for a 60-minute review
- Minutes (评审纪要) with the conclusion, open questions, owners and dates
Required Inputs
Ask for these if not provided:
- The PRD or a summary of it
- Who attends: which roles, and who decides
- The release target and any fixed dates
- Known disagreements or risks the PM already expects
Framework
- Readiness check (评审前自查). The PRD should cover: 背景与目标 (with a measurable goal), 用户与场景, 需求范围 (in scope and explicitly out of scope), 功能说明 (flows, states, rules), 异常与边界 (errors, empty states, permissions, limits), 数据埋点 (events and the metric each serves), 非功能需求 (performance, security, compliance), 上线计划 (gradual release, rollback) and 待定问题. Mark each present, partial or missing.
- Question bank by role.
- 研发: "这个规则的边界是什么？", "历史数据怎么处理？", "并发 / 性能要求是多少？", "依赖哪些团队的接口？"
- 测试: "异常流程有哪些？", "验收标准是什么？", "兼容哪些端和版本？"
- 设计: "交互稿覆盖了哪些状态？", "空状态和错误提示怎么写？"
- 运营 / 数据: "怎么衡量效果？", "埋点谁来验收？", "上线后多久复盘？"
- Run sheet (60 minutes). 5 min background and goal; 20 min walkthrough of flows; 20 min questions by role; 10 min scope and schedule; 5 min conclusion read back aloud.
- Conclusion. One of 通过 (enters scheduling), 有条件通过 (enters scheduling once named items are fixed by a date) or 不通过 (re-review needed), with the reason.
- Minutes the same day. Decisions, open questions with owners and dates, and any scope changes.
Output Format
Pre-review self-check
| Module | Status (complete / partial / missing) | Needs supplementing |
Anticipated question list
| Role | Question | Answer points | Materials to prepare in advance |
Review meeting agenda (60 minutes)
| Time | Segment | Owner |
Review minutes
- Conclusion: Pass / Conditionally pass / Fail (reason)
- Confirmed: [Decision]
- To be resolved: | Issue | Owner | Deadline |
- Scope changes: [Added / Removed]
- Next steps: [Scheduling, technical review, second review]
Quality Checks
- Every PRD module is marked present, partial or missing, with what to add
- The question bank covers every role attending
- Out-of-scope items are stated, not implied
- Every tracking event is tied to a metric in the goal
- The conclusion is one of the three outcomes, with a reason
- Every open question has an owner and a date
Anti-Patterns
- Reading the PRD aloud for 50 minutes. Send it a day ahead; use the meeting for questions.
- "Details to be decided later". Undefined rules become arguments in development. Name them as open questions with owners.
- No tracking plan. Without 埋点 the feature cannot be judged after launch.
- Leaving without a conclusion. A review with no written outcome will be re-argued.
Example Trigger Phrases
- "Requirements review is tomorrow, help me see what's still missing in the PRD."
- "What questions do engineering and testing usually ask? Help me prepare."
- "Prepare me for a PRD review with a Chinese engineering team."
- "Help me write the minutes for this review meeting, the conclusion is conditionally passed."