delegated-development

用途：以委派式子代理工作流执行开发计划。核心原则是每个任务派发一个全新子代理，并在任务完成后做两阶段审查：先规格符合性审查，再代码质量审查，从而实现高质量、快迭代。\n\n适用判断：已有实现计划，且任务基本相互独立，并希望停留在当前会话内时使用本技能；若没有计划，应先手工执行或先做需求梳理；任务紧耦合时不适用；若改为并行会话执行，则使用 superpowers:executing-plans。与 executing-plans 的区别：同一会话无需上下文切换、每任务全新子代理避免上下文污染、每任务两阶段审查、任务间无需人工介入。\n\n主要能力与流程：控制器先读取计划，提取全部任务全文并记录上下文，建立 TodoWrite；然后逐任务派发实现子代理（./implementer-prompt.md），子代理可提问，控制器回答并补充上下文；子代理实现、测试、提交并自审；随后派发规格审查子代理（./spec-reviewer-prompt.md），若不符合规格则由同一实现子代理修复并复审；通过后派发代码质量审查子代理（./code-quality-reviewer-prompt.md），有质量问题则修复并复审；通过后在 TodoWrite 标记完成。全部任务完成后，派发最终代码审查子代理，再使用 superpowers:finishing-a-development-branch 收尾。\n\n使用方式：控制器向子代理提供任务全文与场景上下文，不让子代理自行读取计划文件；子代理按 superpowers:test-driven-development 实践 TDD；审查模板配合 superpowers:requesting-code-review 使用。\n\n限制与红线：不得跳过任一阶段审查，不得带未修复问题进入下一任务，不得并行派发多个实现子代理，不得忽略子代理提问，不得用自审替代正式审查，不得在规格符合性未通过前开始代码质量审查，审查发现问题必须修复后重新审查。代价是子代理调用次数更多、控制器准备工作更多、审查循环增加迭代，但能更早发现问题。具体安装命令与收费信息暂未提供。