roadmap-propose

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

You are helping the user turn planned roadmap work into a normal spec-driven change.

你将协助用户把路线图中的计划工作转换为标准的spec-driven变更。

Prerequisites

前置条件

The

.spec-driven/

directory must exist at the project root. Before proceeding, verify:

ls .spec-driven/

If this fails, the project is not initialized. Run

/spec-driven-init

first.

.spec-driven/roadmap/

is missing, repair the scaffold first:

node {{SKILL_DIR}}/scripts/spec-driven.js init

.spec-driven/

目录必须存在于项目根目录下。继续操作前，请先验证：

ls .spec-driven/

如果执行失败，说明项目尚未初始化，请先运行

/spec-driven-init

。

如果缺少

.spec-driven/roadmap/

目录，请先修复脚手架：

node {{SKILL_DIR}}/scripts/spec-driven.js init

Steps

步骤

Identify the target planned change — determine which milestone item the user wants to turn into a real change. If they already gave a change name, use it. Otherwise ask which
```
Planned Changes
```
item to promote.
Read roadmap and spec context first — before scaffolding anything, read:
- ```
.spec-driven/config.yaml
```
- ```
.spec-driven/roadmap/INDEX.md
```
- the milestone file that contains the target item
- ```
.spec-driven/specs/INDEX.md
```
- the relevant main spec files the new change is likely to touch
- the selected planned change entry as a single-line roadmap input
Confirm it is already planned work — verify that the selected name is present under a milestone
```
## Planned Changes
```
section before scaffolding.
Extract the roadmap handoff context — treat the selected planned change entry as more than a name lookup:
- use the canonical first line to identify the change name while treating the declared status and summary as metadata on that same line
- use the surrounding milestone sections as context for scope, rationale, sequencing, or constraints when the one-line summary is not sufficient
- treat milestone declared statuses as limited to
```
proposed
```
  ,
```
active
```
  ,
```
blocked
```
  , or
```
complete
```
- treat planned change declared statuses as limited to
```
planned
```
  or
```
complete
```

Scaffold the change — run:

node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>

This creates

.spec-driven/changes/<name>/

with seeded artifact templates.

Fill the standard proposal artifacts — populate:
- ```
proposal.md
```
- ```
design.md
```
- ```
tasks.md
```
  with
```
## Testing
```
  containing at least one explicit lint or validation command task and one explicit unit test command task when those commands are knowable from repository context
- ```
questions.md
```
- delta specs under
```
changes/<name>/specs/
```
- mapping frontmatter in delta spec files when implementation and test paths are knowable from repository context Use the roadmap milestone as planning input, but treat the selected planned change as a single-line item and derive any extra context from the milestone sections rather than multiline planned change detail.
Validate artifact format — run:
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
If the command reports repairable format issues, fix them and rerun verify.
Offer the execution handoff — report the new change path, note which milestone it came from, surface any open questions that must be resolved before implementation, and ask the user whether they want to:
- enter
```
/spec-driven-apply <name>
```
  for the stepwise execution path
- enter
```
/spec-driven-auto
```
  for the end-to-end execution path Do not auto-enter either execution path without the user's explicit choice.

确定目标计划变更 —— 明确用户想要转换为实际变更的里程碑项。如果用户已经给出了变更名称，直接使用即可，否则询问需要升级哪个
```
Planned Changes
```
项。
先读取路线图和spec上下文 —— 在生成任何脚手架之前，先读取以下内容：
- ```
.spec-driven/config.yaml
```
- ```
.spec-driven/roadmap/INDEX.md
```
- 包含目标项的里程碑文件
- ```
.spec-driven/specs/INDEX.md
```
- 新变更可能涉及的相关主spec文件
- 选中的计划变更条目，作为单行路线图输入
确认属于已计划工作 —— 在生成脚手架前，验证选中的名称确实存在于里程碑的
```
## Planned Changes
```
章节下。
提取路线图交接上下文 —— 不要仅将选中的计划变更条目当作名称查询依据，还需要：
- 使用规范的第一行识别变更名称，同时将同一行中声明的状态和摘要作为元数据
- 当单行摘要信息不足时，参考周围的里程碑章节作为范围、基本原理、顺序或约束的上下文
- 里程碑声明的状态仅限
```
proposed
```
  、
```
active
```
  、
```
blocked
```
  、
```
complete
```
  四类
- 计划变更声明的状态仅限
```
planned
```
  或
```
complete
```
  两类
生成变更脚手架 —— 运行：
```
node {{SKILL_DIR}}/scripts/spec-driven.js propose <name>
```
该命令会在
```
.spec-driven/changes/<name>/
```
目录下生成初始的工件模板。
填充标准提案工件 —— 填充以下内容：
- ```
proposal.md
```
- ```
design.md
```
- ```
tasks.md
```
  ，当可以从仓库上下文获知测试命令时，在
```
## Testing
```
  章节至少包含一个明确的lint或校验命令任务，以及一个明确的单元测试命令任务
- ```
questions.md
```
- 存放在
```
changes/<name>/specs/
```
  下的增量spec文件
- 当可以从仓库上下文获知实现和测试路径时，在增量spec文件中添加前置元数据（frontmatter）映射可参考路线图里程碑作为规划输入，但仅将选中的计划变更视为单行项，任何额外上下文都从里程碑章节获取，而非多行的计划变更详情。
校验工件格式 —— 运行：
```
node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>
```
如果命令报告可修复的格式问题，修复后重新运行校验命令。
提供执行交接选项 —— 告知用户新的变更路径，说明其来源的里程碑，列出所有实现前必须解决的待解决问题，并询问用户是否想要：
- 输入
```
/spec-driven-apply <name>
```
  选择分步执行路径
- 输入
```
/spec-driven-auto
```
  选择端到端执行路径未经用户明确选择，不要自动执行任意一种执行路径。

Rules

规则

This skill creates planning artifacts only — do not implement product code
Only turn
```
Planned Changes
```
into change scaffolds
Create the same five artifacts as
```
spec-driven-propose
```
Keep implementation and test mappings in spec frontmatter, not in requirement prose
If testing commands are not knowable from repository context, add an open question instead of guessing them
Before finishing, rerun
```
verify
```
until all repairable format issues are fixed

本技能仅生成规划工件 —— 不要实现产品代码
仅将
```
Planned Changes
```
转换为变更脚手架
生成与
```
spec-driven-propose
```
完全相同的5个工件
实现和测试映射存放在spec的前置元数据中，不要写在需求正文里
如果无法从仓库上下文获知测试命令，不要猜测，添加为待解决问题即可
完成前重新运行
```
verify
```
命令，直到所有可修复的格式问题都被解决