create-task-plans-runtime

name	create-task-plans-runtime
description	桌面/网关运行时内置的计划创建技能，用于生成可落盘、可调度、可批次执行的结构化计划包。

编写计划

使用此技能将规格说明或粗略请求转化为实施计划，使另一个代理能够在聚焦会话中安全执行。

开始时请说：我正在使用 create-task-plans-runtime 技能来创建实施计划。

输出位置

将每个计划保存为一个目录：

./.plans/YYYY-MM-DD-<功能名称>/
├── plan.md
├── prompt.md
├── tasks.json
├── 1-<first-task>.md
├── 2-<second-task>.md
└── ...

• YYYY-MM-DD 使用当前日期。
• 所有计划全部使用中文。
• 使用简短的中文短横线分隔功能标识。
• 如果用户提供了不同路径，则使用用户指定的路径。
• 将 plan.md 保持为整体的任务参考指南；生成后只读，后续提示词不得要求修改或清理它。
• 将 prompt.md 保持为所有任务的执行提示列表，方便用户复制粘贴到不同对话框。
• 将 tasks.json 保持为运行时调度事实来源，必须与 prompt.md 和编号任务文件一一对应。
• 将实现细节放入编号任务文件中，不要写进一个过大的计划文件。

结构化计划包

运行时计划目录必须同时产出 Markdown 文件和 tasks.json：

• tasks.json 顶层必须包含 plan_dir 和 tasks。
• tasks 数组中每个元素必须对应一个编号任务文件，按任务编号升序排列。
• 每个任务元素必须包含 id、title、file、batch、depends_on_batches、status。
• file 必须是相对计划目录的 Markdown 文件名，例如 1-复制运行时计划技能.md。
• batch 必须是正整数；depends_on_batches 必须是整数数组，无依赖时使用空数组。
• status 只能使用任务文件允许的状态，初始为 未开始。
• prompt.md 中的任务标题、批次、依赖批次和任务文件路径必须与 tasks.json 完全一致。
• 如果无法保证 Markdown 文件与 tasks.json 一一对应，必须先修正计划包，不要交付部分产物。

计划工作流

1. 在编写计划前，先阅读请求、相关仓库说明、现有模块、工厂连线和相邻测试。
2. 如果请求涉及外部规格、变更提案、设计文档、能力说明或任务清单，先用对应工具或清单确认活跃变更；名称明确时直接使用，未给出且只有一个合理活跃变更时可自动选择，存在歧义时先让用户选择。
3. 对外部变更，先读取其状态，并以工具返回的模式、产物、依赖关系和实现指令为准；不要猜测固定文件名或固定流程。
4. 读取工具返回的依赖文件、上下文文件和其它必要仓库上下文后，再编写计划。
5. 如果目标、成功标准、非目标、设计边界、变更状态或产物依赖不清楚，先澄清；不要把未确认猜测写成计划事实。
6. 对仍有多个可行路线的设计，记录 2-3 个方案的主要权衡和最终选择。
7. 定义范围边界。如果请求横跨独立子系统，将其拆分为单独的计划目录，或清晰标记范围外工作。
8. 围绕一个可测试行为、一个窄模块变更或一个未完成来源任务来划分任务边界，确保一个代理通常能在一个聚焦会话中完成。
9. 对会改变行为的代码，定义实现前必须先编写的失败测试。
10. 定义每个任务被标记为 已完成 前需要哪些新证据；如果任务映射外部任务清单，说明完成后需要按来源工具规则更新对应任务状态。
11. 在具体的任务和 prompt.md 同时写出线性执行顺序和可并行执行批次；并行批次只包含没有相互依赖、不会争用同一文件或验证资源的任务。
12. 先编写包含全局架构的 plan.md，再编写每个编号任务文件，最后编写 prompt.md 和 tasks.json。
13. 在 prompt.md 中为每个编号任务提供一个可直接复制的执行提示；提示必须引用对应任务文件、当前批次和依赖批次，要求执行者先阅读 plan.md 和任务文件，只在对应任务文件中记录阻塞原因，在最终回复中报告完成证据，禁止修改 plan.md。
14. 重新通读完整计划，检查缺失需求、占位符、不安全假设、任务顺序、并行批次冲突和 prompt.md 是否覆盖每个任务。
15. 特别注意，并行批次一定保证正确，不要将不能并行的放到同一个批次，不能并行就升高批次数。

