莫的 Skills 精品 Hubskills.miemie
安装热度榜

writing-plans

obra/superpowers 中的 writing-plans 技能，用于在动手写代码之前，为多步骤任务编写结构化的实施计划。计划面向一位没见过该代码库、也没读过规格说明的工程师：假定对方掌握项目语言并会写出符合习惯的代码，凡是其无法自行得知的决策——涉及哪些文件、命名与签名、规格中的哪些取值、由哪些测试证明每个任务——都要在计划中写明。计划以可勾选的小任务形式交付，遵循 DRY、YAGNI、TDD 与频繁提交。内容涵盖：范围检查（若规格横跨多个独立子系统则建议拆分为多份计划）；文件结构规划（按职责而非技术分层拆分，每个文件单一职责）；任务粒度（任务是最小自带测试周期、值得独立评审的单位）；步骤粒度（每个步骤只做一个动作并可检验，如写失败测试、运行确认失败、实现最小代码、运行确认通过、提交）；计划文档的固定头部（Goal、Architecture、Tech Stack、Spec 路径、Global Constraints、Review Focus）；随后是对照规格的自审清单（规格覆盖、步骤扫描、类型一致性、Review Focus、篇幅比例）；最后是执行交接，要求人类先评审计划，并在未指定执行方式时选择子代理驱动或原生执行。计划默认保存到 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md。

分类
Agent 工作流
榜单排名
#247
安装量
265,363

它能做什么

中文摘要

obra/superpowers 中的 writing-plans 技能，用于在动手写代码之前，为多步骤任务编写结构化的实施计划。计划面向一位没见过该代码库、也没读过规格说明的工程师：假定对方掌握项目语言并会写出符合习惯的代码，凡是其无法自行得知的决策——涉及哪些文件、命名与签名、规格中的哪些取值、由哪些测试证明每个任务——都要在计划中写明。计划以可勾选的小任务形式交付，遵循 DRY、YAGNI、TDD 与频繁提交。内容涵盖：范围检查（若规格横跨多个独立子系统则建议拆分为多份计划）；文件结构规划（按职责而非技术分层拆分，每个文件单一职责）；任务粒度（任务是最小自带测试周期、值得独立评审的单位）；步骤粒度（每个步骤只做一个动作并可检验，如写失败测试、运行确认失败、实现最小代码、运行确认通过、提交）；计划文档的固定头部（Goal、Architecture、Tech Stack、Spec 路径、Global Constraints、Review Focus）；随后是对照规格的自审清单（规格覆盖、步骤扫描、类型一致性、Review Focus、篇幅比例）；最后是执行交接，要求人类先评审计划，并在未指定执行方式时选择子代理驱动或原生执行。计划默认保存到 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md。

为什么推荐

推荐理由

如果你已经有一份规格或需求，却常在没有计划的情况下直接改代码，这个技能把“动手前先固定决策”变成一套有输出路径、有步骤格式、有自审清单的流程。它特别强调计划只记录实施者无法独自决定的取舍（文件、签名、规格取值、验证测试），并明确反对把计划写成代码誊本，因此适合需要把设计意图交给他人或子代理逐任务执行的场景。

什么时候用

适用场景

  • 已有规格说明或需求，需要把它拆成一份可逐任务执行的多步骤实施计划
  • 要开始一个复杂任务、还没碰代码，需先确定涉及哪些文件、接口、签名与验证测试
  • 需要把计划交给另一位工程师或子代理独立实施，且对方看不到原始代码库和规格
  • 希望计划能被人类评审后再选择执行方式（子代理逐任务实现并评审，或由当前会话原生实现）
  • 想用自审清单检查计划是否覆盖规格、步骤是否无歧义、前后任务类型命名是否一致

使用前先看

主要亮点

  • 01

    面向没见过该代码库与规格的工程师编写计划，要求写明文件、命名与签名、规格取值以及证明每个任务的测试

  • 02

    步骤粒度为单一动作且结果可检验：写失败测试、运行确认失败、实现最小代码、运行确认通过、提交

  • 03

    规定每份计划必须以固定头部开头，包含 Goal、Architecture、Tech Stack、Spec 路径、Global Constraints 与 Review Focus

  • 04

    提供对照规格的自审清单五项：规格覆盖、步骤扫描、类型一致性、Review Focus、篇幅比例

  • 05

    计划默认保存到 docs/superpowers/plans/YYYY-MM-DD-<feature-name>.md，用户偏好可覆盖

  • 06

    任务结构包含 Files（Create/Modify/Test 精确路径）与 Interfaces（Consumes/Produces 的精确签名）

  • 07

    范围检查要求：若规格覆盖多个独立子系统，应拆为相互独立的计划，每份都能产出可工作、可测试的软件

  • 08

    执行交接在未指定方式时提供子代理驱动（逐任务新子代理实现加新评审）与原生（当前会话实现、末尾一次评审）两种选择，并要求人类先评审计划

  • 09

    开始执行时要求声明：Announce at start: "I'm using the writing-plans skill to create the implementation plan."

原始文档

原文摘录

Writing Plans Overview Write implementation plans for an engineer who has not seen this codebase or this spec. Assume they write idiomatic code in the project's language once they know the exact interface and the exact test, and that they will make a reasonable choice wherever the plan leaves one open. What they cannot know is what you decided: which files, which names and signatures, which values from the spec, which tests prove each task. Document those. Give them the whole plan as bite-sized