Skills 技能库- JulyCode

在编写代码之前，如果您已经有了多步骤任务的规范或要求，请使用此方法。

npx skills add https://github.com/obra/superpowers/tree/main/skills/writing-plans

技能.md

写作计划

概述

编写全面的实施计划，假设工程师对我们的代码库一无所知，而且审美也值得怀疑。记录他们需要了解的一切：每个任务需要修改哪些文件、代码、测试、可能需要查阅的文档以及测试方法。将整个计划分解成易于执行的小任务。遵循 DRY（Don't Repeat Yourself，不要重复自己）原则。遵循 YAGNI（You Aigns No I，你不需要它）。遵循 TDD（测试驱动开发）。频繁提交。

假设他们是一位技术娴熟的开发人员，但对我们的工具集或问题领域几乎一无所知。假设他们对优秀的测试设计也知之甚少。

开场白： "我将运用计划撰写技能来制定实施计划。"

背景： superpowers:using-git-worktrees如果在隔离的工作树中工作，则应该在执行技能时创建。

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

（用户自定义的计划位置会覆盖此默认设置）

范围检查

如果规范涵盖多个独立子系统，那么在头脑风暴阶段就应该将其拆分为子项目规范。如果没有，建议将其拆分为单独的计划------每个子系统一个计划。每个计划都应该能够独立生成可运行、可测试的软件。

文件结构

在定义任务之前，先规划好哪些文件将被创建或修改，以及每个文件负责什么。这是确定任务分解方案的关键一步。

设计单元应具有清晰的边界和明确的接口。每个文件应承担一项明确的职责。
你最擅长处理那些能够一次性理解其上下文的代码，而且当文件处于焦点状态时，你的编辑也更可靠。比起功能过多的大型文件，最好选择较小且功能明确的文件。
共同变更的文件应该放在一起。按职责划分，而不是按技术层划分。
在现有代码库中，遵循既定模式。如果代码库包含大型文件，不要单方面进行重构------但如果您正在修改的文件变得过于庞大，那么在计划中加入拆分是合理的。

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

任务规模合理化

任务是最小的单元，它拥有自己的测试周期，值得一位

新的评审员审核。在划定任务边界时：将设置、

配置、脚手架搭建和文档编写步骤归入需要这些步骤的任务中；只有当评审员可以合理地拒绝一个任务而批准其相邻任务时，

才应将其拆分。每个任务最终都应交付一个可独立测试的成果。

精细化任务粒度

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

"编写失败的测试"------步骤
"运行它以确保它失败"------步骤
"实现使测试通过所需的最小代码量"------步骤
"运行测试并确保它们通过"------步骤
"提交"步骤

计划文件页眉

所有计划都必须以这个标题开头：

bash 复制代码

# [Feature Name] Implementation Plan

> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking.

**Goal:** [One sentence describing what this builds]

**Architecture:** [2-3 sentences about approach]

**Tech Stack:** [Key technologies/libraries]

## Global Constraints

[The spec's project-wide requirements --- version floors, dependency limits,
naming and copy rules, platform requirements --- one line each, with exact
values copied verbatim from the spec. Every task's requirements implicitly
include this section.]

---

任务结构

bash 复制代码

### Task N: [Component Name]

**Files:**
- Create: `exact/path/to/file.py`
- Modify: `exact/path/to/existing.py:123-145`
- Test: `tests/exact/path/to/test.py`

**Interfaces:**
- Consumes: [what this task uses from earlier tasks --- exact signatures]
- Produces: [what later tasks rely on --- exact function names, parameter
  and return types. A task's implementer sees only their own task; this
  block is how they learn the names and types neighboring tasks use.]

- [ ] **Step 1: Write the failing test**

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

- [ ] **Step 2: Run test to verify it fails**

Run: `pytest tests/path/test.py::test_name -v`
Expected: FAIL with "function not defined"

- [ ] **Step 3: Write minimal implementation**

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

- [ ] **Step 4: Run test to verify it passes**

Run: `pytest tests/path/test.py::test_name -v`
Expected: PASS

- [ ] **Step 5: Commit**

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

无占位符

每一步都必须包含工程师实际需要的内容。以下是一些计划失败的例子------千万不要写这些：

待定，待办，稍后实施，填写详情
"添加适当的错误处理"/"添加验证"/"处理极端情况"
"为上述内容编写测试"（不包含实际测试代码）
"与任务 N 类似"（重复代码------工程师可能阅读任务顺序有误）
描述操作步骤，但不展示具体操作方法（代码步骤需要代码块）
引用未在任何任务中定义的类型、函数或方法

记住

始终使用精确的文件路径
每一步都要写出完整的代码------如果某一步修改了代码，请显示出来。
包含预期输出的确切命令
DRY（Don't Repeat Yourself，不要重复自己）、YAGNI（You Agni，你不需要它）、TDD（测试

自我评价

完成所有计划后，请以全新的视角审视规范，并对照规范检查计划。这是一份需要您亲自执行的检查清单，而不是外包给其他代理商的。

**1. 规范覆盖率：**快速浏览规范中的每个章节/要求。你能指出一个实现了该要求的任务吗？列出所有遗漏之处。

**2. 占位符扫描：**检查您的计划是否存在危险信号------即上面"无占位符"部分中提到的任何模式。修复它们。

**3. 类型一致性：**后续任务中使用的类型、方法签名和属性名称是否与之前任务中定义的一致？clearLayers()任务 3 中调用的函数clearFullLayers()在任务 7 中仍然被调用，这是一个错误。

如果发现问题，请直接修复。无需重新审核------只需修复即可继续。如果发现某个规范要求没有对应的任务，请添加该任务。

执行交接

保存计划后，提供执行选项：

计划已完成并保存docs/superpowers/plans/<filename>.md。有两种执行选项：

1. 子代理驱动（推荐） ------我为每个任务调度一个新的子代理，任务间进行审查，快速迭代

2. 内联执行- 使用执行计划、带检查点的批量执行方式，在本会话中执行任务

哪种方法？

如果选择子代理驱动：

**必备子技能：**运用超能力：子代理驱动开发
每个任务配备一名新的子代理人 + 两阶段审核

如果选择内联执行：

**必备子技能：**运用超能力：执行计划
带有检查点的批量执行以供审核