log-review

name	log-review
description	审查日志，区分 runtime / skill 问题，并判断是否存在可沉淀的新 Skill
version	2.0.0
author	InspectorCat Team
user_invocable	true

Log Review Skill

触发条件

• "审查日志 [路径]"
• "分析日志 [路径]"
• "看看日志有什么问题"
• 用户上传日志文件并要求分析

支持的 XiaoBa 日志类型：

• 文本运行日志：.log
• 轮次会话日志：.jsonl

工作流程

1. 如果日志很大（>5000 行）或明显很长，先用 analyze_log 的 quick 模式看概览，再决定是否继续 deep
2. 使用 analyze_log 工具分析日志（优先 deep），获取结构化数据
3. 优先基于 issueProfiles[] 做生产路由；再结合 issues[] / toolStats[] / turns[] 补充证据
4. 把问题明确分成 runtime 问题、tool policy / surface / provider 问题、skill 问题、role prompt / usage 问题、external dependency 或 insufficient signal
5. 额外判断是否存在值得沉淀的新 Skill、benchmark/replay 或 EngineerCat handoff 候选
6. 按下面的 报告模板 生成完整 MD 内容
7. 使用 write_file 工具保存报告到日志同目录，文件名格式 report-YYYY-MM-DD.md（用日志文件日期）
8. 如需下游处理，额外写 inspector-handoff.json
9. 向用户发送简短摘要（2-3 句）+ 报告文件路径
10. 如果有严重问题（severity=high），在摘要中醒目提示

硬规则

1. 必须回答三件事：有没有 runtime 问题、有没有已有 skill 的问题、有没有新 skill 候选
2. 必须给归因层级：每个主要问题都要判断更像 runtime、skill、prompt 还是 usage
3. 不要把所有问题都归 runtime；如果是 skill 触发条件太宽、步骤缺失、调用顺序不稳，要明确写成 skill 问题
4. 不要把所有重复都当成新 skill；只有稳定、可参数化、重复至少 3 次的模式才算候选
5. 样本不足必须显式标记：如果 summary.signalQuality=insufficient，不要输出“没问题”，要要求补日志
6. 要尊重日志类型差异：.log 更偏 runtime 执行轨迹，.jsonl 更偏逐轮交互和行为模式；两者都要结合起来看，不要混淆证据层级

报告模板

生成报告时严格按以下模板结构。{...} 占位符用 analyze_log 返回的数据填充。问题列表和改进建议由 AI 根据数据补充分析。

# 日志分析报告

> 生成时间：{当前日期时间}
> 日志文件：{log_source 文件名}
> 分析深度：deep

## 会话概览

| 指标 | 值 |
|------|-----|
| 总轮次 | {summary.totalTurns} |
| Token 消耗 | {summary.inputTokens} + {summary.outputTokens} = {summary.totalTokens} |
| 工具调用次数 | {summary.toolCalls} |
| AI 推理总耗时 | {summary.totalDuration}s |
| 日志时间范围 | {summary.startTime} ~ {summary.endTime} |
| 会话数 | {summary.sessionCount} |
| 交互数 | {summary.interactionCount} |

## 总结结论

- **样本质量**：{summary.signalQuality}；{summary.recommendedIntakeAction}
- **Runtime 判断**：{存在 / 不存在}；一句话说明主结论
- **Skill 判断**：{存在 / 不存在}；一句话说明主结论
- **新 Skill 机会**：{存在 / 不存在}；一句话说明主结论

## Issue Profiles

{遍历 issueProfiles 数组，每个 profile 一个条目}

- **Issue ID**：{issue_id}
- **类别**：{category}
- **严重程度 / 置信度**：{severity} / {confidence}
- **疑似 owner**：{suspected_owner}
- **路由目标**：{route_to_role}
- **建议动作**：{recommended_next_action}
- **证据引用**：{evidence_refs}
- **交接要求**：{handoff.required_artifacts}

## 问题列表

{遍历 issues 数组，每个问题一个章节}

### {序号}. {根据 description 生成简短标题}
- **严重程度**：{issue.severity}
- **发生位置**：{sessionId / interactionId / Turn}
- **类型**：{issue.type}
- **详情**：{issue.description}
- **归因层级**：{runtime / skill / prompt / usage}
- **证据**：{引用日志片段或 analyze_log 返回的 issue/context/toolStats}
- **影响范围**：{单次 / 多次复现 / 系统性}
- **建议动作**：{修 runtime / 调整 skill / 修改 prompt / 调整使用方式}

{如果 issues 为空，写：未发现明显问题。}

## Runtime 问题

{列出最重要的 1-5 个 runtime 问题；如果没有，写“未发现明显 runtime 问题”。}

每个条目至少包含：
- 现象
- 证据
- 影响
- 建议修复方向

## Skill 问题

{列出最重要的 1-5 个已有 skill 问题；如果没有，写“未发现明显 skill 问题”。}

重点看：
- 触发条件太宽 / 太窄
- 步骤缺失
- 工具选择不稳
- 过度依赖平台特定命令
- 明明应该 skill 化却还在手工重复

## 新 Skill 候选

{列出 0-5 个候选；如果没有，写“暂未发现值得沉淀的新 Skill”。}

每个候选至少包含：
- 候选名称
- 触发意图
- 重复证据
- 稳定性判断
- 是否建议提炼（是 / 否）
- 不建议提炼时的原因

## 工具统计

| 工具名 | 调用次数 | 成功 | 失败 | 平均耗时 |
|--------|---------|------|------|---------|
{遍历 toolStats，每行一个工具}

## 改进建议

{AI 根据问题、工具统计和 Skill 候选，给出 2-5 条可操作的改进建议}

{每条建议格式：}
{序号}. **{建议标题}**（优先级：高/中/低）
   - 归属：{runtime / skill / process}
   - 问题：{关联的 issue、工具统计或重复模式}
   - 建议：{具体操作}
   - 预期效果：{改善什么}

---
*Generated by InspectorCat*

注意事项

• 分析完成后 必须 调用 write_file 保存报告，不能只发文本
• 报告中的改进建议由 AI 分析得出，不是工具直接返回的
• 如果日志文件很大（>5000 行），先用 analyze_log quick 模式获取概览，再决定是否 deep 分析
• 优先用 analyze_log 的 signalQuality、issueProfiles、issueCounts、toolStats、issues、turns 做判断，不要脱离证据空谈
• 如果多个问题本质上指向同一个根因，合并归因，不要机械地逐条罗列