Menü
当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
在任何创造性工作之前必须使用此技能——创建功能、构建组件、添加功能或修改行为。在实现之前先探索用户意图、需求和设计。
当你有一份书面实现计划需要在单独的会话中执行，并设有审查检查点时使用
完成任务、实现重要功能或合并前使用，用于验证工作成果是否符合要求
当在当前会话中执行包含独立任务的实现计划时使用
在开始任何对话时使用——确立如何查找和使用技能，要求在任何响应（包括澄清性问题）之前调用 Skill 工具
在宣称工作完成、已修复或测试通过之前使用，在提交或创建 PR 之前——必须运行验证命令并确认输出后才能声称成功；始终用证据支撑断言
Basierend auf der SOC-Berufsklassifikation
| name | writing-plans |
| description | 当你有规格说明或需求用于多步骤任务时使用，在动手写代码之前 |
编写全面的实现计划，假设工程师对我们的代码库零上下文，且品味存疑。记录他们需要知道的一切：每个任务要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆成小步骤任务。DRY。YAGNI。TDD。频繁 commit。
计划的每个实现任务必须包含两个子步骤： 1. **先写失败的单元测试** — 步骤必须包含完整测试代码 2. **再写最少实现代码** — 步骤必须包含完整实现代码不包含 UT 先行步骤的实现任务是无效计划，必须修正。 纯配置、文档、样式类任务可豁免，但必须明确标注"本任务不涉及业务逻辑"。
假设他们是有经验的开发者，但对我们的工具链和问题领域几乎一无所知。假设他们不太擅长测试设计。
开始时宣布： "我正在使用 writing-plans 技能创建实现计划。"
上下文： 此技能应在专用 worktree 中运行（由 brainstorming 技能创建）。
计划保存位置： docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md
如果规格涵盖了多个独立子系统，它应该在头脑风暴阶段就被拆分为子项目规格。如果没有，建议将其拆分为独立的计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。
在定义任务之前，先列出将要创建或修改的文件以及每个文件的职责。这是锁定分解决策的地方。
此结构决定了任务分解。每个任务应产出独立的、有意义的变更。
每步是一个操作（2-5 分钟）：
TDD 强制： 以上红-绿循环是每个实现任务的标准模板。如果任务涉及业务逻辑，跳过任何一步都是计划缺陷。
每个计划必须以此头部开始：
# [功能名称] 实现计划
> **面向 AI 代理的工作者：** 必需子技能：使用 superpowers:subagent-driven-development（推荐）或 superpowers: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：Commit**
```bash
git add tests/path/test.py src/path/file.py
git commit -m "feat: add specific feature"
```
每个步骤都必须包含工程师需要的实际内容。以下是计划缺陷——绝不要写出来：
编写完整计划后，以全新视角审视规格并对照检查计划。这是你自己执行的检查清单——不是子代理调度。
1. 规格覆盖度： 浏览规格中的每个章节/需求。你能指出实现它的任务吗？列出所有遗漏。
2. 占位符扫描： 搜索计划中的红旗——上方"禁止占位符"章节中的任何模式。修复它们。
3. 类型一致性： 后续任务中使用的类型、方法签名和属性名是否与前面任务中定义的一致？任务 3 中叫 clearLayers() 但任务 7 中叫 clearFullLayers() 就是 bug。
4. TDD 合规检查： 每个涉及业务逻辑的任务是否都包含"先写测试 → 验证失败 → 写实现 → 验证通过"的完整步骤？是否有任务跳过了 UT 直接写实现？
如果发现问题，直接内联修复。无需重新审查——修好继续推进。如果发现规格中的需求没有对应任务，就添加任务。
保存计划后，提供执行选项：
"计划已完成并保存到 docs/superpowers/plans/<filename>.md。两种执行方式：
1. 子代理驱动（推荐） - 每个任务调度一个新的子代理，任务间进行审查，快速迭代
2. 内联执行 - 在当前会话中使用 executing-plans 执行任务，批量执行并设有检查点
选哪种方式？"
如果选择子代理驱动：
如果选择内联执行：