deepworkplan

DeepWorkPlan — 方法论技能（路由器）

模型很重要；上下文更重要。DeepWorkPlan 技能将任何代码仓库转化为结构化环境——包含上下文、护栏和持久计划——让任何编码 Agent 都能可靠地执行短期或长期工作。它让代码仓库成为「AI 优先」——AGENTS.md + docs/ + 各模块文档 + .agents/（带有 .claude → .agents 和 .cursor → .agents 符号链接）——并运行结构化的 Deep Work Plans：针对范围明确的工作使用 Lite 计划，针对较长工作使用 Full 任务文件计划；AI Agent 会创建、完善计划，逐项执行并在之后恢复。所有计划输出都存放在代码仓库根目录下被 git 忽略的 .dwp/ 目录中（.dwp/plans/）。

权威信息来源：https://deepworkplan.com。许可证：MIT。

从这里开始（首次运行）

此技能是一个自给自足的入口：无论开发者是通过 https://deepworkplan.com/init.md 进入，还是仅仅安装此技能，设置计划都相同——而且内容就在这里，因此无需联网。

如果代码仓库尚未成为 AI 优先——根目录下没有 AGENTS.md，也没有 .agents/ 目录——建议首先接入它，即使开发者的请求较为含糊（「设置一下」「让此代码仓库成为 AI 优先」或只是简单安装）。在转到其他流程之前：

1. 在本地阅读规范。 阅读 spec/（v5 基础规范和 v6 扩展）以及 shared/adaptation.md。首要原则是推理，而非复制粘贴：此技能是可复用的引擎；产出的内容必须根据此代码仓库进行调整，绝不能套用模板。
2. 运行接入流程。 阅读 onboard/SKILL.md 并执行。 此流程不会破坏现有内容：检测已有的 AGENTS.md、docs/、.agents/ 或 CLAUDE.md，进行整合而非覆盖，并在替换任何内容前询问开发者。最终会生成：AGENTS.md + CLAUDE.md 符号链接、经过推理设计的 docs/ 目录树、各模块文档、.agents/ 工具包，以及被 git 忽略的 .dwp/——代码仓库由此成为 Agent 的工作环境。
3. 验证是否符合规范。 阅读 verify/SKILL.md 并运行它，客观确认代码仓库现在符合规范（包含实际命令的 AGENTS.md、.agents/ 目录清单、被 git 忽略的 .dwp/ 等）。
4. 然后规划并执行。 工作环境准备就绪后，创建并执行 Deep Work Plans（见下文）——这是供 Agent 自主运行数小时的长期、有门槛、可恢复的工作。

如果代码仓库已经是 AI 优先，但其工作环境早于此技能——AGENTS.md / .agents/ 已存在，但没有 DWP standard: 来源标记行；来源标记行属于较早的系列（2.x、4.x 或 5.x；参见 spec/V6_LIFECYCLE.md）；或 docs/TESTING_GUIDE.md 缺少规范要求的、用于限定调用范围和映射的内容；或其 Agent 规则缺少 spec/DOCUMENTATION_STANDARD.md §2.3.1 所述的工作原则（措辞等效也算）——在转到其他流程之前，提供针对性的工作环境升级。 用一行说明哪些内容已过时，然后以 upgrade 模式（Phase 0）运行 onboard/SKILL.md。此模式只整合缺失或过时的部分，保留所有手写章节、自定义技能和进行中的计划不变，并且第二次运行时不会做任何更改。如果开发者想要更新的是技能本身（获取较新的已发布版本，或从头到尾重新执行一次 init），则转到 upgrade/SKILL.md：它会检查最新的已发布标签，仅在明确接受后下载，并将接入流程作为全新 init 重新运行——绝不会迁移 .dwp/ 计划。进行中的计划会保留其记录的生命周期；迁移计划需单独明确执行 refine migrate。如果开发者拒绝，则按其意图正常路由。

无人值守运行会记录这一缺口；绝不会停下来提出建议。 在 trust/auto 模式下，或使用预先批准的计划时，确认授权已被移除， 因此不应再询问：将其记录在工作内容会看到的地方（计划工作流的 README 说明和 PROGRESS.md；否则记录在该工作流自己的报告中），并根据意图分流。 过时的工具链和任何缺失的可选工具一样，都是一项已记录的发现 （spec/AGENT_PROTOCOL.md §7.2）——绝不是一个问题，也绝不能悄无声息地略过。

部分采用 AI 优先模式的仓库也走同一分支。 上述分支是理想情况；实际 仓库往往介于两者之间（有 AGENTS.md，却没有 .agents/；有 .agents/， 却没有来源说明；有文档，却没有测试指南）。任何已具备部分工具链、但并不 完整的仓库，都应视为工具链已过时，而不是全新仓库：通过 onboard 的 upgrade 模式进行协调，只补充缺失的内容。对于已经包含部分工具链的仓库， 切勿从头开始重新引导——这是唯一可能覆盖手写内容的路径。

如果仓库已经采用 AI 优先模式且内容是最新的，则跳过引导，并静默 按意图分流——不要宣布检测结果或分流决定（不要加上“仓库已经采用 AI 优先模式” ／“正在分流到 create 子技能”之类的开场白）。直接开始匹配的子技能流程。

功能

这是路由器。它本身不会运行任何流程——它会将开发者的意图映射到相应的 子技能，并指示 Agent 阅读该子技能的 SKILL.md，然后在那里执行。

信任边界（写入范围）

allowed-tools 包含具有写入能力的 Edit、Write 和 Bash，因为路由器委派 的子技能需要这些工具；路由器本身只会读取（仓库目录树、本地 spec/、 shared/ 和子技能文件）。写入操作会在受委派的子技能中进行，每个子技能都会 声明自己的信任边界：

