技能与代理

DWP 是代理无关的，但它预设了两类反复出现的基本构件——技能与代理——以及一种在任何工作开始之前、刻意先在代码仓库中确立方位的方式。

技能对比代理

Building blocks

Skill

how — a reusable procedure

• fix-lint
• add-component
• translate-sync
• dwp-create

Agent

who — a specialized worker

• reviewer
• executor
• architect
• i18n-guardian

.claude → .agents symlink → backward compatibility

两者容易混淆，但服务于不同的目的：

• 技能是按名称调用的可复用过程。一项技能把一套可重复的工作流打包起来——运行测试、修复 lint、创建组件——使代理与人类每次都以相同方式调用它。
• 代理是带有既定角色的专职工作者——审阅者、执行者、架构师。每个代理都有一项聚焦的职责，并在其范围内运作。

一个有用的速记：技能是如何完成一项反复出现的任务；代理是谁对某一类工作负责。

一套活套件：代码仓库培育自己的技能

接入会把代码仓库转化为代理的 harness（运行支架）；它不会将其冻结。套件本应随着仓库的工作流逐渐清晰而成长。DWP 提供了一个 author 子技能——通过 /skill-create 与 /agent-create 调用——它会对仓库现有的 .agents/ 布局与约定进行推理，然后写出一个与之相匹配的新技能、新代理或轻量命令委派器。代码仓库自行撰写自己的套件，而非继承一套泛用的。

author 子技能在“契合度”上十分审慎。它为人们手工运行的可重复过程创建一个技能，为有独特模型或工具需求的反复出现的角色创建一个代理，并且只把命令作为路由到某个技能或代理的轻量入口点来创建。它会略过任何与真实工作流不匹配的泛用之物，并让 .agents/docs/ 目录与它所添加的一切保持同步。同一个子技能也支撑着那项强制的 Skills & Agents Discovery 任务，该任务会将目录与磁盘上实际存在之物进行核对——而 /dwp-verify 则客观地确认这一核对，若目录与文件相互背离便判为失败。

维护类附加组件

在撰写之外，DWP 还附带了可选的维护类附加组件——对一个仓库实现 AI-first 而言绝非必需。dependency-upgrade 附加组件是其典范：它会对仓库实际使用的包管理器进行推理（npm、pnpm 或配合 ncu 的 yarn；pip、poetry 或 uv；Cargo；Go modules；Bundler；Composer），而不是假定某一种，然后以小批次升级，在每个批次后运行仓库真实的验证关卡，回退任何失败的批次，并在不自动提交的情况下给出总结。附加组件在接入期间被明确采纳；拒绝其中之一仍会让仓库保持完全符合规范。

基于推理的代码仓库接入

在创建或执行一份计划之前，代理会接入代码仓库。接入是基于推理的，而非基于脚本的：代理读取仓库的结构、文档与配置以构建一套心智模型，而非运行一个固定的安装脚本。

在接入过程中，代理会识别仓库的原型（单一对比编排）、构建、测试与 lint 命令、关于风格、结构与命名的既有约定，以及已经可用的技能与代理。正是这份理解，让代理得以用一种契合仓库而非与之对抗的方式来规划与执行。

.agents/ 目录与 .claude → .agents 符号链接

DWP 把界定代理行为的一切——技能、命令、代理定义、内部文档与设置——都汇集于单一的规范目录 .agents/ 之下。这个名字昭示着其中的内容是跨代理共享的，而非绑定于任何单一工具。

为了与历来从 .claude/ 读取的工具向后兼容，那个路径是指向 .agents/ 的符号链接：

ls -la .claude
# .claude -> .agents

每一个 .claude/... 路径都会透明地解析到其 .agents/... 对应项，因此较旧的工具链得以继续工作，而新内容则引用规范的 .agents/ 位置。技能与代理通过 .agents/ 之下的真实文件来编辑，绝不通过符号链接。