Implement Feature 是从 add-new-feature 延续下来的工作流，用于执行 SAM（SAM 实施循环）任务。它的输入是一个 plan_ref 引用，工作流会一直执行所选提供者的任务，直至全部完成或被阻塞。
用途
该技能在被提供 add-new-feature 返回的 plan_ref 时使用，负责把计划中的任务逐个派发给子代理执行，并依据工作账本（ledger）判定任务结果。
主要步骤与能力
-
解析计划（Resolve Plan）：把 plan_ref 视为不透明引用，原样传给每个 SAM 操作和委派提示。使用
sam_cli plan status --plan-address "{plan_ref}"确认计划存在。 -
将计划写入账本（Put the Plan in the Ledger）：通过 SAM 计划操作创建的计划存放在内容存储（content store）中，无法直接开立尝试。因此需要在首次派发前执行
sam_cli plan import --from content --plan-address "{plan_ref}"。若账本已持有该计划，命令返回 exists 且不做更改。导入后，所有以该地址命名的计划命令都读写账本，状态响应的结构也会改变——计划级字段移入顶层 row 键，tasks 变为任务行数组。读取任何状态字段前需参考 ./references/plan-status-shapes.md。 -
记录实施基准 SHA（Record the Implementation Base SHA）：判定器会把 worker 的 FILES_CHANGED 与计划起始提交进行 diff，因此必须在首个提交落地前记录该提交。导入后重新运行状态命令，读取 row.base_sha；若已有值则无需重复记录。若 row.context 中已有
**Implementation base SHA**: <sha>行，同样跳过。否则在进度循环首次提交前运行git rev-parse HEAD，并把该行前置到现有 context（不可替换整个字段），再通过sam_cli plan update写回。 -
进度循环（Progress Loop）：查询状态
sam_cli plan status --plan-address "{plan_ref}"，并提取自主模式autonomy_mode = status["row"]["autonomy"]。该值必须在 full_auto、checkpoint 或 per_task 之一；若无法解析，必须停止循环并询问用户，不得回退到 full_auto。若有剩余任务，通过sam_cli plan ready --plan-address "{plan_ref}"查询就绪任务，每批次只查询一次。 -
按模式派发（Dispatch based on autonomy_mode）：在 per_task 模式下逐个处理就绪任务，每次单一 Agent 调用，完成后展示单任务确认关卡再派发下一个；在 full_auto 或 checkpoint 模式下，多个任务同时就绪时并行派发多个 Agent 调用。派发时只传任务引用（plan_ref + 任务 ID）与尝试编号。通过
sam_cli plan dispatch --address "{plan_ref}/{task_id}"开立尝试，该命令会设置任务为进行中、启动租约并打印尝试编号。leased 与 not-ready 两种代码表示应跳到批次中的下一个任务；其他代码会停止当前波次并交由用户处理。 -
代理健康检查（Agent Health Check）：派发批次后，当出现约 10 分钟无任何消息、用户询问代理状态、或 git log 显示应有实现工作时却无新提交时，触发健康检查，具体分支与重新生成逻辑见 ./references/agent-health-check.md。
-
结算与判定（Settle and Judge）：代理返回后立即运行
sam_cli plan settle --address "{plan_ref}/{task_id}" --attempt {A} --return-text "{...}"，即使响应为空或代理崩溃也要执行。随后通过sam_cli plan read对照任务的验收标准与验证步骤以及文件差异进行判定：符合则plan accept，未满足则plan reclaim退回并说明需要修改的原因。完整判定表（含过期租约与尝试耗尽等情况）见工作循环文档。 -
Concerns 处理：读取代理输出中的 <concerns> 块，若存在则通过
mcp__plugin_dh_backlog__backlog_groom追加到待办条目的 Concerns 区。这些 concerns 会累积并进入 /complete-implementation 的验证阶段。 -
契约验证（4a）：若已知父 issue 编号，可读取 architect 工件
sam_cli artifact read --item-id N --artifact-type architect，若有内容则解析刚完成任务的修改文件（git diff --name-only HEAD~1..HEAD），并派发 dh:contract-verification 代理按规范验证。若无 architect 规范则跳过此步。 -
批次完成确认（4b）：在 full_auto/checkpoint 模式下，提交批次前必须通过 plan status 确认批次内每个任务都已终止，不能假设静默的代理已完成。
-
提交归属（Commit Ownership）：默认同工作树模式下由编排器负责所有提交。per_task 模式在 4b 之后、派发下一任务之前提交；full_auto 与 checkpoint 模式在步骤 5 确认整个批次完成后一次性提交。提交信息类型应匹配主要变更（feat、fix、docs、refactor 等），不得包含 Fixes/Closes/Resolves 尾注，issue 关闭仅由 /complete-implementation 处理。隔离工作树模式（经 /dh:work-milestone）下由各代理自行提交，编排器将其工作树合并回来，不发出提交调用。
-
确认关卡：per_task 模式下，任务 N 完成后、派发任务 N+1 前展示紧凑的任务结果摘要（任务 ID 与标题、完成状态、concerns，后者需通过 backlog_view 重新读取）并等待用户明确确认；checkpoint 模式下，在当前批次全部完成且仍有剩余任务时，展示波次完成摘要（本波完成任务数、计划进度、剩余任务数、下一批就绪任务 ID）并等待用户确认后方可获取下一波。
依赖与限制
该技能依赖 SAM CLI、dh:dh-cli-usage、dh:dispatch-contract、dh:task-worker 等 dh 系列子技能，以及通过 mcp__plugin_dh_backlog__* 工具访问的 MCP 服务器（会话重启后约 1–2 秒初始化，Claude Code 会自动处理连接等待）。使用 SAM CLI 或 dh 脚本前须先加载 dh:dh-cli-usage。
关于收费、价格、支持平台或其他未在上述资料中出现的信息，暂未提供。