agentleFS
zieang88888zieang88888/zhskills/skills/execution-plan/SKILL.md

execution-plan

Skill1 starsChanged 46 days agoMITView on GitHub

给定一份需求/规格,写出一份对零上下文执行者也友好的分步执行计划书 Markdown(含目标、范围、全局约束、关键检查点、交付物责任结构图、逐任务分步动作与验收标准)。当用户需要项目排期、工作计划、活动执行方案、任务拆解,并希望产出可直接交付的分步计划时使用。

2 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Files
SKILL.md

执行计划书 · execution-plan

二次开发:本技能改编自 obra/superpowers 的 writing-plans(MIT © 2025 Jesse Vincent),在保留其核心方法论基础上,升级为「提示词 + 可执行 CLI」双形态。署名见本目录 NOTICE.md 与仓库 THIRD_PARTY_NOTICES.md。

这个技能做什么

把一份需求 / 规格 / 任务说明,拆解成一份对零上下文执行者也友好的分步执行计划书 Markdown。执行者不需要看过原始讨论、不需要知道你做了哪些取舍,照着计划一步步做就能交付结果。

适用于中文职场场景:项目排期、工作计划、活动执行方案、跨部门任务拆解。

输入要求

  • 必填:需求 / 规格 / 任务说明文本(直接粘贴,或 .txt / .md 文件路径)。
  • 可选:项目背景、截止时间、预算范围、团队分工、既有流程规范——有则更准确,无则从需求中推断并标注"(推断)"。
  • 需求可能很长、很散、口语化;本技能负责把它收敛成结构化计划,而不是原文搬运。

输出结构(模板见 scripts/templates/execution-plan.template.md)

  1. 文档头:
    • 目标:一句话说明本计划要达成什么结果。
    • 范围:本计划覆盖什么、不覆盖什么。
    • 全局约束:项目级硬性要求(时间、预算、合规、命名规范、平台限制等),逐条列出,精确数值照抄需求原文。每个任务自动继承这些约束。
    • 关键检查点:需求没明说、但执行者最容易踩坑的输入或情况——逐条写出"什么情况 + 期望行为",按最可能出问题的顺序排列。这些检查点必须逐条落实到对应任务的验收标准里。
  2. 交付物责任结构图:在拆任务之前,先画清楚要产出哪些交付物、各自归谁负责、依赖哪些上游交付物。这是边界锁定的地方——每个交付物职责单一、接口明确。
  3. 任务列表:每个任务包含:
    • 交付物:本任务完成后独立产出什么。
    • 接口:输入(从前面任务拿什么)、输出(后续任务依赖什么)。
    • 分步动作:用 - [ ] 勾选框跟踪,每步一个动作、一个可检查的结果。
    • 里程碑交付:任务收尾时的验收标准(替换原方法论中的"commit")。
  4. 自检结论:写完后做四项自检(见质量规则),在文末简要列出发现并修正了什么。

工作流程

  1. 范围检查:先判断需求是否覆盖多个独立子系统。如果是,建议拆成多份计划——每份计划单独产出可交付的成果,不要硬塞进一份。
  2. 画交付物责任结构图:列出所有要产出的交付物,标注责任方和依赖关系,锁定边界。
  3. 切分任务:每个任务自带可独立验收的交付物;粒度小到每一步都能独立验收。把准备工作、配置、脚手架、文档折叠进需要它们的那个任务里,不单独成任务。
  4. 写步骤:每步只做一个动作、产生一个可检查的结果。验收步骤写清"做什么 + 看到什么算过"。
  5. 补关键检查点:对照需求,找出需求没写但最容易踩的坑(预算超支、审批流程遗漏、对外沟通口径不一致、数据格式不兼容、权限不足等),逐条写成检查点,并落实到对应任务的验收标准里。
  6. 四项自检:需求覆盖、占位符扫描、跨任务一致性、检查点是否落验。发现问题就地修正。

质量规则(必须遵守)

  • 无占位符铁律:禁止出现 TBD、TODO、"适当处理边界情况"、"同任务 N"、"按上述方式"等偷懒写法。每一步都必须写清楚具体做什么、产出什么、怎么验收。
  • 每步可独立验收:每个任务结束时有一个独立可检验的交付物;每个步骤有一个明确的完成标志。
  • 接口写死:任务之间的输入输出必须写清具体名称、格式、数值,不让执行者猜。
  • 全局约束逐条照抄:需求里的硬性数值(截止日期、预算上限、版本要求等)原样复制,不改写、不概括。
  • 检查点必须落验:文档头列出的每个关键检查点,都必须在某个任务的步骤里有对应的验收动作;不能只列不管。
  • 不确定就标注:需求没说清但计划需要做决定的地方,写"(待确认)"并说明需要谁确认,不替用户拍板。
  • 计划不是代码转录:计划是执行者无法独自做出的决策集合;如果计划比需求本身还长很多,说明写过头了,把冗余的实现细节换成接口签名和验收标准。

边界与异常处理

  • 需求跨多子系统:建议拆分多份计划,每份独立可交付;不强行合并。
  • 需求信息不足:在计划中标注"(待确认)",并列出需要补充的信息,不编造假设。
  • 任务之间有循环依赖:在交付物责任结构图中标注,并建议调整顺序或引入中间交付物解耦。
  • 需求本身矛盾:在自检结论中指出矛盾点,标注需要决策的位置,不擅自选边。
  • 需求过短或过于笼统:先反问补充关键信息(目标、约束、验收标准),信息实在不足时按最常见职场场景补默认值并标注"(推断)"。

与脚本配合

  • 批量 / 命令行场景:scripts/draft_execution_plan.py(纯标准库,一条命令跑通)。
  • 自定义模板:复制 scripts/templates/execution-plan.template.md 修改后使用。

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.