milestone-planning

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Milestone Planning

Milestone 规划

Plan roadmap structure before task-local spec work begins.

This skill decides

Milestone -> optional Module -> Task

shape. It owns roadmap-layer

docs/tasks/

structure and governance, not task-local specs or implementation flow.

在针对具体任务的规格工作开始前，规划路线图结构。

此技能用于确定

Milestone -> 可选Module -> Task

的层级结构。它负责路线图层面的

docs/tasks/

结构与管理，但不负责具体任务的规格说明书或实现流程。

Composition

职责范围

Entry: reached from
```
doc-driven-spec-workflow
```
after scope is clear enough to plan delivery structure.
Owns: milestone boundaries, optional module grouping, roadmap-layer task breakdown, backlog/handoff governance, planning-stage
```
docs/tasks/
```
documents.
Does not own: repository scaffold bootstrap, task-local
```
spec.md
```
, task-local
```
plan.md
```
, readiness checks, implementation, verification, branch closing.
Handoff: use
```
task-spec-execution
```
only after the current concrete task is selected and the user wants to enter spec-first execution.

入口: 在范围足够清晰、可规划交付结构后，从
```
doc-driven-spec-workflow
```
进入此流程。
负责: 里程碑边界、可选模块分组、路线图层面的任务拆分、待办/交接管理、规划阶段的
```
docs/tasks/
```
文档。
不负责: 代码库脚手架初始化、具体任务的
```
spec.md
```
、具体任务的
```
plan.md
```
、就绪检查、实现、验证、分支关闭。
交接: 仅当选定当前具体任务且用户希望进入规格优先的执行流程时，才移交至
```
task-spec-execution
```
。

Core Rules

核心规则

Delivery Boundary

交付边界

Start from: release goal, phase boundary, acceptance boundary — not feature count.
One milestone: same delivery goal + same completion definition + no meaningful stage boundary.
Multiple milestones: clear phase boundaries, different exit criteria, different release timing, or frozen history needed.

起点: 发布目标、阶段边界、验收边界 — 而非功能数量。
单个里程碑: 具备相同交付目标 + 相同完成定义 + 无意义重大阶段边界。
多个里程碑: 存在明确阶段边界、不同退出标准、不同发布时间，或需要冻结历史记录。

Module Rules

模块规则

Modules are optional. Use only when a milestone has multiple durable capability areas with distinct ownership, dependency graphs, risk profiles, release boundaries, or acceptance criteria.
Skip modules when there is only one real capability area.

模块是可选的。仅当里程碑包含多个具有不同所有权、依赖关系图、风险概况、发布边界或验收标准的持久能力领域时，才使用模块。
若仅存在一个核心能力领域，则跳过模块设置。

Task Rules

任务规则

One independently reviewable implementation round.
Delivers one coherent capability outcome: implementation, tests, docs/status updates, verification.
Keep inside the task: tests, migrations, docs updates, refactors required for the capability.

每个任务对应一轮可独立评审的实现工作。
交付一个连贯的能力成果：实现、测试、文档/状态更新、验证。
任务需包含：该能力所需的测试、迁移、文档更新、重构工作。

Routing

路由规则

Situation	Action
Empty `Open Milestones`	Use `superpowers:brainstorming` first
`Roadmap confirmed: no`	Treat tasks as candidates only
Cross-milestone movement	Resolve previous milestone closure first

Planning mode question: "Do you already have a concrete short-term target for this iteration, or do we need to realign the next stage of the roadmap first?"

场景	操作
「开放里程碑」为空	先使用 `superpowers:brainstorming`
「路线图已确认：否」	仅将任务视为候选项
跨里程碑调整	先完成前一个里程碑的收尾工作

规划模式问题: "您是否已为本迭代设定了明确的短期目标，还是我们需要先重新调整路线图的下一阶段？"

Mandatory Behavior

强制行为

Explain why each milestone, module, and task boundary exists. Structure without rationale is incomplete.
Ask the planning mode question first when it is still unclear whether the user needs roadmap alignment or direct decomposition.
Treat an empty
```
Open Milestones
```
list as a routing signal, not enough information to decompose by itself.
Use
```
superpowers:brainstorming
```
first when goals, constraints, success criteria, or roadmap alignment are still unclear.
Skip
```
superpowers:brainstorming
```
and decompose directly when the user already has a concrete short-term target.
Treat milestone confirmation as the primary routing signal for task decomposition.
Treat tasks inside a milestone marked
```
Roadmap confirmed: no
```
as provisional planning output, not formally selected execution work.
Treat milestone/module/task creation or reshaping as docs governance only. It does not authorize spec writing or implementation.
Hand off to
```
task-spec-execution
```
only after the current concrete task is chosen.

