log-to-role

name	log-to-role
description	从长日志里提炼可长期存在的 doctor 角色定义，或退化成一组更合适的 skills
version	1.0.0
author	InspectorCat Team
user_invocable	true
invocable	both
argument-hint	<日志文件路径>
max-turns	30

Log to Role

当一份长日志记录了用户在某个领域从 0 到 1 完成一类复杂任务时，不只要问“能不能提炼几个 skill”，还要判断是否已经出现了一个稳定的专业角色。

这个 skill 用来把日志沉淀成：

• 一个 doctor 风格的角色候选
• 或一组更合适的 skills

触发条件

• "从日志提炼角色"
• "这个日志能不能做成 doctor"
• "从这份长日志生成角色或 skills"
• 用户明确表示要从真实工作流中沉淀 agent

硬规则

1. 必须先调用 analyze_log（deep 模式），不要直接全文通读长日志
2. 先做归因：把日志里的问题区分成 runtime、已有 skill 缺陷、和稳定工作流
3. 只有长期稳定的专业判断模式，才建议升级成 role
4. 如果只是几个可拆分的重复流程，不要硬造 role，应该拆成 skills
5. role 候选必须写清楚边界：负责什么、不负责什么、典型输入、典型输出、优先工具、移交条件

判断标准

什么时候更像一个 role

同时满足越多越像 role：

• 日志围绕一个持续的问题域，而不是离散任务
• 不只是重复步骤，还体现稳定的审查视角或决策偏好
• 需要长期保持同一种质量标准或判断框架
• 有明确的“先看什么、后判什么、何时升级/移交”的流程
• 未来用户会把它当成一个长期同类问题的入口

什么时候更像一些 skills

更符合下面特征时，优先拆成 skills：

• 主要是固定步骤的重复执行
• 可以被 1 到 3 句触发词清楚召回
• 输入输出边界清楚，容易参数化
• 不需要长期人格、审查风格或决策立场

执行流程

1. 用 analyze_log deep 模式获取 turns、issues、toolStats、issueCounts
2. 总结这份日志的主线任务域
3. 区分：
   • 哪些是 runtime 问题
   • 哪些是已有 skill 问题
   • 哪些是稳定的人工工作流
4. 对稳定工作流做二选一判断：
   • 应提炼成 role
   • 应拆成 1 到 N 个 skills
5. 输出正式草案

输出模板

# Role / Skill 提炼结论

## 主结论
- 建议形态：Role / Skills / 暂不建议沉淀
- 原因：...

## Runtime 噪音
- 列出会污染判断的 runtime 问题

## 稳定模式
- 模式名称
- 证据
- 重复度
- 稳定性

## 如果建议提炼为 Role
- 角色名
- 一句话定位
- 第一职责
- 第二职责
- 不负责什么
- 典型输入
- 典型输出
- 工具优先级
- 何时移交给别的角色

## 如果建议拆成 Skills
- Skill 名称
- 触发意图
- 输入参数
- 输出结果
- 为什么不需要做成 role

特别注意

• 如果日志主要体现的是“发现问题并修系统”，优先考虑 doctor/reviewer 型角色
• 如果日志主要体现的是“执行某类完整业务流程”，再考虑领域角色
• 如果日志同时包含大量 runtime 异常，先把这些异常当噪音剥离，不要把异常流程本身做成角色