skill-implementer（任务实现技能）Skill 是什么？如何安装使用？

任务实现技能Skill：把「已规划」的任务交给子代理，自动完成实现、状态更新与提交

核心结论速览

• 任务实现技能Skill（skill-implementer） 是一个「薄包装器」型技能，职责是把通用实现类任务委托给 general-implementation-agent 子代理去执行，自己负责前后的状态管理与收尾。
• 它最大的差异化在于内置后操作（postflight）模式：子代理返回后，技能会自己完成状态更新、工件链接和 git 提交，再返回结果，从而消除技能与编排器之间反复出现「继续」提示的问题。
• 触发条件很明确：任务语言为 general、meta 或 markdown，或直接调用 /implement 命令，且计划文件已经存在、任务处于可实施状态。
• 它带有完整的执行流程（11 个阶段）与错误处理：先验证输入，再更新状态，然后落标记文件、委托子代理、解析元数据文件 .return-meta.json，最后分级更新状态、链接工件、提交、清理。
• 适合已经用「计划 + 状态文件」管理开发任务、希望把「执行」这一段流程自动化的开发者与团队。

---

该技能叫什么？如何下载安装 AI 技能提升开发效率？

基本信息

项目	内容
中文名	任务实现技能Skill
英文名	skill-implementer
技能ID	12879
技能类型	薄包装器（委托型实现技能）
核心委托对象	general-implementation-agent 子代理

它解决什么问题？

在「先规划、后执行」的工作流里，计划文件（implementation-*.md）写完之后，真正的痛点往往不在写代码，而在执行这一段的管理成本：

1. 状态不同步：任务在 state.json 里还写着 planned，代码其实已经写完了；TODO.md、计划文件的 Status 字段三处各说各话。
2. 收尾易遗漏：实现完成后忘了链接摘要工件、忘了提交 git，事后追溯困难。
3. 流程易中断：技能返回结果后，编排器还在等一个「继续」信号，导致对话或流水线卡住。
4. 长任务难恢复：跑到一半失败，下次要从头再来，无法从断点续跑。

任务实现技能Skill 的做法是：把「实现本身」交给子代理，把「实现前后的所有簿记」留在技能内部完成，让一次调用从「读取任务」一直走到「提交完成」。

一键安装的思路与步骤

该技能属于 AI 技能（Skill）体系，安装方式遵循其宿主平台的技能加载机制。以下为通用思路，具体命令、仓库地址与入口请以官方说明为准：

