| name | capability-adaptation |
| description | 用户要求采用内部流程、调整工作方式、修改默认 Skill 行为、创建或替换专业 Skill、卸载可能被编排的 Skill，或 Agent 准备改变 provides、requires、capability contract、binding 及跨 Skill 协作边界时使用；负责从自然语言意图完成影响分析、候选开发、组合验证、安全激活和 runtime 同步，不要求用户理解 capability 术语。 |
工作能力适配
本 Skill 承载 Agent 工作能力适配（Agent-managed Capability Adaptation）。用户只拥有工作意图和关键决策；Agent 维护工作资产；Buildr 维护依赖结构和 runtime 投射；capability contract 只保护跨 Skill 最小协作边界。
1. 建立影响基线
- 解析 Buildr workspace、实际 scope 和当前 Agent，运行
buildr doctor --agent <agent> --target <workspace> --json。
- 读取目标 Skill 源、
skills/manifest.yml、相关 contracts、当前 bindings 和 doctor capabilities graph；同时区分 Agent runtime 基于 description 的入口发现与 Skill 加载后的 dependency resolution。routing evidence 存在时，只在对应产品入口已经命中的前提下检查其内部用户意图覆盖。
- 列出目标 Skill 提供的 capabilities、直接/递归 consumers、required/optional mode、当前 selected provider 和修改后的 blocked/degraded 风险。用户无需知道这些资产名称。
- 修改 Buildr builtin 时不得直接编辑用户 workspace 中的受管副本；组织差异使用组织自有 provider，Buildr 产品行为变化走产品 change。
2. 判断如何落地
按以下顺序选择最小变化：
- 只属于单个 Skill 内部，且不被组合、不需替换、consumer 不依赖稳定保证或结果证据、生命周期无需影响诊断：普通 Skill 维护，不创建 contract。
- 触达已有 contract 且变化位于
Allowed Variations：修改用户自有 provider，或为 builtin 创建组织 provider；保持 contract identity 和 guarantees。
- 另一工作流无法在缺少该能力的稳定保证或结果证据时安全继续、需要替换实现，或生命周期需要影响诊断：创建最小 contract 和
provides/requires。不要因为 Agent 执行时会同时读取多个 Skills，就把它们建模为方法调用依赖。
- 新行为突破既有前置条件、副作用、授权、结果证据或失败语义：升级 contract major version，或同步修改 consumers；不得把不兼容实现继续声明为旧版本 provider。
判断的是稳定协作边界，不是用户是否说出 capability 名字。命令、算法、merge/rebase policy 和组织工具留在 provider；只有 consumer 无法安全继续时依赖的保证进入 contract。
3. 先开发候选，再改变当前实现
- 在 canonical task worktree 或任务候选目录中修改或创建 Skill，记录当前 provider、binding 和 source integrity；不得先卸载或覆盖当前有效实现。
- 为候选写清触发 description、职责边界、授权/停止条件和结果证据。实现既有 contract 时逐项核对 contract；新增 contract 时使用最小 frontmatter 和固定语义章节。替换顶层入口 capability provider 时，必须验证新 provider 的 description 覆盖原用户意图，并检查旧入口或其他 Skill 是否造成触发歧义；binding ready 不能替代这项验证。
- 运行 Skill frontmatter/package 静态检查、provider 专项测试和每个受影响 consumer 的组合场景。
ready 只表示结构可路由，不能替代行为证据。
- 候选不满足 contract、组合验证失败或计划会产生用户未接受的 blocked consumer 时停止；保留当前实现和 binding，向用户说明真正需要决定的语义差异。
4. 激活与恢复
- 使用
buildr skills add ... --provides/--requires 或 --replace 写入已验证候选；不要要求用户手改 manifest。
- 安装新 provider 不会自动改变流程。确认候选可见后使用
buildr skills bind <capability>@<version> --provider <skill-id> --scope <scope> --target <workspace> 显式选择。
- 在新 binding ready 之前不卸载旧 provider；一个 Skill 提供多个仍被使用的 capabilities 时，逐项检查后才能完整卸载。
- 执行当前 Agent 的
buildr sync 或最小 scope render，再运行最终 doctor，核对受影响 consumers、runtime paths，以及已加载产品入口内部适用的 routing evidence。顶层入口发生替换时，同时确认 selected provider 已投射到 runtime，且入口 description 与激活计划一致。
- 激活后出现新的结构 error 时，使用记录的旧 binding 恢复选择并重新 doctor；不得留下明知 blocked 的半完成适配。已经发生且无法安全自动恢复的外部副作用必须如实报告。
5. 面向用户交付
默认只说明：用户要求的工作方式、实际生效 scope、Agent 修改或创建了什么能力、哪些现有工作流已验证兼容、是否有需要决策的风险。provider、consumer、binding 和命令细节只在用户询问、存在歧义或发生阻塞时展开。
例如用户要求“改用 feature 分支并通过 PR 合入 dev”时，Agent 应发现 Git task integration 被 Task Finish 使用；若该变化仍满足现有 contract，则创建或修改组织 Git provider、验证 Task Finish 后激活，并向用户报告新实践和收尾能力仍可用，而不是让用户执行 capability 命令。
Guardrails
- 不把“用户想改工作方式”机械等同于新建 contract。
- 不通过 Skill id、description 相似或安装顺序猜测 provider conformance。
- 不把产品入口 Buildr Skill 当成全局前置 dispatcher，也不把 capability binding 当成 Agent 首次 Skill 意图发现机制。
- 不让产品入口的某项 route blocked 扩大为整个 Buildr Skill blocked。
- 不修改 runtime 派生副本作为长期事实。
- 不以“能力适配”为名扩大用户对外部写入、远端改写或破坏性动作的授权。