除非用户明确要求同时进行计划和实现，否则编写计划时不要实现代码。

plan.md 模板

# <功能名称> 计划

目标：<用一句话描述结果，不超过 100 字>

范围：<包含哪些内容，不超过 300 字>

范围外：<有意排除哪些内容，不超过 100 字>

假设：<仅写有仓库上下文支持的具体假设，不超过 200 字>

## 设计决策 <不超过 100 字>

- <已确认的方案选择、关键权衡或用户批准的约束>
- <如适用，记录来源变更、模式、关键产物和已确认约束>

## 架构说明 <不超过 100 字>

- <需要遵循的关键现有模块/模式>
- <重要约束、风险或安全边界>

## 开发策略

- 对会改变行为的代码，使用失败验证-通过验证-重构。
- 在实施步骤前规划失败验证命令和预期失败。
- 将实施步骤限制在失败测试所证明的行为范围内。
- 测试真实行为，不验证模拟对象或实现细节。

编号任务文件仅使用这些状态：未开始、已完成、已阻塞、已完成，待回归。

prompt.md 模板

prompt.md 是给用户复制粘贴的任务执行列表，不是进度来源。它必须覆盖所有编号任务，并保持与任务文件一一对应。

# <功能名称> 任务提示词

按顺序复制以下提示到独立对话框执行。执行前先阅读 `plan.md` 和对应任务文件；`plan.md` 只是整体架构指南，不是进度来源，不要修改它的任何部分。

## 任务 1: <任务名称>【批次 1】

```text
请使用技能 ./skills/do-task-plans/SKILL.md 执行 `<plan-dir>/1-<first-task>.md`。

开始前先阅读 `<plan-dir>/plan.md` 和该任务文件，确认依赖已满足。按任务文件中的测试驱动开发/验证计划实施，只处理该任务范围。
任务获得所需验证证据后，在最终回复中报告完成证据并删除该任务文件；如果被阻塞，只在任务文件中更新为 `已阻塞` 并记录具体原因和已运行的检查；如果因为无关本次修改的导致无法运行验证，可以解除`已阻塞`，修改为状态为 `已完成，待回归验证`。
注意，`<plan-dir>/plan.md` 为只读，不要修改该文件的任何部分，这会增加上下文的大小，还会干扰其他任务的执行。
```

## 任务 2: <任务名称> 【批次 2】 <依赖批次 1或“无”>

```text
请使用技能 ./skills/do-task-plans/SKILL.md 执行 `<plan-dir>/2-<second-task>.md`。

开始前先阅读 `<plan-dir>/plan.md` 和该任务文件，确认依赖已满足。按任务文件中的测试驱动开发/验证计划实施，只处理该任务范围。
任务获得所需验证证据后，在最终回复中报告完成证据并删除该任务文件；如果被阻塞，只在任务文件中更新为 `已阻塞` 并记录具体原因和已运行的检查；如果因为无关本次修改的导致无法运行验证，可以解除`已阻塞`，修改为状态为 `已完成，待回归验证`。
注意，`<plan-dir>/plan.md` 为只读，不要修改该文件的任何部分，这会增加上下文的大小，还会干扰其他任务的执行。
```

• 每个提示都必须包含具体任务文件路径。
• 如果任务可并行执行，仍按任务编号列出；在每个编号任务文件中写明批次和依赖批次。
• 不要在 prompt.md 中复制完整任务细节，避免与任务文件漂移，提示词必须为中文，必须严格遵守这个格式。
• 不要让执行者跳过验证、跳过编号任务文件中的阻塞状态更新或扩大任务范围。

任务文件模板

每个任务文件都必须足够自包含，使执行者无需阅读所有其他任务即可执行。

# 任务 N: <任务名称>

批次：【批次 3】 <依赖批次 1,2或“无”>

状态：未开始

目的：<此任务要完成什么，不超过 100 字>

来源任务：<对应来源任务编号或“无”>

预计会话范围：<为什么这适合一个聚焦会话，不超过 300 字>

## 文件

- 新建：`exact/path/to/new_file.rs`
- 修改：`exact/path/to/existing_file.rs`
- 测试：`exact/path/to/test_file.rs`

