用途：当人类要求领取、接手或处理一个已跟踪的实现类 issue 时使用。主助手是编排者而非直接实现者，只负责按阶段协调子代理，不亲自做实现工作。阶段需自上而下依次执行。
主要流程与能力：Intake 阶段必须获取并阅读 issue、检查验收标准；若 issue 属于某 PRD，还必须检查未解决的后续被阻塞 issue 的验收标准，避免当前切片把后续工作逼入死角。Grill 阶段在验收标准未明确边界情况与做法时，必须与人类进行 grill 会话确认；若标准已无歧义，可提议跳过（条件 criteria_clear），但由人类在关卡确认，不得静默跳过。Scout 阶段必须在实现前派发只读的预实现侦察子代理，检查相关代码、既有模式、风险与可能的验证方式，其发现用于制定计划。Plan 阶段必须按 writing-plans 技能在临时目录创建实现计划，并默认创建/使用隔离工作区（worktree），使用项目已有的版本控制系统，若有对应 VCS 技能需先阅读。Mode 阶段必须确定执行模式：由调用参数指定（不区分大小写的 HITL 或 AFK，如 /issue-implementation 123 AFK），未提供则询问人类；不得从标签、issue 内容或模糊措辞推断。HITL 保留每任务的人类反馈关卡；AFK 在任务实现与评审/修复循环中忽略人类关卡，但最终 PR 就绪关卡仍适用。
Implement 阶段必须按任务粒度委派 worker 子代理，禁止单个宽泛 worker（除非计划只有一个任务或人类明确同意合并）。多任务时串行循环：派发一个异步 worker 实现 Task N、等待完成、提交（遵循项目提交信息约定，否则默认 Conventional Commits）、若 N 为 1 则在评审前立即创建草稿 PR、推送、派发至少一个异步评审者、按模式处理人类反馈、用聚焦 worker 修复阻塞问题、提交推送、重新评审直至通过，再进入下一任务。子代理纪律：始终使用异步子代理，假定其运行中非交互，初始提示需包含全部已知范围、评审反馈、停止规则与验证要求。
PR 与 Review：Task 1 提交推送后创建草稿 PR，全程保持草稿；所有任务完成且代理评审问题解决后，请人类批准转为 ready for review（HITL 与 AFK 均适用），随后请求覆盖规格/验收标准遵循与代码质量（DRY/KISS/YAGNI/campfire）的代理评审，DRY 评审需检查变更文件及深度 1 的依赖/引用。人类批准后才可标记 ready，评审通过后才可合并。若跳过必需步骤或编排者误直接实现，必须立即停止、报告并询问。除非验收标准明确要求，不强制向后兼容。ready-for-agent 标签仅表示该 issue 适合此流程，不选择 AFK 模式。
限制：资料未提供具体安装命令、收费、平台或效果信息。