• Onboard 会写入 AGENTS.md、docs/、各模块文档、.agents/，并向 .gitignore 追加内容——与现有内容协调，绝不覆盖，并在替换任何内容前征求同意。
• Create / refine 只会在被 Git 忽略的 .dwp/ 目录下写入计划产物。
• Execute / resume 会写入任务输出、进度和每项任务的提交——每项任务都必须 通过验证；绝不提交机密，也绝不在开发者未指示的情况下推送。
• Addons 只会在开发者明确接受建议后安装或配置内容，且始终通过固定版本并经过 验证的安装路径进行。

它绝不能：在核心流程中发起网络请求、读取或提交凭据、在未获提示的情况下运行安装程序， 或在上述范围之外的任何位置写入。完整保证和可运行的自审查程序见 TRUST.md。

---

面向 Agent — 路由规则

当开发者想要规划、执行或管理结构化工作，或让代码仓库做好供 AI Agent 使用的准备时，请根据以下意图匹配，并阅读对应子技能的 SKILL.md 来执行。不要直接作答——每个子技能都包含完整的分步流程。

开发者说……	路由至
“创建计划”、“规划这个小修复”、“整理这项工作”、“新的深度工作计划”、“/dwp-create”	创建 → 阅读 create/SKILL.md
“执行计划”、“运行计划”、“/dwp-execute”	执行 → 阅读 execute/SKILL.md
“修改计划”、“更改范围”、“/dwp-refine”	完善 → 阅读 refine/SKILL.md
“恢复”、“继续被中断的计划”、“/dwp-resume”	恢复 → 阅读 resume/SKILL.md
“计划状态”、“还剩什么”、“/dwp-status”	状态 → 阅读 status/SKILL.md
“验证”、“这个代码仓库是否以 AI 为先？”、“检查是否符合规范”、“/dwp-verify”	验证 → 阅读 verify/SKILL.md
“让这个代码仓库以 AI 为先”、“引导这个代码仓库”、“设置 AGENTS.md + docs + .agents”	引导接入 → 阅读 onboard/SKILL.md
“升级 DWP”、“更新技能”、“有更新版本吗？”、“/dwp-upgrade”	升级 → 阅读 upgrade/SKILL.md
“创建/更新技能或 Agent”、“改进工具包”、“/skill-create”、“/agent-create”	编写 → 阅读 author/SKILL.md

如果意图在规划工作和管理现有工作之间存在歧义，请先询问开发者想做哪一种，再进行路由。

适用于表格中每一行的激活规则：

• 普通的直接编辑绝不会悄然变成计划。“修复这个错误”、“重命名此函数”、“更新 README”都应直接完成——只有开发者要求制定计划（或明确选择某个流程）时，才启动深度工作计划。路由表映射的是请求的流程；它不是拦截策略。
• 信任不是流程选择器。trust / auto 授权在开发者请求的流程中无人值守地继续执行；它绝不会将只读请求扩大为执行，也不会把直接编辑变成计划。
• **状态和验证保持只读。**它们只报告信息；绝不执行任务或修改文件——无论以何种方式调用。
• **计划生成通过检测确定，绝不凭空假定。**包含 manifest.json 合约指针、contract.json 或 contracts/ 修订链的计划文件夹属于 v6（合约生成版本 v6 或 v7，spec/V7_CONTRACT.md）——创建和执行流程应通过各自的 v6.md 循环处理（合约、日志、调度器、经验证的闭环）。其他计划沿用记录的 v5 生命周期，绝不悄然迁移；仅支持 v5 的运行器遇到 v6 计划时，应报告为不受支持，而不是近似处理。两代计划可以共存于同一个 .dwp/ 中。
• **不支持斜杠命令的宿主使用相同的命名流程。**以 #deepworkplan-create 的形式调用子技能，或使用纯文本（“运行 deepworkplan-create”）；这些流程本身只涉及读取文件、编辑和运行 shell 命令（shared/troubleshooting.md §5 说明了能力缺失时的回退方案）。流程发现仅限本地：工具包和代码仓库的 .agents/ 索引都保存在磁盘上——不会经由网络服务进行路由。

规范性规范（随技能一同发布）

权威标准位于 spec/：保留的 v5 基础文档，以及当前的四项 v6 扩展。该标准随技能一同发布，因此 Agent 会在本地读取标准——无需网络。onboard 流程和 shared/adaptation.md 将其作为产出标准的依据。公开的渲染版本位于 https://deepworkplan.com/spec。

所有子技能共用的资源

• shared/context.sh — 检测仓库根目录、分支和 Agent 工具；确定 .dwp/ 输出位置。
• shared/dwp-paths.md — .dwp/ 输出约定（计划存放在 .dwp/plans/ 下）以及如何覆盖该约定。
• shared/adaptation.md — 以推理取代复制粘贴的原则，以及两种仓库类型（个人仓库与编排中心）。
• shared/troubleshooting.md — 仅在已出现问题时阅读：发现失败、安装过时、缺少测试命令、宿主功能不受支持或状态不一致。

附加组件 — 一项必需的本地审查，七项可选

addons/ 目录包含 onboard 在仓库中分层安装的内容。每个仓库都会获得该套件和 AI Diff Reviewer 本地审查（自 2.3.0 起的基线要求：在阶段 7a 安装，并由每次最终审查运行）。 其余七项为可选——即使不安装任何可选附加组件，仓库也完全符合要求。收到设置或更新这些附加组件的请求，或升级 harness 时，onboarding 会检测所有附加组件，升级正在使用的组件，并提供适用的组件。