前言¶

多步骤开发任务常见的失败模式：需求没定清楚就动手写代码，改完才发现验收标准不明；中间产物靠聊天窗口口口相传，会话一重启状态全丢；说”做完了”但没有可核对的文件证据。计划编排器针对这类问题，把需求分析、技术设计、实现、验证、质量审核拆成固定状态，逐个阶段验证产物后才推进。

这是什么¶

计划编排器是一个项目全生命周期管理引擎，用于系统化、流程化地执行软件工程任务，从分析需求、功能设计、任务计划、执行开发到审核验收全流程自动跟进。

• 坐标：@user_c4926d5a/reqplan-v3
• 版本：6.1.0
• 来源：community
• 分类：ai-agent
• 发布者：user_c4926d5a
• 标签：requires_api_key=false，不需要 API Key
• 官方地址：https://api.skillhub.cn/user_c4926d5a/reqplan-v3

与一次性让模型”开始写”的做法相比，区别在于：状态、产物和验证链落在文件里，而不是只存在于对话上下文中，因此可以跨会话接力。

核心功能¶

按固定状态机自动推进，无需用户逐一下令：

START → ANALYZE → CONFIRM → DESIGN → IMPLEMENT → VERIFY → JUDGE

配套规则：

1. 每个阶段必须验证产物，才能进入下一阶段。
2. 所有产物通过文件传递，禁止口头传递。
3. 用户必须在 CONFIRM 阶段确认后才能继续。
4. 每步回复第一行输出 当前状态：[状态名]，下一步：[操作]，让调用方随时知道进度。
5. 每步结束执行验证链检查，类型包括计数验证、列表验证、文件验证，用于防止”声称完成但文件不存在”这类虚假完成。
6. 当前状态记录在接力棒 .agent/harness/_baton.md，启动时读取该文件获取阶段状态。
7. 项目路径在开头确定；元任务走兜底规则，不以路径模糊为由跳过。

官方简介还提到”渐进式披露按需加载”，此说法出自简介文案，本次抓取的资料中没有更多细节可核对。

产出物¶

产物统一以文件形式落盘：

• _analysis.md：需求分析报告
• _design.md：技术设计文档
• _implementation.md：实现摘要
• _verification.md：验证报告
• _baton.md：接力棒状态
• _quality_audit_analysis.md / _quality_audit_design.md / _quality_audit_implement.md / _quality_audit_verify.md / _quality_audit_judge.md：各阶段质量审核报告

质量审核报告按阶段拆成五份，与状态机的阶段一一对应，审的是每个阶段的产物，而不是最后统一补一份总结。

何时用它¶

符合以下任一情况时启用：

• 用户说”帮我开发…”、”实现…功能”、”新增…”、”写个…”
• 用户说”帮我分析…”、”审查…”、”看看这个设计…”
• 用户说”出错了”、”报错了”、”修个Bug”、”修复…”
• 用户说”帮我规划…”、”怎么做…”、”有什么方案”
• 用户说”完善文档…”、”补充文档…”、”写文档…”
• 用户说”重构…”、”优化架构…”、”技术债务…”
• 用户说”测试…”、”写测试…”、”覆盖率…”
• 用户输入 /reqplan 命令
• 任何涉及多步骤、需要设计-实现-验证的复杂任务

以下情况不要用：

• 单次简单问答，例如”Python列表怎么排序”，不涉及多步骤任务规划。
• 纯聊天对话，无具体任务目标。
• 纯粹的信息查询，例如”React 18 新增了什么”，不需要代码产出。
• 用户仅要求查看或浏览代码，无需分析、修改或设计。
• 需求极度模糊且用户拒绝澄清，无法确定任务边界。
• 目标与范围已固定，只需单次代码修改，不涉及多阶段协作。

安装与启用¶

本次抓取的资料中没有给出安装命令、目录要求或配置字段，也没有 Cursor / Codex CLI / Claude Code 的差异化说明，因此这里不臆造。启用方式请以官方页面为准：

https://www.skillhub.cn/skills/user_c4926d5a/reqplan-v3

该 Skill 基于通用 SKILL.md 格式，接入时需要确认目标编辑器支持该格式，并按平台要求指定 Skill 路径或坐标 @user_c4926d5a/reqplan-v3。

典型用法¶

以一个常见的多阶段请求为例，用户输入：

/reqplan 帮我实现用户登录功能

实际执行流程如下：

1. 确定项目路径；如果是元任务，走兜底规则，不因路径模糊而跳过。
2. 读取 .agent/harness/_baton.md，拿到当前阶段状态。
3. 进入 ANALYZE，产出 _analysis.md，并做一次验证链检查。
4. 进入 CONFIRM，等待用户确认；未确认前不继续推进。
5. 用户确认后进入 DESIGN，产出 _design.md，附带 _quality_audit_design.md。
6. 依次进入 IMPLEMENT、VERIFY、JUDGE，每个阶段都落盘对应产物和质量审核报告。
7. 每步回复首行按 当前状态：[状态名]，下一步：[操作] 的格式输出。

上面的步骤顺序来自该 Skill 的工作原理描述，不是一次真实执行记录。

注意点¶

适合需要”设计—实现—验证”闭环的任务，尤其是跨会话、跨阶段较长、容易在中途失焦的工作。代价是流程本身有开销：每个阶段都要等验证通过，CONFIRM 阶段还要等用户确认。目标明确、改动只有一行的情况，直接改更省事。

运行前需要准备好项目路径，否则会卡在第一步；接力棒文件缺失时，需要重新确定起点。

结尾¶

计划编排器的价值在于把”是否做完”变成可核对的文件证据，而不是模型的一句话。它不替代设计与编码判断，只是把多步骤任务的推进顺序固定下来。

• SkillHub 页面：https://www.skillhub.cn/skills/user_c4926d5a/reqplan-v3
• 接口地址：https://api.skillhub.cn/user_c4926d5a/reqplan-v3

指标说明：评分 100000，分类 ai-agent。下载量在线索与抓取资料中不一致（线索写 352，抓取资料写 755），本文采用抓取资料的 755，安装数为 0。这些数字以官方页面实时显示为准。