用途：把大型实现计划拆解为聚焦、可自主执行的智能体冲刺。每个冲刺自包含、含可衡量验收标准，无需人工干预即可执行。调用时以参数传入计划：$ARGUMENTS。
何时使用：计划超过15个离散步骤或超过8K tokens、跨领域（多类别/服务/层）、或需检查点的长任务时拆解；少于10步、单一领域、范围清晰或探索性研究则直接执行。不确定时倾向拆解。
工作流：加载计划（从参数路径或用户输入读取，若为描述则索取完整计划或规格位置）；盘点工作项并按复杂度分类（setup、simple、stub、complex、integration）；识别依赖并分组可并行项；按批处理策略分批，每冲刺最多2-6项；用冲刺结构字段编写定义与验收标准；构建依赖链（如 1 → 2, 3 → 4 → 5）；按 assets/sprint-template.yaml 输出，并追加 references/execution-protocol.md 中的执行协议与回滚部分。
冲刺要求：时长2-4小时；范围2-6项；3-5条可验证验收标准；显式列出依赖；可无人执行；定义控制在约2K输入tokens内。结构字段包括 sprint_id、title（“类别: 描述”）、duration_hours、dependencies、input_state、output_state、scope、acceptance_criteria、constraints、reference_material（仅文件路径与行范围，不粘贴源码）、style_anchor。
验收标准须可衡量、确定性，禁止“代码看起来不错”等主观表述，可用产物存在、代码模式、构建/测试成功、验证输出、集成检查点等格式。批处理策略区分 setup、简单CRUD批量、stub迁移、复杂工作、集成，并规定不混用 setup 与实现、复杂工作单独成冲刺、每个冲刺可从 input_state 独立重跑。
上下文最小化：冲刺上下文超过约2K tokens 时性能下降，中段信息利用更低；应引用文件路径而非内联内容，把验收标准与约束排在参考材料之前。依赖用 sprint_id 显式声明，独立冲刺可并行，并在计划头部用 dependency_chain 表达。
输出为 YAML，使用 assets/sprint-template.yaml，并附执行协议、验证门与回滚流程；references/example.md 提供43端点迁移拆为7冲刺的完整示例。限制：资料未提供具体安装命令、收费、平台或效果数据。