核心循环

DWP 定义了一小组操作，让一份计划从目标走向完成、可审阅的工作：create → execute → refine → resume → status，并以 verify 作为确认结果的符合性核查。它们共同构成代理在一份计划的整个生命周期中所遵循的循环。代理一次执行一项任务，在继续之前验证每一步。

这个循环是规范驱动开发的运作形态。计划是代理依据其执行的规范，每项任务都带有明确的验收标准，而验证这一步则是把“声称已完成”转化为“完成之证据”的关卡。由于计划及其进展日志存在于代码仓库中，这个循环可以跨会话、跨代理恢复。

这些操作

方法论技能将意图委派给九项专门的子技能：六项核心执行操作、两项生命周期助手以及一个作者引擎：

• create —— 从目标生成新计划。代理分析目标并将其分解为连续任务后写出计划文件。在引导模式下直接物化紧凑内联的 Lite 计划，支持保留、晋升为 Full 计划或编辑；在 trust 模式下直接物化目标表现形式无需交互提问。需求分析和计划质量检查在两种模式下均会执行。
• execute —— 严格按顺序逐项执行任务。代理在每项任务后更新进展日志、运行验证关卡并在 git 中提交。在 trust 模式下可持续无人值守执行，任务之间无需交互确认。
• refine —— 修改现有计划（添加、编辑、拆分或重排任务，或将 Lite 计划晋升为 Full 计划），严格保全已完成证据并禁止未经确认地削弱验收标准。
• resume —— 恢复中断的计划。代理读取仅追加的日志与任务文件以重建状态，从第一项未完成的任务继续，绝不重复已完成的工作。
• status —— 汇报进展而不执行任何操作（严格只读）。汇总已完成、进行中和待处理的任务，不修改任何文件。
• verify —— 核查规范符合性而不改动任何内容（严格只读）。报告仓库是否达到 AI-first 标准以及各项任务是否具备明确标准与验证关卡。
• onboard —— 深入检视目标仓库以推理（而非机械复制）适配的 AGENTS.md、规范的 docs/ 层次、各模块文档以及带有兼容符号链接的 .agents/ 套件。
• upgrade —— 检查上游发布的版本，在下载前请求开发者明确同意，安装锁定的稳定标签并调和本地适配，现有 .dwp/ 计划始终保持原样。
• author —— 创建或演进符合仓库真实高频工作流的本地技能、代理或斜杠命令，并保持 .agents/docs/ 目录同步。

.dwp/ 输出目录

所有 DWP 产物都存放于代码仓库根目录下一个被 gitignore 的 .dwp/ 目录中。把工作区排除在版本控制之外，意味着一份计划的工作状态绝不会污染项目历史。仓库级别的插件配置记录在 .dwp/config.json（dwp-config/v1）中，计划则存放在扁平的编号目录内：

.dwp/
├── config.json
└── plans/
    └── PLAN_001_<slug>/
        ├── manifest.json
        ├── contract.json
        ├── journal.ndjson
        ├── state.json
        ├── README.md
        ├── PROGRESS.md
        ├── 1.task_<slug>.md
        ├── 2.task_<slug>.md
        └── analysis_results/

任务的十段式结构

任务文件

1. 01 标题
2. 02 上下文
3. 03 开始前必读
4. 04 目标
5. 05 涉及表面
6. 06 操作指南
7. 07 验收标准
8. 08 产出物
9. 09 验证
10. 10 执行清单与完成记录

每个任务文件都按顺序包含这十个段落。这一结构保证每个工作单元都自成一体且可审阅：

1. Goal（目标） —— 用一段文字陈述该任务达成了什么。
2. Context（上下文） —— 背景、链接，以及这项任务为何存在。
3. Touched Surface（触及面） —— 该任务改动之物与必须验证之物之间的契约。
4. Steps（步骤） —— 有序、具体、要执行的动作。
5. Acceptance criteria（验收标准） —— 一份界定“完成”的条件清单。
6. Validation（验证） —— 为核实工作而要运行的命令或测试。
7. Files（文件） —— 预计将被创建或修改的路径。
8. Dependencies（依赖） —— 其他任务或外部前置条件。
9. Risks（风险） —— 可能出错之处，以及缓解措施。
10. Completion & Log（完成与日志） —— 一个状态标记外加按时间顺序排列的记录。

验证、完成与恢复

验证是任务的一部分，而非事后补充：每项任务都点明证明其完成的命令或测试，代理在标记完成之前先运行它们。测试在此是头等大事——一项新增功能或改变行为的任务必须为该行为新增或更新自动化测试，并运行代码仓库完整的代码质量检查（测试外加 lint 与类型检查），而不仅仅是确认构建成功；现有测试必须保持通过，且应更新为预期的行为而非被跳过。安全与之同样是头等事项——任何触及认证、输入处理、机密、网络接触面或依赖的任务，都会在其验收标准中带上该变更的安全预期，并保持每次提交都不含机密，而每份计划都以 Final Review 作结——对整个变更集的安全审查、对最终状态的完整验证，以及对技能决策的核对。完成会在“完成与日志”段落中以一个明确的状态标记记录下来（[ ] 未开始、[~] 进行中、[x] 已完成、[!] 受阻）。恢复依赖于这些标记与进展日志——代理可以确切重建出计划停在何处，并从第一项未完成的任务继续，无需重做已完结的工作。

v6 与 v7：方法论不变，结构更加严格

当前 DWP 标准为 7.0.0，由 7.x 技能系列实现。该技能包默认使用 v7 创建每个新计划；明确的 v6 请求仍会生成 v6 计划。现有的 v1、v2、v5 和 v6 计划保留记录的代际，绝不会被静默迁移；将 v5 计划迁移到 v6 必须明确请求。

v6 保留相同的计划 → 任务 → 验证门 → 完成方法论、斜杠命令和 .dwp/plans/ 位置。它通过契约、日志、逐任务上下文清单、调度器以及拒绝空能力允许列表，强化了工程结构。v7 保留这一记录层，并新增可选的 parallel_safe 任务标记、用于记录交给另一个代理的有界工作的 delegation 日志事件，以及 .dwp/config.json 附加组件注册表；在未启用任何委托附加组件时，每个计划仍在当前会话中顺序运行。架构决策为 GO；尚未测量代理结果的经验性非劣效性。