Chikage0o0/writing-plans

编写计划

概述

编写全面的实施计划，假设工程师对我们的代码库完全不了解，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、需要查阅的文档、如何测试。将整个计划拆分为细粒度的任务。遵循 DRY、YAGNI、TDD 原则，频繁提交。

假设他们是一名熟练的开发者，但几乎不了解我们的工具链或问题域。假设他们对良好的测试设计不太熟悉。

开始时声明："我正在使用 writing-plans 技能来创建实施计划。"

注意： 如果 brainstorming 阶段判断为小型任务（< 3 个文件），则跳过本技能，直接进入开发阶段。

**上下文：**本技能应在当前 git 分支上下文中运行。外部工具可能在执行前准备或切换分支，但本技能不得要求或创建单独的工作空间目录。

保存计划至：docs/plans/active/YYYY-MM-DD-<feature-name>.md

• （用户对计划位置的偏好优先于此默认值） 在整项工作完成前，将计划保留在 docs/plans/active/ 中，完成后移至 docs/plans/completed/。
• 计划文档默认使用中文，包括标题、章节标题、任务标题、步骤描述、列表项、固定提示词和预期结果文本。
• 如果用户明确要求使用英文或其他语言编写计划，请遵循用户指令而非默认值。
• 不要翻译代码块、shell 命令、文件路径、技能名称或标识符，除非用户明确要求。

范围检查

如果规格说明涵盖了多个独立的子系统，那么它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个计划。每个计划都应独立产出可运行、可测试的软件。

文件结构

在定义任务之前，先梳理出将要创建或修改哪些文件，以及每个文件的职责。这是分解决策被锁定的地方。

• 设计具有清晰边界和明确接口的单元。每个文件应有一个明确的职责。
• 你能同时在上下文中理解的代码，推理效果最好；文件越聚焦，编辑越可靠。优先选择小而聚焦的文件，而非功能过多的大文件。
• 一起变更的文件应该放在一起。按职责拆分，而不是按技术层级拆分。
• 在现有代码库中，遵循既定模式。如果代码库使用大文件，不要单方面重构——但如果你正在修改的文件已经变得难以驾驭，在计划中包含拆分是合理的。

该结构指导任务分解。每个任务都应产生自包含的、独立有意义的变更。

细粒度任务拆分

每个步骤是一个动作（2-5 分钟）：

• "编写失败测试" - 步骤
• "运行测试以确认失败" - 步骤
• "编写最小实现使测试通过" - 步骤
• "运行测试并确认通过" - 步骤
• "提交" - 步骤

计划文档头部

每个计划必须以以下头部开头：

# [功能名称] 实施计划

> **给代理执行者：** REQUIRED SUB-SKILL: 使用 `subagent-driven-development`（推荐）或 `executing-plans` 逐任务执行本计划。步骤使用复选框 `- [ ]` 语法追踪。

**目标：** [一句话说明这份计划要完成什么]

**架构：** [2-3 句话说明实现思路]

**技术栈：** [关键技术与库]

---

任务结构

### 任务 N：[组件名称]

**文件：**
- 新增：`exact/path/to/file.py`
- 修改：`exact/path/to/existing.py:123-145`
- 测试：`tests/exact/path/to/test.py`

- [ ] **步骤 1：先写失败测试**

```python
def test_specific_behavior():
    result = function(input)
    assert result == expected
```

- [ ] **步骤 2：运行测试并确认失败**

运行：`pytest tests/path/test.py::test_name -v`
预期：FAIL，并看到 `function not defined`

- [ ] **步骤 3：编写最小实现**

```python
def function(input):
    return expected
```

- [ ] **步骤 4：运行测试并确认通过**

运行：`pytest tests/path/test.py::test_name -v`
预期：PASS

- [ ] **步骤 5：提交**

```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```

禁止占位符

每个步骤必须包含工程师所需的实际内容。以下是计划失败的范例——绝不要写：

• "TBD"、"TODO"、"稍后实现"、"补充细节"
• "添加适当的错误处理" / "添加验证" / "处理边界情况"
• "为上述内容编写测试"（没有实际测试代码）
• "与任务 N 类似"（重复代码——工程师可能是按乱序阅读任务的）
• 只描述做什么而不展示怎么做的步骤（代码步骤必须包含代码块）
• 引用在任何任务中都没有定义的类型、函数或方法

注意事项

• 始终使用精确的文件路径
• 每个步骤包含完整代码——如果步骤涉及代码变更，展示代码
• 使用带预期输出的精确命令
• 通过精确的 skill 名称/路径引用相关技能，以便 OpenCode 控制器显式加载它们
• DRY、YAGNI、TDD、频繁提交

自检审查

编写完完整计划后，以全新的视角审视规格说明并对照检查。这是你自己运行的检查清单——不是子代理派遣。

1. 规格覆盖： 浏览规格中的每个章节/需求。你能指出实现它的任务吗？列出任何缺口。

2. 占位符扫描： 在计划中搜索危险信号——上面"禁止占位符"部分中的任何模式。修复它们。

3. 类型一致性： 你在后续任务中使用的类型、方法签名和属性名称是否与早期任务中定义的一致？任务 3 中名为 clearLayers() 的函数，在任务 7 中却叫 clearFullLayers()，这就是一个 bug。

如果发现问题，直接内联修复。无需重新审查——修复后继续。如果发现某个规格需求没有对应任务，请添加该任务。

执行交接

保存计划后，在提供任何执行选项或开始实施之前，使用 OpenCode question 工具先询问：

"Plan 已保存到 docs/plans/active/<filename>.md。在开始实施前，你要我先提交当前的 plan/spec 文档吗？"

• 即使用户要求立即开始编码或已声明首选执行模式，此问题也是强制性的。
• 不要将此问题与执行模式问题合并。先解决文档提交决策。

如果用户希望提交文档：

• 必需子技能： 使用 git-commit
• 提交当前计划文档以及作为实施交接一部分的任何相关规格编辑。
• 提交成功后，提供下方的执行选项。

如果用户暂时不希望提交文档：

• 不要提交文档。
• 提供下方的执行选项。

文档提交问题解决后，使用 OpenCode question 工具提供执行选项：

"有两种执行方式：

1. Subagent-Driven（推荐） - 我为每个任务派发一个新的 subagent，在任务之间做评审，迭代更快

2. Inline Execution - 在当前会话中使用 executing-plans 执行任务，按检查点分批推进

你希望采用哪一种？"

如果选择 Subagent-Driven：

• 必需子技能： 使用 subagent-driven-development
• 控制器应按任务派遣真正的 implementer、spec-reviewer 和 code-reviewer 子代理类型
• 传入给子代理的上下文应包含：
  • 规格文档路径（如果存在）
  • 本轮任务需要完成的规格范围
  • 计划文档的行号范围（任务开始行到结束行）
  • 子代理自行读取计划文档获取详细信息

如果选择 Inline Execution：

• 必需子技能： 使用 executing-plans
• 批量执行，带检查点审查