en un clic
writing-plans
在编写代码之前使用,当你有规范或需求用于多步骤任务时
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Menu
在编写代码之前使用,当你有规范或需求用于多步骤任务时
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
桌面/网关运行时内置的计划创建技能,用于生成可落盘、可调度、可批次执行的结构化计划包。
桌面/网关运行时内置的计划执行技能,用于按批次执行结构化计划包中的单个任务文件。
Use when demonstrating or verifying VibeWindow local plugin packaging, including plugin skills, MCP servers, hook declarations, and interface metadata.
当需要在编码前创建或更新实施计划时使用,尤其适用于多步骤功能开发、重构、包含多个活动部件的缺陷修复,或需要拆分为可独立执行并跟踪进度的任务文件的请求。
当你有书面实现计划需要在单独会话中执行,并带有审查检查点时使用
通过 `rustcodegraph` 命令行界面使用 RustCodeGraph 理解、导航或脚本化操作已索引代码库。当用户要求使用 RustCodeGraph、需要高性能搜索检索代码、需要符号/源码/调用流上下文、调用方/被调用方/影响分析或受影响测试选择时使用。
| name | writing-plans |
| description | 在编写代码之前使用,当你有规范或需求用于多步骤任务时 |
编写全面的实施计划,假设工程师对我们的代码库零上下文,且品味存疑。记录他们需要知道的一切:每个任务要接触哪些文件、代码、测试、可能需要检查的文档、如何测试。将整个计划以小任务形式提供给他们。DRY。YAGNI。TDD。频繁提交。
假设他们是熟练的开发者,但几乎不了解我们的工具集或问题领域。假设他们不太了解良好的测试设计。
开始时声明:"我正在使用 writing-plans 技能来创建实施计划。"
**上下文:**这应该在专用的工作树(由 brainstorming 技能创建)中运行。
计划保存至: docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md
-(用户对计划位置的偏好覆盖此默认值)
如果规范涵盖多个独立子系统,则应该在头脑风暴期间将其分解为子项目规范。如果没有,建议将其拆分为单独的计划——每个子系统一个。每个计划都应该独立产生可工作、可测试的软件。
在定义任务之前,规划哪些文件将被创建或修改,以及每个文件的职责。这是分解决策被锁定的地方。
这个结构为任务分解提供依据。每个任务应该产生有意义的、独立可理解的更改。
每个步骤是一个动作(2-5分钟):
每个计划必须以此头开始:
# [功能名称] 实施计划
> **对于代理工作者:**必需子技能:使用 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`
预期:失败,显示"function not defined"
- [ ] **步骤 3:编写最小实现**
```python
def function(input):
return expected
```
- [ ] **步骤 4:运行测试以验证它通过**
运行:`pytest tests/path/test.py::test_name -v`
预期:通过
- [ ] **步骤 5:提交**
```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。
如果你发现问题,请就地修复。无需重新审查——只需修复并继续。如果你发现没有任务的规范要求,请添加任务。
保存计划后,提供执行选择:
"计划完成并保存至 docs/superpowers/plans/<filename>.md。两个执行选项:
1. 子代理驱动(推荐) - 我为每个任务调度一个新的子代理,任务之间审查,快速迭代
2. 内联执行 - 在此会话中使用 executing-plans 执行任务,带有审查检查点的批量执行
哪种方法?"
如果选择子代理驱动:
如果选择内联执行: