莫的 Skills 精品 Hubskills.miemie
安装热度榜

subagent-driven-development

这是一个面向会话内执行实施计划的 Agent 工作流技能：为计划中的每个任务派发一个全新的实施者子代理（拥有隔离上下文），每个任务完成后派发任务审查（规格符合性 + 代码质量），最后对整个分支做一次广义终审。核心原则是「每任务新子代理 + 任务审查 + 最终广度审查」，以在保持控制器上下文干净的同时实现高质量、快速迭代。技能强调：用 ledger 文件（workspace 内 progress.md）记录进度以抵抗上下文压缩；派发前记录 BASE commit 并用脚本生成任务简报、审查包与工作区；实施者只有四种状态（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）；审查发现问题进入修复循环，最多 5 轮，第 1-3 轮恢复原实施者，第 4-5 轮换更强模型的新实施者，触顶后逐条裁定并记账；只有四类情况才停下询问人类（不可逆/破坏性操作、安全敏感动作、工作树之外的副作用如合并推送发布、计划破碎到每一条路都是猜测）。除这些之外不中断执行、不做进度汇报式确认，冲突与歧义由控制器裁定并写入 ledger。

分类
Agent 工作流
榜单排名
#266
安装量
219,314

它能做什么

中文摘要

这是一个面向会话内执行实施计划的 Agent 工作流技能：为计划中的每个任务派发一个全新的实施者子代理（拥有隔离上下文），每个任务完成后派发任务审查（规格符合性 + 代码质量），最后对整个分支做一次广义终审。核心原则是「每任务新子代理 + 任务审查 + 最终广度审查」，以在保持控制器上下文干净的同时实现高质量、快速迭代。技能强调：用 ledger 文件（workspace 内 progress.md）记录进度以抵抗上下文压缩；派发前记录 BASE commit 并用脚本生成任务简报、审查包与工作区；实施者只有四种状态（DONE / DONE_WITH_CONCERNS / NEEDS_CONTEXT / BLOCKED）；审查发现问题进入修复循环，最多 5 轮，第 1-3 轮恢复原实施者，第 4-5 轮换更强模型的新实施者，触顶后逐条裁定并记账；只有四类情况才停下询问人类（不可逆/破坏性操作、安全敏感动作、工作树之外的副作用如合并推送发布、计划破碎到每一条路都是猜测）。除这些之外不中断执行、不做进度汇报式确认，冲突与歧义由控制器裁定并写入 ledger。

为什么推荐

推荐理由

适合已有清晰实施计划、任务之间基本独立、并且环境支持子代理的场景。它把「每任务派新上下文 + 每任务审查 + 最后一轮全分支审查」工程化为一套可恢复的流程：ledger 让长会话在上下文压缩后仍能续跑，避免重复派发已完成任务；审查循环有明确熔断（5 轮）与裁定规则，防止无休止返工；模型选择按任务复杂度分层以控成本。若你曾遇到长会话丢进度、控制器上下文被实施细节污染、或审查流于形式的问题，这套流程有针对性价值。它不适用于任务紧耦合、没有实施计划（应先头脑风暴或手工执行）、或伙伴明确选择内联执行的情形。

什么时候用

适用场景

  • 在当前会话中按已写好的实施计划逐任务落地，且任务之间大体独立
  • 需要每个任务后做一次规格符合性 + 代码质量审查，而不是只在末尾审查一次
  • 长会话容易因上下文压缩丢失进度，需要用 ledger/workspace 文件持久化恢复点
  • 希望把实施委托给隔离上下文的子代理，同时保留控制器上下文用于协调
  • 任务复杂度差异大，需要按机械/集成/架构/审查分别选择不同能力的模型以控成本
  • 需要一套有明确熔断与裁定规则、避免无限修复循环的执行流程
  • 多提交任务需要基于派发前记录的 BASE commit 生成审查包，而非用 HEAD~1 截断

使用前先看

主要亮点

  • 01

    为每个任务派发全新的实施者子代理，使其不继承会话的上下文与历史，从而保持专注并保留控制器自身的上下文用于协调

  • 02

    任务审查同时要求两项结论：规格符合性与任务质量；实施者自审不能替代任务审查

  • 03

    修复循环最多 5 轮：第 1-3 轮恢复原实施者（其上下文仍在），第 4-5 轮改用至少高一个层级模型的新实施者

  • 04

    触顶后对每条未解决发现进行裁定，结果记为 ledger 条目（parked 或 Ruling），禁止静默丢弃

  • 05

    只有四类情况会中断执行去询问人类：不可逆/破坏性操作、安全敏感动作、工作树之外需先询问的副作用（合并、推送到共享分支、发布）、以及每条前进路径都是猜测的破碎计划

  • 06

    使用 git 忽略的 workspace 目录记录本案的 ledger、简报、报告与审查包，另一个计划的目录不得读写

  • 07

    任务简报通过 `bash scripts/task-brief PLAN_FILE N` 生成，派发提示中只放简报路径与跨任务接口，避免让子代理读整个计划文件

  • 08

    审查包通过 `bash scripts/review-package PLAN_FILE BASE HEAD` 生成，BASE 必须是派发实施者前记录的 commit，而非 HEAD~1

  • 09

    把最小发现（Minor）记录到 ledger 并在最终审查时统一分诊，不进入修复循环

  • 10

    实施者不得自行派发子代理，包括审查者——重复审查席被视为缺陷而非严谨

  • 11

    最终全分支审查用最强可用模型派发，发现的问题只做一次修复派发加一次限定范围的复审，没有第二轮修复波

  • 12

    结束前必须把所有含 Ruling: 的 ledger 条目汇总进最终消息的「Rulings I made」列表，避免决策随工作区被删除而消失

  • 13

    模型选择分层：机械实现用便宜快模型，集成与判断用标准模型，架构设计与最终全分支审查用最强模型，并强调派发时必须显式指定模型

  • 14

    等待子代理时不做短超时轮询也不做无休止静默等待，有本地工作就继续做事，空闲时按 5-10 分钟的有界时段等待并核对存活的子代理

原始文档

原文摘录

Subagent-Driven Development Execute plan by dispatching a fresh implementer subagent per task, a task review (spec compliance + code quality) after each, and a broad whole-branch review at the end. **Why subagents:** You delegate tasks to specialized agents with isolated context. By precisely crafting their instructions and context, you ensure they stay focused and succeed at their task. They should never inherit your session's context or history — you construct exactly what they need. This also