summarize

name: summarize description: "Summarize conversations, logs, docs, or investigation notes into action-oriented text with evidence tags. Use for recap, handoff, CI failure digest, or MEMORY. Triggers: 总结, 汇总, summarize, 交接, 复盘, 调试总结." keywords: - summarize - summary - recap - notes - 总结 - 交接 - 复盘 - handoff tags: - writing - memory - documentation

Summarize

把已有材料压缩成可交接、可执行的摘要。只写能指回证据的事实；无证据不写结论。

何时使用

• 长对话 / 调试会话交接
• CI / 测试失败浓缩
• 写入 Issue、PR、MEMORY 前的草稿

不适用

• 用户要「分析根因并给出修复方案」→ 先调查再总结，或直接用开发 skill
• 材料只有一句模糊描述 → 先追问，不要编造细节

工作流

第 1 步：确认受众与材料是否够用

材料充分度检查（缺任一项则进入「材料不足模式」，见第 2 步）：

• 失败现象或目标（用户原话或日志一行）
• 至少一条已执行的命令 + 结果（或明确写「未跑验证」）
• 相关路径 / 版本 / 配置名（如有）

第 2 步：选模式

A. 材料不足模式（无日志、无命令结果、仅口头描述）：

禁止输出「已完成」章节。只用：

## 概要
材料不足，以下为**待确认清单**（非最终结论）

## 已从上下文提取（附来源）
- [待确认] … — 来源：用户原话 / 对话片段

## 待用户补充
- [ ] 完整错误日志或 CI job 链接
- [ ] 已运行的命令及输出
- [ ] 相关文件路径（如 `zhin.config.yml`）

## 建议下一步
1. …

B. 材料充足模式：按第 3–4 步选模板，并遵守事实分级。

第 3 步：事实分级（写入时强制）

每条 bullet 格式：[确认] 结论 — 来源：pnpm test` 失败于 demo-config.test.ts ENOENT``

第 4 步：按场景输出

默认（材料充足）：

## 概要
（1–2 句，仅 [确认] 事实）

## 已完成
- [确认] … — 来源：…

## 未完成 / 阻塞
- [待确认] … — 来源：…

## 关键命令与结果
- `命令` → 结果（一行）

## 下一步（按优先级）
1. …

CI / 测试失败（含 ENOENT、类型错误、端口占用）：

## 概要
Job/包：… | 首条错误：…

## 失败信号
- 命令：…
- 错误（原文一行）：…
- 涉及文件：…（若 ENOENT 写明缺失路径）

## 已排除（须 [确认]）
- … — 来源：…

## 下一步
1. …

调试会话交接：

## 当前状态
- 分支/commit：…
- 服务可达性：… — 来源：curl/日志

## 时间线（按发生顺序，每条带标记）
1. [确认] … — 来源：…

## 已尝试
- `命令` → 结果

## 阻塞
- [待确认] … — 来源：…

## 待办
1. …

用户要求 exhaustive 时再扩展章节；默认保持短。

🔴 CHECKPOINT · 敏感信息

写入 Issue、PR、公开 MEMORY 前：删除 token、.env、用户 ID、内网 URL → <REDACTED>。

🔴 CHECKPOINT · 材料不足

若第 1 步检查未通过，必须用材料不足模式，不得用默认模板的「已完成」填空。

失败与兜底

不要做什么

• 不要把推测写进「已完成」（无命令/日志支撑 = [待确认]）
• 不要把摘要写成营销或过度乐观
• 不要省略失败原因（禁止只写「有问题」「500」）
• 不要无日志时编造调试时间线
• 不要在摘要里泄露 token、密码、私聊 ID
• 不要默认生成长报告（除非用户明确要求）

延伸阅读