recursive-subagent

recursive-subagent

使用此技能判断子代理是否有助于递归模式阶段，并在使用子代理时强制执行交接约定。

此技能不会放宽规范工作流。主 Agent 仍负责：

• 每次只进行一个递归阶段
• 作为用户当前交互对象的唯一协调者
• 在锁定前进行完整审计
• 拒绝不完整或缺乏上下文的子代理输出
• 子代理不可用时回退到 self-audit

如果已安装 recursive-router，当用户明确要求使用路由，或所选委派角色存在已启用的外部路由时，请查阅它。由于路由器发现和配置可能会检查设备上的本地 CLI 和提供商配置，因此在进行新设置或更改策略前，先征求用户同意。对于必须派发的角色，若只是遵循已配置的外部路由，则无需再次询问。

用户确认路由设置、明确要求进行路由委派，或该角色存在已启用的外部路由后，在为该角色选择路由的外部 CLI／模型路径之前，请查阅：

• /.recursive/config/recursive-router.json
• /.recursive/config/recursive-router-discovered.json
• ../recursive-router/SKILL.md

每次路由派发前，都要从磁盘重新读取这些文件。如果策略、发现状态或回退行为在运行期间可能已发生变化，不要复用先前的内存解析结果。如果 recursive-router-resolve 返回 external-cli，请对该委派时段使用 recursive-router-invoke。仅当路由解析为 fallback-local、local-only、blocked 或 ask-user 时，才可使用本地／自审计执行路径，并且记录的产物必须说明原因。

使用优先级

按以下价值顺序使用子代理：

1. 分析员
2. 规划员
3. 代码审查员
4. 记忆审计员
5. 测试员
6. 仅在写入范围确实互不重叠时使用实现者

不要将子代理视为必需的基础设施。它们是可选基础设施，但只要子代理可用且上下文包完整，委派审计／审查就是首选默认做法。

能力检测是硬性控制点

在考虑委派的阶段开始时，确定环境是否确实支持子代理／任务。

如果子代理不可用：

• 记录 Subagent Availability: unavailable
• 记录 Audit Execution Mode: self-audit
• 在本地执行相同的审计

如果子代理可用：

• 记录 Subagent Availability: available
• 对于上下文包完整的审计／审查工作，默认进行委派
• 如果当前任务明确要求路由委派，或所选角色配置了外部 CLI 路由，则在派发前查阅路由器策略
• 如果控制器仍选择 self-audit，记录具体的 Delegation Override Reason
• 保持相同的审计检查清单和验收标准

委派前，阅读 /.recursive/memory/skills/SKILLS.md，以及与受委派审查、审查包适配性和上下文过时风险相关的技能记忆分片。

绝不要因为无法委派而跳过或弱化审计。

规范约束

• 递归阶段必须按顺序进行。每次运行中恰好只有一个活动阶段。
• 子代理可以协助活动阶段，但不能授权并行开展阶段工作。
• 仅当子阶段明确独立、写入范围互不重叠且不存在阻塞依赖链时，才允许并行进行可写入的实现工作。
• 审计、审查和只读验证是最安全的默认委派模式。

委派审计约定

只有控制器传递了完整的上下文包，委派审计才有效。优先使用 /.recursive/run/<run-id>/evidence/review-bundles/ 下的规范审查包文件，以确保交接持久且可重复。

控制器必须传递以下所有内容：

1. 阶段名称和产物路径
2. 当前阶段草稿
3. 必须重新读取的确切上游产物路径
4. 相关补充文件路径
5. 相关的既往递归证据和记忆引用
6. 来自 00-worktree.md 的差异基准
7. 更改文件列表
8. 要检查的目标代码文件路径或文件组
9. 必要时提供相关控制平面文档
10. 该阶段的确切审计问题／检查清单
11. 所需的输出格式，包括发现和结论

“审查此阶段”或“审计实现”等含糊的委派无效。

如果缺少任何必需项，请勿委派。应自行执行审计。

如果修复实质性地改变了审查范围、更改文件或证据，请在重新审计前更新审查包。

控制器检查清单

派发前：

• 确认委派是可选的，而非必需的
• 确认当前阶段仍是唯一的活动阶段
• 确认交接包完整
• 确认在阶段产物中记录委派时，规范审查包路径确实存在
• 确认将在 /.recursive/run/<run-id>/subagents/ 下写入持久的子 Agent 操作记录
• 确认初始提示词包引用自提示词包路径，且路由后的助手输出、stdout/stderr 记录和调用元数据将保存在 /.recursive/run/<run-id>/evidence/router/ 下，而非直接放在 subagents/ 下
• 确认目标子 Agent 角色与任务匹配
• 在委派任何可写任务前，确认写入范围互不重叠

接受结果前：

