recommend-evolution

推荐演进

概述

当反复出现的证据表明缺少某项能力时，推荐生态系统演进，并以标准的机器可读格式记录建议。

适用场景

• 反思发现，具有相同根因的交付失败反复出现
• 路由器/分析信号表明，对于反复出现的请求，没有合适的 Agent 或技能
• 反复出现的集成缺口意味着缺少某种制品类型或策略
• 用户明确请求新的能力路径

铁律

1. 绝不从此技能直接启动 evolution-orchestrator——此技能仅记录建议；执行决策由 orchestrator 和审批流程负责。
2. 始终先根据已定义的阈值验证触发类型，再记录建议——模糊的观察不算触发条件；必须有具体的失败次数或路由未命中情况。
3. 绝不在 artifact-integrator 或 skill-updater 能解决缺口时创建新的演进请求——演进仅用于新增能力，不用于集成或更新缺口。
4. 始终将建议追加到 JSONL 队列，并在当前输出中包含必需的报告块——双重记录可确保建议在运行时和审查时都能被发现。
5. 绝不在没有证据的情况下提出建议——单次失败只是噪声；设置触发阈值自有其原因。

面向反思/规划 Agent 的演进建议技能。 - 触发分类（`repeated_error`、`no_agent`、`integration_gap`、`user_request`、`rubric_regression`、`stale_skill`、`other`） - 建议与集成之间的分支判断 - 双重记录模式：JSONL 运行时队列 + 反思报告块

触发分类说明

recommend-evolution 使用面向原因的触发分类（repeated_error、no_agent、integration_gap、user_request、rubric_regression、stale_skill、other）。

这与 skill-updater 有意不同，后者使用面向调用方的触发分类（reflection、evolve、manual、stale_skill），用于说明由谁/什么启动了更新流程。

步骤 0：验证触发类型

使用以下阈值：

• repeated_error：同一类失败出现在 5 个或更多任务中
• rubric_regression：同一类任务的分数反复低于阈值
• no_agent：反复出现的需求没有有效的路由匹配
• integration_gap：缺少现有制品的集成（优先使用 artifact-integrator）
• user_request：明确请求当前不具备的能力
• stale_skill：审计流程报告已验证制品超过 6 个月，或 lastVerifiedAt 无效

步骤 1：决定建议路径

• 如果缺口是现有制品的集成，优先使用： Skill({ skill: 'artifact-integrator' })
• 如果缺口是现有技能过时/表现不佳，优先使用： Skill({ skill: 'skill-updater' })
• 如果缺口需要新增能力/制品，则继续提出演进建议
• 如果不需要更改制品，只更新记忆，然后退出

步骤 2：创建标准建议载荷

构建一个包含必需字段的 JSON 对象：

{
  "timestamp": "2026-02-14T00:00:00.000Z",
  "source": "reflection-agent",
  "trigger": "repeated_error",
  "evidence": "Same routing failure observed in 6 tasks over 2 days.",
  "suggestedArtifactType": "skill",
  "summary": "Create a new routing-context skill for reflection-time grounding.",
  "status": "proposed"
}

架构参考： .claude/schemas/evolution-request.schema.json

步骤 3：记录建议

1. 将 JSON 行追加到： .claude/context/runtime/evolution-requests.jsonl
2. 添加必需的报告块：

## Evolution Recommendation

- Trigger: <trigger>
- Evidence: <evidence>
- Suggested Artifact Type: <type|null>
- Summary: <1-2 sentences>
- Queue Record: `.claude/context/runtime/evolution-requests.jsonl`

步骤 3：输出

返回建议摘要以及已记录的内容。

</execution_process>

**调用示例**：

// Repeated failure pattern -> recommend skill creation
Skill({
  skill: 'recommend-evolution',
  args: '--trigger repeated_error --suggestedArtifactType skill',
});

// Routing miss -> recommend new agent/workflow discussion
Skill({ skill: 'recommend-evolution', args: '--trigger no_agent --suggestedArtifactType agent' });

</usage_example>

反模式

反模式	为什么会失败	正确做法
直接从此技能启动 evolution-orchestrator	违反单一职责原则；绕过审批和资源门槛	仅将建议记录到 JSONL 队列；由协调器决定是否执行
为已有相关产物的集成缺口记录演进请求	如果修复集成问题就能解决，却创建了不必要的新产物	优先检查 artifact-integrator 路径；仅当缺口需要全新能力时才升级处理
提交没有触发证据的建议	未经充分了解的演进会浪费资源，并让噪声污染队列	必须提供具体证据：失败次数、路由遗漏日志或明确的用户请求
将过时技能触发交由此技能处理，而不是交给 skill-updater	升级路径错误；为本应在更新周期内完成的工作创建演进请求	将 stale_skill 触发直接交给 skill-updater；仅当技能无法更新时才升级处理
单次失败后就触发演进	单次失败属于噪声；过早演进会浪费构建能力	应用规定的阈值：重复错误达到 5 次以上，或多次会话中持续出现路由遗漏

记忆协议（强制）

开始前：

使用 Read 或 Node fs.readFileSync（跨平台）读取 .claude/context/memory/learnings.md。

完成后：

• 建议模式 -> .claude/context/memory/learnings.md
• 模糊的触发逻辑 -> .claude/context/memory/issues.md
• 演进策略决策 -> .claude/context/memory/decisions.md

假设工作可能中断：你的上下文可能会重置。如果没有记录在记忆中，就等于没有发生。