القائمة
Use when 已有经批准的设计/规格说明、多步骤实施任务，在动代码之前需要可执行任务清单时。触发场景：写实施计划、拆解开发任务、implementation plan、执行计划文档、任务拆分、按 TDD 步骤写计划。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
超压缩通信模式。通过去掉废话、冠词和客套语，在保持完整技术准确性的同时削减约 75% token 用量。 当用户说"caveman 模式"、"简洁模式"、"少废话"、"省 token"、"简短点"或调用 /caveman 时触发。
对用户的计划或设计进行不留情面的深度追问，直到达成共同理解，逐一解决决策树的每个分支。当用户想要压力测试计划、检验设计时触发。触发词：追问我、grill me、逐一问我、挑战我的方案、深度追问、质疑设计、设计评审追问。
将当前对话压缩为交接文档，供下一个 Agent 会话接续工作。触发词：交接、handoff、下一个会话、会话摘要、接续工作、传给下一个 agent。
在代码库中发现架构"深化"机会——将浅模块变成深模块的重构，提升可测试性和 AI 可导航性。与 architecture-advisor 互补：architecture-advisor 设计新架构，本技能改善现有代码库结构。触发词：改进代码库架构、架构深化、找重构机会、模块耦合太紧、难以测试、代码难以理解、架构改进、improve architecture、refactor opportunities。
快速验证设计的一次性原型。区分两条分支——逻辑/状态模型用终端交互 App，UI 布局用多变体路由切换。当用户想原型验证、检验数据模型或状态机、探索多种 UI 方案时触发。触发词：原型、prototype、验证方案、快速试验、让我玩一玩、试几个设计。
Use when 已有书面实施计划、任务相对独立，且在本会话内通过子代理逐任务落实时。触发场景：执行实施计划、子代理开发、按计划实现、Task 派发实现、两阶段代码审查、plan execution。
| name | writing-plans |
| description | Use when 已有经批准的设计/规格说明、多步骤实施任务，在动代码之前需要可执行任务清单时。触发场景：写实施计划、拆解开发任务、implementation plan、执行计划文档、任务拆分、按 TDD 步骤写计划。 |
在已获用户批准的设计文档（例如方案设计师产出的 docs/specs/…-设计.md）基础上，编写可交给代理或工程师逐步执行的实施计划。假设执行者对代码库与领域几乎零上下文、测试习惯一般：计划中必须写明路径、命令、完整代码块与预期输出。遵循 DRY、YAGNI、TDD、小步提交。
开场声明：「我正在使用实施计划编写技能生成实施计划。」
保存路径（默认）： docs/specs/plans/YYYY-MM-DD-<功能简述>.md
（若用户或项目已有约定路径，以约定为准。）
可选上下文： 大功能建议在独立分支或 git worktree 上实施；若用户未准备，在计划头注明即可，不阻塞写计划。
pytest/npm test/go test 等）。references/plan-template.md）。TODO/TBD/适当/稍后补充），每步必须可执行（路径/命令/预期输出齐全）。../code-review-expert/references/quality-gates-checklist.md。subagent-driven-development（子代理驱动开发）：按计划逐任务执行code-review-expert（代码审查专家）：最终质量门禁/收尾审查tdd-master（TDD 开发大师）：执行阶段遵循 RED-GREEN-REFACTOR 节奏若规格仍包含多个可独立交付的子系统，应退回方案阶段拆成多份子规格；若未拆，则建议多份实施计划（一子系统一份），每份计划都能单独产出可运行、可测试的软件。
在写任务前，先列出将创建/修改的文件及职责，作为分解依据：
每一步对应一个可完成动作（约 2–5 分钟）：
每一份计划必须以如下头部开头：
# [功能名] 实施计划
> **给代理执行者：** 推荐配合 `subagent-driven-development（子代理驱动开发）`（每任务独立子代理 + 两阶段审查）或在本会话内按勾选逐步执行并在批次节点与用户确认。任务使用 `- [ ]` 勾选跟踪。
**目标：** [一句话说明交付什么]
**架构要点：** [2–3 句]
**技术栈：** [主要语言/框架/测试命令]
**关联设计文档：** `docs/specs/…-设计.md`（路径按实际填写）
---
### 任务 N：[组件或主题名]
**涉及文件：**
- 新建：`exact/path/to/file.py`
- 修改：`exact/path/to/existing.py`（可注行号范围）
- 测试：`tests/exact/path/to/test_xxx.py`
- [ ] **步骤 1：编写失败测试**
```python
def test_具体行为():
result = function(输入)
assert result == 期望
```
- [ ] **步骤 2：运行测试确认失败**
运行：`pytest tests/path/test.py::test_具体行为 -v`
预期：失败（例如 NameError / 断言失败，写明预期信息）
- [ ] **步骤 3：最小实现**
```python
def function(输入):
return 期望
```
- [ ] **步骤 4：运行测试确认通过**
运行：`pytest tests/path/test.py::test_具体行为 -v`
预期：通过
- [ ] **步骤 5：提交**
```bash
git add …
git commit -m "feat: …"
```
（语言与测试命令按项目替换：如 npm test、go test、cargo test 等。）
以下情况禁止出现在最终计划中：
TBD、TODO、稍后补充、实现时再想写完计划后快速过一遍：
TODO、适当、类似 等红线词并修正。若计划规模大或风险高，可在保存前派发审查子代理，模板见 references/plan-document-reviewer-prompt.md。
保存计划后，向用户说明执行方式并二选一（或用户指定）：
subagent-driven-development（子代理驱动开发）。tdd-master（TDD 开发大师） 的红绿重构；关键节点用 code-review-expert（代码审查专家） 做质量门禁。禁止在未获用户同意时在 main/master 上直接开始实施（若计划针对默认分支，须在计划中或交接时明确分支策略）。
| 技能 | 关系 |
|---|---|
brainstorming（方案设计师） | 本技能的上游：输入为已批准的设计文档 |
subagent-driven-development（子代理驱动开发） | 本技能的推荐执行方式 |
tdd-master（TDD 开发大师） | 子代理或本会话实施时的测试节奏依据 |
code-review-expert（代码审查专家） | 全量收尾或子代理流程中的质量审查依据 |
prd-engineer（需求工程师） | 偏 PRD/问题域；本技能偏工程切片与文件级步骤，二者可衔接但职责不同 |