• 如果使用了外部 CLI 路由，验证路由调用的 success: true，且退出代码为 0
• 验证子 Agent 已读取指定的上游产物
• 验证子 Agent 已读取审查包或其完整等效内容
• 验证子 Agent 返回了足够的细节，以填充操作记录字段
• 验证 Current Artifact 指向稳定的已审查产物；或者在草稿发生任何实质性编辑后更新记录
• 验证输出引用了差异基准和更改文件
• 验证任何修复后，审查包仍与当前产物哈希相符
• 验证输出包含具体发现，或明确说明未发现问题
• 验证输出在相关情况下包含与需求／计划的一致性说明
• 验证输出以明确结论收尾
• 在接受前，根据实际工作树差异、实际产物和较早锁定的递归文档，核实任何声称的文件影响、产物影响或发现
• 验证阶段产物记录了 Reviewed Action Records、Main-Agent Verification Performed、Acceptance Decision、Refresh Handling 和 Repair Performed After Verification
• 对于实质性贡献的工作，如果操作记录将声称的文件影响或声称的产物影响留为 none，则拒绝该记录
• 如果输出脱离上下文、含糊其辞或缺少必需检查，则拒绝该输出

如果路由的子 Agent 报告失败、发现问题、工作未完成、success: false，或外部 CLI 退出代码非零，则不得接受结果。控制器必须执行审计—修复—重试循环：记录失败尝试和诊断证据；如果该受限角色拥有修复权限，则明确告知同一角色需要修复的内容；重新运行路由；然后针对实际差异和产物重复执行控制器验证。如果路由角色无法修复问题，或路由仍不可用，则在使用本地修复或自审证据之前，先记录明确的回退方案。

推荐角色

分析员

用于现状分析、根因分析，以及其他需要独立分析审查的审计阶段，审查内容包括：

• 当前草稿
• 上游已锁定的工件
• 与记录的基线相比的 git diff
• 需求覆盖情况
• 差距、偏移和修复需求

规划员

用于第 2 阶段规划和可追溯性要求较高的检查，确保下游工件明确覆盖每个范围内的 R#，而不是用含糊的摘要掩盖遗漏。

代码审查员

用于第 3.5 阶段或第 3/4 阶段的高风险审计。

预期检查内容：

• 需求与实现是否一致
• 计划与实现是否一致
• git diff 与声称的范围是否一致
• 代码质量和可维护性
• 测试是否充分以及是否符合 TDD

记忆审计员

在第 8 阶段使用，以验证已触及的路径、记忆状态转换和路由器更新是否与最终验证通过的仓库状态一致。

测试员

在第 4 阶段使用，以审计测试是否充分、命令是否准确、证据是否已采集，以及在采信测试结果前实现是否确实完整。

实现者

仅在第 2 阶段定义了真正独立且文件归属明确的子阶段时使用。

控制器必须明确分配归属，且默认不得将此模式描述为广义的“并行模式”。

交接模板

委派审计或审查时，使用以下结构。优先通过 recursive-review-bundle 生成审查包，然后提供审查包路径以及任何特定于阶段的指示：

Review Bundle Path: `/.recursive/run/<run-id>/evidence/review-bundles/<bundle>.md`
Phase: `03.5 Code Review`
Artifact path: `/.recursive/run/<run-id>/03.5-code-review.md`
Role: `analyst`
Audit execution expectation: return findings plus `Audit: PASS` or `Audit: FAIL`

Bundle freshness check:
- confirm changed files, evidence refs, and audit questions still match the latest repaired draft
- confirm relevant addenda are included; do not hand-wave plan or requirement amendments that live in addenda

Additional audit questions:
- Which `R#` are still incomplete?
- Which changed files drift from the plan?
- Is required evidence missing?
- Is repair required before lock?

Action-record expectation:
- return enough structured detail for `recursive-subagent-action`
- prefer the stable reviewed artifact for `Current Artifact` when recording review/audit work
- cite upstream artifacts reread, relevant addenda, prior recursive evidence, changed files or code refs reviewed, claimed findings, and verification handoff items

自审回退模式

无法使用子 Agent 时，在阶段工件中复用相同的检查清单，并记录：

## Audit Context

Audit Execution Mode: self-audit
Subagent Availability: unavailable
Audit Inputs Provided:
- `/.recursive/run/<run-id>/...`

然后在本地完成完整的审计流程：

1. 起草或修订阶段工件
2. 重读上游工件
3. 根据记录的差异依据和变更文件进行核对
4. 记录差距
5. 修复工作
6. 重新运行审计
7. 仅当阶段确实已准备好锁定时，才设置 Audit: PASS

拒绝输出的规则

如果委派结果存在以下任一情况，则予以拒绝：

• 未引用工件路径或阶段名称
• 未引用审查包路径，也未清楚复述相同的审查包内容
• 未提及重读的上游工件
• 忽略了属于有效输入集的相关补充材料
• 忽略了审查包中包含的相关既往递归证据或记忆引用
• 未审查差异依据或变更文件
• 未在审查说明中引用变更文件或代码引用
• 声称委派工作成功，但控制器未根据实际文件、实际工件和实际差异所属范围核实这些声明
• 无法在不猜测的情况下转化为持久化的子 Agent 操作记录
• 在需要时未说明需求或计划的一致性
• 只有泛泛的赞扬，没有基于实际情况的发现
• 没有明确的结论

参考资料

• 规范工作流：/.recursive/RECURSIVE.md
• 工件模板：../recursive-mode/references/artifact-template.md
• 代码审查员提示词：agents/code-reviewer.md
• 实现者提示词：agents/implementer.md