---
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.  **执行初始化**：
    运行脚本扫描源文件标题结构，并生成工作区：
    ```bash
    python3 .gemini/skills/long-chat-task-processor/scripts/setup_workspace.py "path/to/chat_log.md" "工作区目录名称"
    ```

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

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

```text
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]` 。

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

关于 **3-实体映射表** ，

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

关于 **4-任务池**，

应该包含

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

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

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