## 上下文

- <实现者必须了解的现有符号、模式、命令或约束，不超过 200 字>

## 测试计划

- 行为：<此任务证明的单一行为或缺陷>
- 失败验证测试：<要新增或修改的测试文件和测试名>
- 失败验证命令：`<确切命令>`
- 预期失败原因：<实现前的具体失败原因>
- 通过验证命令：`<确切命令>`
- 模拟策略：<优先使用真实依赖，或说明要模拟的确切边界及原因>

## 步骤

1. 为上述行为编写失败验证测试。
2. 运行失败验证命令并确认预期失败。
3. 实现让测试通过所需的最小生产代码变更。
4. 运行通过验证命令和相关周边检查。
5. 仅在测试保持通过时进行重构。

## 验证

- 运行：`<确切命令>`
- 预期：<具体成功信号>
- 所需证据：<失败验证的预期失败、通过验证成功、退出码、输出行、失败数量、已审查差异或证明完成的清单结果>

## 完成

对于代码变更，包含确切文件路径、相关符号、预期行为和聚焦验证命令。只有在能消除歧义时才包含代码片段；避免粘贴会随仓库漂移的大段代码。如果测试驱动开发不适用，在任务中说明原因，并将测试驱动开发计划小节替换为适合仓库的验证计划。

## 任务大小规则

如果一个任务符合以下情况，就说明它过大：

- 触及多个无关模块。
- 需要多个独立设计决策。
- 有超过一个主要验证故事。
- 很可能超出一个聚焦编码会话。
- 混合了功能工作、重构工作和基础设施工作。

当任务过大时，按行为、模块边界或验证目标拆分为多个独立的任务。保持任务文件的依赖关系显式。

## 质量门槛

- 遵守仓库说明和禁用命令。
- 计划前先收敛目标、成功标准、非目标和设计边界；不清楚时先澄清。
- 对外部规格或变更相关计划，以来源工具返回的变更、模式、产物、依赖关系、指令和上下文文件为准。
- 不把来源工具的上下文或规则原样复制进计划，只提炼与实施相关的约束。
- 若来源工具返回阻塞状态、缺少必要产物、范围会扩大或存在安全风险，暂停并说明原因；不要伪造可执行计划。
- 发现新需求、设计决策、范围变化或新增任务时，先询问用户是否记录回来源产物；不要自动写入。
- 优先使用现有模式，而不是新增抽象。
- 不要添加推测性的配置、特征、特性开关或扩展点。
- 保持不支持路径显式。
- 在相关时包含安全和权限边界。
- 每个 `已完成` 状态都必须依赖当前验证证据，而不是信心或过去的运行结果。
- 对行为变更，要求失败验证和通过验证证据，除非任务明确说明测试驱动开发不适用的原因。
- 优先使用真实行为测试；只 mock 清晰的外部、缓慢、不安全或非确定性边界，并说明 mock 的副作用和数据形状。
- 除非用户明确要求提交，否则不要包含 commit 步骤。
- 不要写 `TBD`、`TODO`、`later`、`add proper error handling` 或 `similar to previous task` 这类占位符。
- 不要引用计划尚未定义或验证的类型、函数、文件或命令。

## 自我审查

完成前：

- 检查每个用户需求是否映射到至少一个任务。
- 检查每个任务是否能在其依赖完成后独立执行。
- 检查 `prompt.md` 是否存在，且为每个任务提供了可复制的执行提示。
- 检查 `tasks.json` 是否存在，且任务条目与 Markdown 文件一一对应。
- 检查 `plan.md` 是否包含具体任务步骤、状态或进度信息；如果包含，立刻移入对应编号任务文件，`plan.md` 只保留整体架构指南。
- 检查并行批次中的任务没有任务依赖、文件写入或验证资源冲突。
- 检查所有验证命令是否遵守仓库说明。
- 检查每个任务是否定义了被标记为 `已完成` 前所需的证据。
- 检查会改变行为的任务是否定义了失败验证和通过验证命令。
- 检查不存在占位符或含糊步骤。

## 交接

结束时报告已保存的计划目录、创建的任务文件数量和 `prompt.md`。保持回复简短，并包含下一步推荐动作。