plan

结构化规划

制定一份计划，让另一个会话无需重新探究决策即可执行并验证。明确说明结果和依赖关系，避免偏离目标，同时将实现选择留给代码和执行过程中发现的证据。

用户的指示优先于本技能的指南。规划不会额外要求审批。如果执行已获授权，计划就绪后继续；如果用户只要求计划，则仅提交计划，不开始实施。

根据不确定性确定计划规模

工作类型	规划深度
明确、可逆且有直接检查方式的改动	通过简短的思考或内联计划后执行
存在多项依赖行为且模式已知	记录任务、接口和验收检查
架构或迁移存在不确定性	弄清关键未知因素，并规划一个有代表性的纵向切片
涉及多个 Agent、会话或环境的工作	保留负责人、状态、依赖关系和恢复指引

文件数量并不能有效衡量风险。与跨多个文件的机械重命名相比，一行授权变更可能需要更多分析。规划应足以揭示不确定或不可逆的部分，而不必预测每一处编辑。

确认实际起点

检查仓库状态、相关差异和所讨论的代码路径。找到现有实现模式，以及脚本、钩子或 CI 中实际使用的验证命令。如果已配置，请通过已安装的 Sibyl 技能读取相关项目记忆。

记录约束执行的事实：

• 可观察到的用户或系统结果。
• 当前检查的基线以及修订版本或环境。
• 受影响的接口、所有权和兼容性要求。
• 可能使拟议工作失效的不确定因素。
• 明确的约束、非目标和用户更正。

将继承的计划视为假设。执行前重新核实其中影响重大的主张是否符合当前代码树。区分已核实的事实、待检查的假设和已过时的前提。如果某个前提不成立，应更新计划本身；只留下单独的评论会让执行者继续遵循过时指示。

选择有用的切片

在拆解并构建新机制之前，先查找能满足请求的现有能力。简化必须保留所请求的结果。不要用一个方便展示底层机制的示例，替代困难的产品目标。

如果纵向切片能尽早证明可行性，就优先选择它来贯穿不确定的边界：让真实输入经过变更后的逻辑，到达需要它的使用方。规划迁移时，应围绕兼容性和部署顺序展开。源文件顺序不能决定安全的发布顺序。

将实现及其行为验证放在同一个责任明确的任务中。标题里包含“和”，并不能证明任务应该拆分。只有当任务的结果可独立审查、负责人不同或存在实际依赖边界时，才应拆分。测试基础设施的前置工作可以单独安排；功能测试不应成为无人负责的后续任务。

为每项任务制定可执行的契约

只使用任务所需的字段：

字段	内容
结果	交付的行为或产物
范围	已知文件／模块及允许的扩展规则
依赖项	所需输入或接口及其提供方
验证	可准确运行的检查及其证明的行为
完成证据	预期的产物、断言、观察结果或报告
风险与恢复	重要时列出兼容性、回滚或尚未解决的外部依赖

示例：

### Task: Reject expired sessions at the request boundary

Outcome: An expired session receives the established unauthorized response.
Scope: The session validator and its request-level tests.
Depends on: The existing clock injection interface, confirmed in the repo.
Verify: [repository's exact focused test command].
Cases: Expired, valid, and boundary-time sessions preserve expected behavior.
Completion: Tests exercise the request path and report executed cases.

已知时优先使用真实文件路径；对于建议的路径，应明确标注为建议路径，不要假装已完成探索。可复制的命令仍需附带断言：“能够渲染”并不能证明生成的策略与预期资源相符。

梳理依赖关系和所有权

并行处理相互独立的结果。文件分离有助于避免冲突，但不能证明任务相互独立：两个模块可能共用一个架构、生成文件、测试数据库、端口或输出目录。明确列出这些共享资源及其所有者。

选择依赖项已就绪的工作，不要强行让所有任务同步分波执行。只有在任务共享重要的集成检查点时，分波才有用。指定集成负责人，并在分支或补丁合并后验证整体行为。若委派能提升效率且当前指令允许，请参考 orchestrate。

检查计划是否遗漏使用方、是否存在不兼容的发布状态，以及范围是否不必要地扩大。对于影响重大的架构或策略，在有要求或确有必要时征求独立评审。评审应聚焦于尚未解决的决策。只有当新证据或具体缺陷能改进计划时，更多轮评审才有用；仅有分歧不足以成为无限修改的理由。

制定可恢复的计划

使用项目的规范跟踪工具或约定的产物位置。使用 Sibyl 时，请通过其已安装的技能获取当前任务和记忆命令。避免在聊天、仓库文件和记忆中重复完整计划；应选定一个权威计划，并在跟踪工具中添加指向它的链接。

不要仅仅因为工作跨越多个会话就创建或提交规划文档。遵循仓库对临时文件和规划产物的规定。如果必须创建文档，请将其放在后续 Agent 实际能够访问的位置；如果委派任务的检出内容不包含未跟踪的上下文，也要在委派说明中提供这些信息。

有用的检查点应记录当前修订、已完成的结果及其证据、当前负责人、待决事项和确切的下一步。保留用户的更正，以免它们在压缩上下文时丢失。恢复工作时，重新阅读检查点并检查实时状态；记录描述的是过去的状态，不保证反映当前情况。

调整计划而不偏离目标

当实现过程暴露出新的约束时，修改受影响的任务，并说明它对结果、依赖项或风险的影响。将更正落实到表格和验收标准中，而不只是修改相关段落。只有在被否决方案的理由有助于未来决策时，才保留这些方案。

在集成边界处，将累积的差异与预期结果进行比较。即使测试通过，范围也可能已经偏离。评审力度应根据变更风险和覆盖范围调整，而不是根据任务编号或此前通过的任务数量决定。后期工作仍必须执行项目要求的验证。

只有在所需证据齐备时，才将工作标记为已完成。应单独报告无法通过的外部关卡，不要与已完成的本地检查混为一谈，并说明确切的阻碍因素和下一步行动。记录阻塞状态时，应遵循宿主的任务状态规则；本技能不会重新定义这些规则。

证据与局限

审阅日期：2026-09-04。Anthropic 的2026 年 3 月 harness 报告介绍了以结果为导向的规范和协商确定的验证标准，同时指出，反复评估也可能增加实现复杂度。这是一项工程案例研究，并不能证明每个项目都需要规划器-生成器-评估器流水线。

这里的流程运用了这一区分：保留可测试的约定，并调整执行路径。评估规划变更时，应考察由此产生的工作和纠正成本，而不是计划的篇幅。

反模式

反模式	更好的做法
阅读代码前就精确预测要修改的内容	明确已验证的边界和不确定的细节
将每项功能与其测试完全拆开	由同一负责人对交付的行为负责
仅根据文件名进行并行处理	检查共享接口和运行时资源
获准构建后仍要求审批	在现有范围内继续执行
因任务延期而降低审查标准	根据当前风险和证据匹配审查力度
维护多份相互竞争的进度记录	保留一份权威计划，并附上相关凭据
覆盖成功所需工作后仍继续拆分	开始执行；证据改变工作内容时再重新规划

这项技能不是什么

• 不适用于琐碎工作，也不设固定的文件数量门槛。
• 不代表可以执行仅要求制定计划的请求。
• 不保证初始架构、时间安排或任务列表不会改变。