tpm-roadmap-slice

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

PRD Phase Generator

PRD阶段生成器

Extract features from a Vision PRD into a detailed Phase PRD with requirements, priorities, and traceability.

从愿景PRD中提取功能，生成包含需求、优先级和可追溯性的详细阶段PRD。

Inputs Required

所需输入

Vision PRD — Annotated with
```
[F-nnn]
```
tags (use
```
prd-vision-annotator
```
first if missing)
Coverage Index — To identify which features are
```
Planned
```
vs already assigned

愿景PRD — 需带有
```
[F-nnn]
```
标签（若缺失，请先使用
```
prd-vision-annotator
```
工具添加）
覆盖索引 — 用于区分哪些功能处于「已规划（Planned）」状态，哪些已被分配

Capacity Defaults

容量默认值

Per phase, target approximately:

10 features (F-nnn)
50 functional requirements (R-nnnn)
100 acceptance criteria (AC-nnnn)

Adjust based on user input about team size or timeline.

每个阶段的目标大致为：

10个功能（F-nnn格式）
50个功能需求（R-nnnn格式）
100个验收标准（AC-nnnn格式）

可根据用户提供的团队规模或时间线进行调整。

Workflow

工作流程

Select features — Choose ~10
```
Planned
```
features from Coverage Index
Decompose requirements — Extract R-nnnn from each feature's vision prose
Assign priorities — Must / Should / Could for each requirement
Generate Phase PRD — Using template in
```
assets/phase-prd-template.md
```
Update Coverage Index — Mark selected features as
```
In Progress
```

选择功能 — 从覆盖索引中选取约10个「已规划」的功能
拆解需求 — 从每个功能的愿景描述中提取R-nnnn格式的需求
分配优先级 — 为每个需求标记「必须（Must）/应该（Should）/可以（Could）」
生成阶段PRD — 使用
```
assets/phase-prd-template.md
```
中的模板
更新覆盖索引 — 将选中的功能标记为「进行中（In Progress）」

Step 1: Feature Selection

步骤1：功能选择

Review

Planned

features in Coverage Index. Select based on:

Dependencies — Foundation features before dependent ones
Cohesion — Group related features (e.g., all calendar views together)
Business priority — Per user input or stakeholder notes
Complexity — Balance large and small features

Present selection to user for approval before proceeding.

查看覆盖索引中的「已规划」功能，选择时需考虑：

依赖关系 — 先选择基础功能，再选择依赖于它们的功能
内聚性 — 将相关功能分组（例如，将所有日历视图功能放在一起）
业务优先级 — 根据用户输入或相关方意见
复杂度 — 平衡大型和小型功能的数量

在继续下一步前，需将所选功能提交给用户确认。

Step 2: Requirement Decomposition

步骤2：需求拆解

For each selected feature, read the Vision PRD section and extract atomic requirements.

Vision prose:

User selects quantity, enters name/email, receives confirmation email immediately.

Becomes:

markdown

undefined

对于每个选中的功能，阅读愿景PRD中的对应部分，提取原子化需求。

愿景描述示例：

用户选择数量，输入姓名/邮箱，立即收到确认邮件。

拆解后：

markdown

undefined

R-0141: RSVP Quantity Selection

R-0141: RSVP数量选择

Parent: F-014 Priority: Must

Users shall select the number of seats when submitting an RSVP.

父功能： F-014 优先级： 必须（Must）

用户提交RSVP时，应可选择席位数量。

R-0142: RSVP Data Collection

R-0142: RSVP数据收集

Parent: F-014 Priority: Must

The RSVP form shall collect attendee name and email address.

父功能： F-014 优先级： 必须（Must）

RSVP表单应收集参会者的姓名和邮箱地址。

R-0143: RSVP Confirmation Email

R-0143: RSVP确认邮件

Parent: F-014 Priority: Must

The system shall send a confirmation email upon RSVP submission.


**Decomposition guidelines:**
- One behavior per requirement
- Use "shall" for required behaviors
- Keep requirements testable and atomic
- ~5 requirements per feature is typical

父功能： F-014 优先级： 必须（Must）

系统应在用户提交RSVP后立即发送确认邮件。


**拆解指南：**
- 每个需求对应一个行为
- 使用「应」来描述必填行为
- 确保需求可测试且原子化
- 通常每个功能对应约5个需求

Step 3: Priority Assignment

步骤3：优先级分配

Priority	Meaning	Guidance
Must	Required for phase to ship	Core functionality, blockers
Should	Expected but negotiable	Important but not critical
Could	Nice to have	Enhancements, polish

Aim for roughly 60% Must, 30% Should, 10% Could.

优先级	含义	指导原则
Must（必须）	阶段发布的必备需求	核心功能、阻塞项
Should（应该）	预期需求但可协商	重要但非关键
Could（可以）	锦上添花的需求	增强功能、优化项

目标比例大致为：60% Must，30% Should，10% Could。

Step 4: Generate Phase PRD

步骤4：生成阶段PRD

Use template at

assets/phase-prd-template.md

. Structure:

Phase Overview (goals, scope, timeline)
Features in Scope (list with F-nnn)
Functional Requirements (R-nnnn grouped by feature)
Quality Requirements section (placeholder — populated by
```
prd-qa-enricher
```
)
Acceptance Criteria section (placeholder — populated by
```
prd-qa-enricher
```
)

使用

assets/phase-prd-template.md

中的模板，结构如下：

阶段概述（目标、范围、时间线）
涵盖的功能（列出F-nnn编号）
功能需求（按功能分组的R-nnnn需求）
质量需求部分（占位符 — 由
```
prd-qa-enricher
```
工具填充）
验收标准部分（占位符 — 由
```
prd-qa-enricher
```
工具填充）

Requirement Numbering

需求编号规则

Continue R-nnnn sequence across phases:

Phase I: R-0001 → R-0089
Phase II: R-0090 → R-0179
Phase III: R-0180 → R-0269

Check previous Phase PRDs to find the last used R-nnnn.

跨阶段延续R-nnnn编号序列：

第一阶段：R-0001 → R-0089
第二阶段：R-0090 → R-0179
第三阶段：R-0180 → R-0269

查看之前的阶段PRD，找到最后使用的R-nnnn编号。

References

参考资料

```
references/naming-conventions.md
```
— ID formats and rules
```
references/phasing-process.md
```
— Detailed extraction workflow

```
references/naming-conventions.md
```
— ID格式与规则
```
references/phasing-process.md
```
— 详细的提取工作流程