long-chat-task-processor

name	long-chat-task-processor
description	对大量原始聊天记录进行结构化整理，进行知识提取或生成任何主题分析文档
license	Apache-2.0
author	github/cafe3310
depends_on_skill	[]
depends_on_binary	["python3"]

聊天记录项目化处理工作流 (Long Chat Task Processor)

此技能旨在将非结构化的、按标题组织的聊天记录（Markdown格式）转化为可执行的项目管理资产。它严格基于文档目录结构 (TOC) 进行分段处理，而非简单的行数切分，以确保对话上下文的完整性。

使用时机

当用户提供导出的聊天记录（Markdown），且记录使用标题（#, ##...）区分不同群聊或对话对象时。 用户通常要求：

1. 项目化梳理：提取任务(Assigner/Assignee)、状态(Status)、决策(Decision)。
2. 特定产出物：根据聊天内容撰写周报、Bug清单、特定事件的时间线复盘等。
3. 背景对齐：处理过程中需要参考用户提供的背景文档（如 PRD、人员表）。

工作流

1. 准备阶段 (Initialization)

首先，必须初始化工作区并解析文档结构。

1. 接收输入：确认源文件、背景文档、以及用户的额外诉求（例如：“帮我把所有关于 API 的讨论单独整理成一个文档”）。
2. 执行初始化： 运行脚本扫描源文件标题结构，并生成工作区：

   python3 .gemini/skills/long-chat-task-processor/scripts/setup_workspace.py "path/to/chat_log.md" "工作区目录名称"
   

工作区目录名称可使用 YYYY-MM-DD-HH 沟通记录整理 格式。

初始化后，工作区结构如下：

Chat_Projectization_YYYY-MM-DD-HH-MM/
├── 0-工作日志.md           # [核心] 基于 TOC 生成的树状任务列表
├── 1-原始记录/             # 存放源文件
├── 2-项目背景/             # 存放用户提供的背景文档，以及用户的所有指示
├── 3-实体映射表.md         # [动态] 自动积累的人名/概念术语表
├── 4-任务池.md             # [动态] 累积提取的任务列表
├── 5-决策与里程碑.md       # [动态] 累积提取的决策和时间点
└── 6-额外输出/             # 存放用户要求的额外的输出文档

3. 将用户的指示和背景文档复制到 2-项目背景/ 目录下，确保后续处理有据可依。

2. TOC 分段处理循环 (TOC Loop)

打开 0-工作日志.md，你将看到一个基于 Markdown 标题层级的任务树。 按顺序处理每一个标记为 [ ] 的 Section。

在处理每个 Section 前，务必读取：

• 0-工作日志.md (获取当前 Section 的行号范围、标题背景)
• 2-项目背景/ (理解业务上下文)
• 3-实体映射表.md (确保人名对齐)
• 用户的额外诉求 (确认本段对话是否涉及需要单独输出的主题)

处理步骤：

1. 读取内容：根据日志中记录的 Line Start-End，读取 1-原始记录/ 中对应的内容。
2. 执行分析 (Analysis)：
   • 通用提取：
     • 任务：更新 4-任务池.md。格式：[ ] <Time> **Assigner** -> **Assignee**: <Task> (Status)
     • 决策：更新 5-决策与里程碑.md。
     • 新实体：发现新人名/黑话，追加到 3-实体映射表.md。
   • 特定主题提取 (Extra Requests)：
     • 如果用户的诉求包含“整理 API 问题”、“输出周报素材”等，且当前段落包含相关信息：
     • 在 6-最终输出/ 下创建或追加对应的文档（例如 6-最终输出/API_Issue_Log.md）。
3. 更新状态：
   • 在 0-工作日志.md 中将该 Section 标记为 [x]。

3. 整合与交付 (Synthesis)

当所有 Section 处理完毕后：

1. 整理任务池：检查 4-任务池.md，合并重复项，按人名或优先级归类。
2. 生成最终交付物：
   • 如果用户要的是一份完整的汇总报告，基于 4、5 和 6 中的内容进行汇总。
   • 如果用户要的是分散的文档（如“任务清单”+“会议纪要”），则分别整理输出。

关键原则

• TOC 优先：不要跨标题合并处理，除非标题层级非常深且内容极少。保持“一个群聊/一个话题”的独立上下文。
• 时间标记：群聊记录中通常使用 -- 日期 或 -- 日期 时间 (如 -- 02-09 15:00) 来标记时间点，可用于参考。
• 上下文补全：聊天中常出现的“那个东西”、“昨天说的”，尽量根据同 Section 的上下文进行指代消解。
• 宁滥勿缺：聊天记录中模糊的任务先记录下来，标记为 Status: UNCONFIRMED。
• 增量原则：在处理每个 Section 时，对 映射表、任务池、决策文档、额外输出做「信息增量更新」：
  • 如果概念、任务、决策、文档内容是全新的，进行追加。
  • 如果可以对已有的内容进行修正、更新、增补，则更新已有内容，使信息更完善。
• 输出文档先读再编辑: 分段处理时，如果使用 write 工具，很容易导致已有内容丢失。在编辑上述输出文档时，必须遵循 先读、再考虑如何编辑、再写 的原则，使用 edit 工具。

注意事项

• 重点关注链接、包含关键信息的图片。
• 尤其重点关注其他人指派给我的事情，以及我是否认可。
• 也要关注我交给别人的事情，以及对方是否认可。
• 如果用户打断你的编辑并指导你的失误，务必遵照执行并修正，注意你要 重做被打断的编辑 ，不要漏掉编辑操作。
• 任务可能中断，如果用户告知「从已有任务继续工作」，无需创建工作区，但 必须 阅读已有的 2-项目背景/ 和 3-实体映射表.md 以恢复上下文。然后继续处理 0-工作日志.md 中未完成的 Section。

输出规范

关于 0-工作日志 ，

可以类似这种格式，在 Agent 处理完成后，将对应的 [ ] 改为 [x] 。

- [ ] **群聊：API 稳定性治理** (Line 100-167)
- [ ] **私聊：小张** (Line 168-600)

关于 3-实体映射表 ，

可以包含人和人的角色、群、组织、项目、概念等的解释，作为多次 Agent 工作之间的上下文补充。 不要使用表格。

关于 4-任务池，

应该包含

1. 我交给别人的事情和每件事情的跟进状态
2. 别人交给我的事情和每件事情的跟进状态
3. 完整的事件分派时间线（包括上述两种，和「别人分派给别人的」）。
4. 关键文档链接和图片（如果缩略了，列出来源群聊/单聊和上下消息，我可以自己找。）
5. 落单任务（无人应答的任务）

事项可以按如下格式记录：

<时间> 交代人 -> 接收人 <事项>
- 来源群或单聊：XXX
- 交付物
- 是否确认和认可
- 后续状态