القائمة
当你有规格或需求需要进行多步骤任务时使用，在动代码之前
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | writing-plans |
| description | 当你有规格或需求需要进行多步骤任务时使用，在动代码之前 |
编写全面的实现计划，假定工程师对我们的代码库零上下文且品味存疑。记录他们需要知道的一切：每个任务需要修改哪些文件、代码、测试、可能需要查阅的文档、如何测试。将整个计划拆分为细粒度任务。DRY。YAGNI。TDD。频繁提交。
假定他们是熟练的开发者，但对我们的工具集或问题领域几乎一无所知。假定他们不太擅长测试设计。
开始时声明："我正在使用 writing-plans skill 来创建实现计划。"
上下文： 应在专用 worktree 中运行（由 brainstorming skill 创建）。
计划保存位置： docs/plans/YYYY-MM-DD-<feature-name>.md
如果规格涵盖多个独立子系统，它应该在头脑风暴阶段已被拆分为子项目规格。如果没有，建议拆分为独立计划——每个子系统一个。每个计划应该能独立产出可工作、可测试的软件。
在定义任务之前，先映射出将要创建或修改的文件及其各自的职责。这是分解决策被锁定的地方。
此结构指导任务分解。每个任务应该产出独立有意义的自包含变更。
每一步是一个动作（2-5 分钟）：
每个计划必须以此头部开始：
# [功能名称] 实现计划
> **给代理工作者：** 必须调用的子 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"
```
编写完整计划之后：
评审循环指南：
保存计划后，提供执行选择：
"计划已完成并保存到 docs/plans/<filename>.md。两种执行选项：
1. 子代理驱动（推荐） — 每个任务派遣全新子代理，任务间评审，快速迭代
2. 内联执行 — 在当前会话中使用 executing-plans 执行任务，批量执行附带检查点
选择哪种方案？"
如果选择子代理驱动：
如果选择内联执行：
在进行任何创造性工作前必须使用——创建功能、构建组件、添加新功能或修改行为。在实现之前先探索用户意图、需求和设计。
TypeScript 和 React 开发的编码标准与最佳实践。在编写或审查代码时激活。提供命名、类型、组件设计、Hook 提取、状态管理等规范。
在用户确认要提交代码变更时使用——安全检查 diff 中的敏感数据后执行 git commit
在面对 2 个以上互不依赖、无共享状态的独立任务时使用
当有已编写的实现计划需要在独立会话中执行时使用，包含评审检查点
在实现完成、测试通过后，引导决定如何集成工作——提供合并、PR 或清理的结构化选项