需解释每个里程碑、模块和任务边界的存在理由。无合理依据的结构视为不完整。
当仍不清楚用户需要路线图对齐还是直接分解时，先提出规划模式问题。
将空的「开放里程碑」列表视为路由信号，而非可直接进行分解的足够信息。
当目标、约束、成功标准或路线图对齐仍不明确时，先使用
```
superpowers:brainstorming
```
。
当用户已有明确短期目标时，跳过
```
superpowers:brainstorming
```
直接进行分解。
将里程碑确认作为任务分解的主要路由信号。
将标记为「路线图已确认：否」的里程碑内任务视为临时规划输出，而非正式选定的执行工作。
将里程碑/模块/任务的创建或调整仅视为文档管理操作，不授权规格编写或实现工作。
仅当选定当前具体任务后，才移交至
```
task-spec-execution
```
。

Handoff and Closure

交接与收尾

```
Handoff Notes
```
: temporary transfer queue for follow-up findings. Resolve before milestone closure.
Before closure: every
```
Handoff Notes
```
item must be resolved to current-milestone open work, later milestone,
```
docs/tasks/backlog.md
```
, or removal.
Close milestone when original exit criteria are satisfied.
Completed milestones are frozen; add follow-up work to a new open milestone.
If the user appears to be moving into a later milestone, resolve previous milestone closure and target milestone confirmation before decomposing or selecting work there.
If milestone entry is still ambiguous, do not answer the routing question on the user's behalf before the user responds.

```
交接说明
```
: 用于记录后续待处理事项的临时队列。需在里程碑收尾前解决。
收尾前: 所有
```
交接说明
```
项必须被分配至当前里程碑的未完成工作、后续里程碑、
```
docs/tasks/backlog.md
```
，或直接移除。
当原始退出标准满足时，关闭里程碑。
已完成的里程碑将被冻结；后续工作需添加至新的开放里程碑。
若用户似乎要推进至后续里程碑，需先完成前一个里程碑的收尾并确认目标里程碑，再进行分解或工作选择。
若里程碑入口仍不明确，在用户回复前不要代为回答路由问题。

Output Requirements

输出要求

Always provide:

Recommended milestone structure
Why it is one milestone or several
Whether modules are needed
Task list per milestone or module
Delivery order when not obvious
Assumptions or open questions

Documents to create/update:

```
docs/tasks/index.md
```
Optional:
```
docs/tasks/backlog.md
```
```
docs/tasks/<milestone>/index.md
```

Optional:

docs/tasks/<milestone>/<module>/index.md

```
docs/tasks/<milestone>/<task>/task.md
```

Use

references/roadmap-template.md

for exact planning-stage shape.

需始终提供：

推荐的里程碑结构
采用单个或多个里程碑的理由
是否需要模块
每个里程碑或模块下的任务列表
交付顺序（当顺序不明确时）
假设或未解决的问题

需创建/更新的文档：

```
docs/tasks/index.md
```
可选：
```
docs/tasks/backlog.md
```
```
docs/tasks/<milestone>/index.md
```

可选：

docs/tasks/<milestone>/<module>/index.md

```
docs/tasks/<milestone>/<task>/task.md
```

使用

references/roadmap-template.md

作为规划阶段的标准模板。

Detailed Rules and Anti-Patterns

详细规则与反模式

For complete mandatory rules, routing rules, and anti-patterns, see:

references/milestone-detailed-rules.md
references/milestone-anti-patterns.md

完整的强制规则、路由规则和反模式，请参阅：

references/milestone-detailed-rules.md
references/milestone-anti-patterns.md

When To Use

使用场景

Use this skill when:

Milestone boundaries, module grouping, or task breakdown need to be decided
Milestones are missing, stale, or need reshaping around current goals
The user wants a phase, iteration, or request broken into roadmap structure
Roadmap-layer
```
docs/tasks/
```
structure must be created or reshaped before current-task spec writing
Current delivery scope and later enhancements need an explicit stage boundary

Do not use this skill when:

The current concrete task is already selected and only needs task-local spec or implementation governance
The problem is implementation design within one task rather than roadmap decomposition
The work is pure docs maintenance with no milestone or task planning need

在以下场景使用此技能：

需要确定里程碑边界、模块分组或任务拆分时
里程碑缺失、过时，或需要围绕当前目标重新调整时
用户希望将某个阶段、迭代或需求拆分为路线图结构时
在编写当前任务的规格说明书前，需要创建或调整路线图层面的
```
docs/tasks/
```
结构时
当前交付范围与后续增强需要明确的阶段边界时

请勿在以下场景使用此技能：

已选定当前具体任务，仅需要任务层面的规格或实现管理时
问题属于单个任务内的实现设计，而非路线图分解时
工作仅为纯文档维护，无需里程碑或任务规划时