1. 确认运行环境前提
   • 需要支持 Skill 机制与 Task 工具的 AI 开发环境（从其上下文路径 .opencode/context/... 看，属于 OpenCode 系技能体系）。
   • 项目内需存在规格目录结构：specs/state.json、specs/{NNN}_{项目名}/ 任务目录、TODO.md、以及 plans/implementation-*.md 计划文件。
   • 需要具备该技能声明的工具权限：Task、Bash、Edit、Read、Write，以及对 /tmp/*.json 的读取与 Bash(rm:*) 清理权限。
2. 获取并放置技能包
   • 从官方技能市场或仓库获取 skill-implementer 技能包，按其说明放入技能目录（通常是项目级或全局的 skills 目录），具体路径以官方说明为准。
3. 检查委托依赖
   • 确认 general-implementation-agent 子代理已可用；该技能本身不做实现，只负责委托。
4. 验证是否生效
   • 满足触发条件后调用 /implement 命令（或对语言为 general/meta/markdown 的任务发起实现）。
   • 生效迹象：state.json 中对应任务 status 变为 implementing、TODO.md 标记变为 [IMPLEMENTING]、任务目录下出现 .postflight-pending 标记文件。
   • 完成后会看到技能返回纯文本摘要（而非 JSON），并伴随一次带会话 ID 的 git 提交。

提示：该技能对价格、账号、网络等无额外描述，相关事宜请以官方说明为准。

---

该技能的主要功能和特点

• 薄包装器定位，职责单一：只做「委托 + 收尾」，不重复实现逻辑；实现上下文由子代理自行加载，避免主流程上下文膨胀。
• 输入三重校验：校验 task_number 是否提供、是否存在于 state.json、任务状态是否允许实施（planned / implementing / partial）；已完成任务直接报错拒绝。
• 预操作状态同步：调用子代理前，把任务状态写为 implementing，同步更新 state.json 时间戳与会话 ID、TODO.md 标记、计划文件的 Status 字段（兼容 - **Status**: 与 **Status**: 两种写法）。
• 后操作标记防早退：创建 .postflight-pending 标记文件，携带会话 ID、技能名、任务号、操作类型等信息，防止技能在收尾前被提前终止。
• 明确的子代理调用规范：强制使用 Task 工具并指定 subagent_type: "general-implementation-agent"，并明确禁止用 Skill(general-implementation-agent) 的方式调用（会失败）。
• 返回格式兼容性检查：若子代理把 JSON 打到控制台（v1 旧模式）而非写入文件（v2 模式），技能会记录警告但不中断，仍继续读取元数据文件，实现新旧代理混用时的优雅降级。
• 元数据文件驱动决策：从 specs/{NNN}_{SLUG}/.return-meta.json 读取 status、首个工件路径/类型/摘要、已完成阶段数与总阶段数，以及 completion_data 中的完成摘要、CLAUDE.md 建议、路线图条目。
• 分支化状态更新：implemented → 置为 completed 并写入 completion_summary；partial → 保持 implementing 并写入 resume_phase（已完成阶段 +1）；failed → 保持 implementing 以便重试。
• 语言感知的字段写入：meta 类任务写入 claudemd_suggestions；非 meta 任务写入非空的 roadmap_items。
• 工件链接防转义坑：采用「先过滤旧摘要工件、再追加新工件」的两步 jq 模式，规避 jq 转义问题（问题 #1132）。
• 自动 git 提交与清理：git add -A 后以「task N: complete implementation」提交并附会话 ID；随后删除 .postflight-pending、.postflight-loop-guard、.return-meta.json 等临时文件。
• 稳健的错误处理：元数据缺失时保留标记、不清理、向用户报错；git 提交失败视为非阻塞；子代理超时（默认 7200 秒）时返回部分结果并保留可恢复状态。

---

如何使用该技能？

前置准备

• 已有 specs/state.json 且其中存在待实施任务（project_number 与 status 字段齐备）。
• 任务目录 specs/{NNN}_{SLUG}/ 与计划文件 plans/implementation-*.md 已就绪。
• general-implementation-agent 子代理可用。

分步使用指南

1. 确认目标任务号

   查看 state.json 中 active_projects 数组，找到你要推进的任务编号，例如 350。

2. 发起调用

   两种常见方式：

   • 命令方式：/implement 350
   • 语义触发：任务语言为 general、meta 或 markdown，且计划已存在、任务就绪时自动激活。

3. 等待阶段 1 校验通过

   若任务号不存在，会立即收到错误（如 Task 350 not found）；若任务已完成，会收到 Task already completed。此时无需任何后续操作。

4. 阶段 2-3 自动完成状态切换

   技能会把任务状态改为 implementing，同步 TODO.md 与计划文件，并写下 .postflight-pending 标记。你可以打开 TODO.md 确认标记已变为 [IMPLEMENTING]。

5. 阶段 4-5 委托子代理执行

   技能以 Task 工具调用 general-implementation-agent，传入任务上下文（任务号、任务名、描述、语言）、计划路径、元数据文件路径与会话信息。子代理会解析计划、找到恢复点、按阶段顺序执行并创建实现摘要。

6. 阶段 6 读取元数据文件

   子代理返回后，技能读取 specs/{NNN}_{SLUG}/.return-meta.json。若该文件缺失或不是合法 JSON，状态会被置为 failed 并报错。

7. 阶段 7-9 后操作三连

   • 按 implemented / partial 分支更新 state.json、TODO.md、计划文件状态；
   • 把摘要工件（path / type / summary）链接回任务，并在 TODO.md 里加上 - **Summary**: [...] 链接；
   • 执行 git 提交。

8. 阶段 10-11 清理与返回

   删除临时标记与元数据文件后，返回简短文本摘要。

输出示例参考

成功场景：

Implementation completed for task 350:
- All 5 phases executed successfully
- Created new feature component with tests
- Created summary at specs/350_feature/summaries/implementation-summary-20260118.md
- Status updated to [COMPLETED]
- Changes committed with session sess_1736700000_abc123

部分完成场景（可从断点续跑）：

Implementation partially completed for task 350:
- Phases 1-3 of 5 executed
- Phase 4 failed: TypeScript compilation error
- Partial summary at specs/350_feature/summaries/implementation-summary-20260118.md
- Status remains [IMPLEMENTING] - run /implement 350 to resume

看到 Status remains [IMPLEMENTING] 时，再次执行 /implement 350 即可续跑，无需手工改状态文件。

---

同类型竞品对比分析

方案名称	定位	核心功能	安装/使用门槛	适用场景	优势与不足
任务实现技能Skill（skill-implementer）	计划驱动实现的「委托 + 收尾」薄包装器	输入校验、状态三段同步、postflight 标记、子代理委托、元数据驱动分支、工件链接、自动 git 提交、断点续跑	需具备 Skill 机制与 Task 工具，需 specs 目录与计划文件；安装方式以官方说明为准	已有计划与状态文件、希望把执行段自动化的单人开发或团队流水线	优势：收尾完整、可追溯、抗中断、新旧代理兼容；不足：强依赖既定目录结构与状态文件规范，脱离该体系后价值骤降
手动按计划执行	传统人工方式	人读计划、人写代码、人改状态、人提交	无门槛	一次性小改动、探索性任务	优势：灵活、无耦合；不足：状态易漂移、收尾易漏、无法续跑与审计
通用编码 Agent 直接对话	通用型 AI 编码助手	对话式改代码、生成文件	门槛低，直接开聊	临时脚本、局部重构	优势：上手快、无需规范；不足：缺少状态机与工件链接，长任务难追踪，提交与摘要常需人工补
自建脚本 / CI 流水线	工程化自动化编排	自定义流水线、脚本串联	门槛高，需自研与维护	稳定的标准化构建发布	优势：可完全定制、可纳入 CI；不足：不擅长「按自然语言计划执行」，对计划变更适应性差

对比可见：它并非要做通用 AI 编码助手，而是指定「计划驱动执行」这一具体位置。当项目本来就有 state.json、TODO.md、计划文件这套规范时，它的边际收益最明显；若项目没有这套结构，直接使用通用 Agent 反而更轻。

---

该技能的典型应用场景与实际体验情况

场景一：独立开发者的多任务并行推进

• 角色与痛点：独立开发者手上同时开着 5-8 个任务，每个任务都有计划文件，但任务已完成却忘了更新状态，导致整理进度时对不上。
• 使用方式：对每个就绪任务执行 /implement {任务号}，技能自动把 state.json、TODO.md、计划文件三处状态一次改到位。
• 实际体验：状态一致性是最直观的收益。注意事项：任务号必须真实存在于 active_projects，否则会在阶段 1 被直接拒回。

场景二：markdown / meta 类文档任务的批量落地

• 角色与痛点：技术写作者或文档维护者需要按计划批量产出/改造文档，并在完成后留下「对 CLAUDE.md 的建议」供团队沉淀。
• 使用方式：当任务语言为 markdown 或 meta 时自动触发；meta 任务完成后，claudemd_suggestions 会被写入状态文件。
• 实际体验：语言感知字段省去了人工分类整理。注意事项：非 meta 任务写的是 roadmap_items，且为空数组时不会写入。

场景三：需要可追溯提交的团队协作

• 角色与痛点：团队要求每次实现都有独立提交、能追溯到具体任务与会话，但手动写提交信息经常不统一。
• 使用方式：技能在阶段 9 统一执行 git add -A 与「task {任务号}: complete implementation」提交，并附会话 ID。
• 实际体验：追溯链完整（提交 → 任务 → 摘要工件）。注意事项：git 提交失败被设计为非阻塞，只记录失败但继续返回成功，因此需要自己检查提交是否真的落地。

场景四：长任务中断后的断点续跑

• 角色与痛点：一次实现涉及多个阶段，中途因为编译错误或超时失败，重跑成本高。
• 使用方式：失败后状态保持 implementing，计划文件不动；重新执行同一命令，子代理会从计划中解析出恢复点继续。
• 实际体验：续跑语义清晰（resume_phase = 已完成阶段 +1）。注意事项：子代理默认超时为 7200 秒，超长任务需留意这一上限。

---

该技能能为用户带来的价值

• 把「执行段的簿记」归零：状态更新、工件链接、git 提交、临时文件清理这四件最容易遗漏的事，全部由技能内部完成，人只需给一个任务号。
• 消除流程卡顿：内置后操作模式让技能返回即代表收尾完成，不再需要编排器反复发「继续」，对话式与流水线式调用都更顺。
• 提高可追溯性：每次实现都留下摘要工件路径、提交记录与会话 ID，事后复盘有据可查。
• 降低中断成本：partial 分支保留 implementing 状态并记录恢复阶段，配合明确的续跑提示，把「失败重来」变成「失败续跑」。
• 降低规范落地门槛：把「按计划执行」的最佳实践固化为 11 个阶段的标准流程，团队无需自行设计状态机与收尾清单。
• 长期价值：随着任务累积，state.json 中的 completion_summary、claudemd_suggestions、roadmap_items 会沉淀为项目知识资产，越用越值钱。

---

常见问题 FAQ

Q1：怎么安装这个技能？需要改代码吗？

不需要改代码。按其宿主平台的技能加载机制放置 skill-implementer 技能包即可，同时确保 general-implementation-agent 子代理可用、项目内已有 specs/state.json 等目录结构。具体安装路径与命令请以官方说明为准。

Q2：为什么我调用后直接报错「Task not found」或「already completed」？

这是阶段 1 的输入校验在起作用：任务号必须存在于 state.json 的 active_projects 中，且状态不能是 completed。请确认任务号是否正确、任务是否已完结。

Q3：技能返回「Status remains [IMPLEMENTING]」是不是失败了？

不是彻底失败，属于部分完成（partial）。通常某个阶段执行出错（例如编译错误）。此时状态与计划文件都保持在可实施状态，重新执行同一命令即可从断点续跑。

Q4：这个技能和通用编码 Agent 有什么区别，该怎么选？

通用 Agent 适合临时、探索性、无规范约束的编码；任务实现技能Skill 适合已经用「计划文件 + 状态文件 + TODO」管理任务的场景，它的价值主要体现在状态同步、工件链接、自动提交与断点续跑上。若你的项目没有这套目录规范，直接用通用 Agent 会更轻。

Q5：git 提交失败会不会导致整个实现白做？

不会。该技能把 git 提交失败设计为非阻塞：记录失败但继续返回成功响应，代码改动与状态更新仍然保留。不过这意味着你需要自己复核提交是否真的产生。