Long Chat Task Processor Agent Skill
对大量原始聊天记录进行结构化整理，进行知识提取或生成任何主题分析文档
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/cafe3310/public-agent-skills --skill long-chat-task-processorThe instruction itself
4 sections, as written by the author聊天记录项目化处理工作流 (Long Chat Task Processor)
此技能旨在将非结构化的、按标题组织的聊天记录（Markdown格式）转化为可执行的项目管理资产。它严格基于文档目录结构 (TOC) 进行分段处理，而非简单的行数切分，以确保对话上下文的完整性。
使用时机
当用户提供导出的聊天记录（Markdown），且记录使用标题（#, ##...）区分不同群聊或对话对象时。
用户通常要求：
- 项目化梳理：提取任务(Assigner/Assignee)、状态(Status)、决策(Decision)。
- 特定产出物：根据聊天内容撰写周报、Bug清单、特定事件的时间线复盘等。
- 背景对齐：处理过程中需要参考用户提供的背景文档（如 PRD、人员表）。
工作流
1. 准备阶段 (Initialization)
首先，必须初始化工作区并解析文档结构。
- 接收输入：确认源文件、背景文档、以及用户的额外诉求（例如：“帮我把所有关于 API 的讨论单独整理成一个文档”）。
- 执行初始化：
运行脚本扫描源文件标题结构，并生成工作区：
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-额外输出/ # 存放用户要求的额外的输出文档
- 将用户的指示和背景文档复制到
2-项目背景/目录下，确保后续处理有据可依。
2. TOC 分段处理循环 (TOC Loop)
打开 0-工作日志.md，你将看到一个基于 Markdown 标题层级的任务树。
按顺序处理每一个标记为 [ ] 的 Section。
在处理每个 Section 前，务必读取：
-
0-工作日志.md(获取当前 Section 的行号范围、标题背景) -
2-项目背景/(理解业务上下文) -
3-实体映射表.md(确保人名对齐) - 用户的额外诉求 (确认本段对话是否涉及需要单独输出的主题)
处理步骤：
- 读取内容：根据日志中记录的
Line Start-End，读取1-原始记录/中对应的内容。 - 执行分析 (Analysis)：
- 通用提取：
- 任务：更新
4-任务池.md。格式：[ ] <Time> Assigner -> Assignee: <Task> (Status) - 决策：更新
5-决策与里程碑.md。 - 新实体：发现新人名/黑话，追加到
3-实体映射表.md。 - 特定主题提取 (Extra Requests)：
- 如果用户的诉求包含“整理 API 问题”、“输出周报素材”等，且当前段落包含相关信息：
- 在
6-最终输出/下创建或追加对应的文档（例如6-最终输出/API_Issue_Log.md）。 - 更新状态：
- 在
0-工作日志.md中将该 Section 标记为[x]。
3. 整合与交付 (Synthesis)
当所有 Section 处理完毕后：
- 整理任务池：检查
4-任务池.md，合并重复项，按人名或优先级归类。 - 生成最终交付物：
- 如果用户要的是一份完整的汇总报告，基于
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-任务池，
应该包含
- 我交给别人的事情和每件事情的跟进状态
- 别人交给我的事情和每件事情的跟进状态
- 完整的事件分派时间线（包括上述两种，和「别人分派给别人的」）。
- 关键文档链接和图片（如果缩略了，列出来源群聊/单聊和上下消息，我可以自己找。）
- 落单任务（无人应答的任务）
事项可以按如下格式记录：
<时间> 交代人 -> 接收人 <事项>
- 来源群或单聊：XXX
- 交付物
- 是否确认和认可
- 后续状态
Other skills for the same job
different authors, same section of the catalogue
Prepare meeting materials with Notion context and Codex research; use when gathering context, drafting agendas/pre-reads, and tailoring materials to attendees.
> This skill generates, creates, or builds brand voice guidelines from source materials. It should be used when the user asks to "generate brand guidelines", "create a style guide", "extract brand voice", "create guidelines from calls", "consolidate brand materials", "analyze my sales calls for brand voice", "build a brand playbook from documents", "synthesize a voice and tone guide", or uploads brand documents, transcripts, or meeting recordings for brand analysis. Also triggers when the user has a discovery report and wants to convert it into actionable guidelines.
Prepares meeting materials by gathering context from Notion, enriching with Claude research, and creating both an internal pre-read and external agenda saved to Notion. Helps you arrive prepared with comprehensive background and structured meeting docs.
Share a Google Docs document with edit access and email collaborators the link.
> Lightweight NDA, MSA, and vendor contract review for SMBs without legal on staff. Reads contracts from local files, Gmail attachments, or DocuSign envelopes; flags non-standard terms; explains risks in plain English; and outputs a marked-up redline as a separate DOCX. Use when the user says "review this contract," "what am I signing," "red flags," "flag any concerns," "check the payment terms," or uploads/forwards a contract or legal agreement.
Search across all connected sources in one query. Trigger with "find that doc about...", "what did we decide on...", "where was the conversation about...", or when looking for a decision, document, or discussion that could live in chat, email, cloud storage, or a project tracker.
Check the status of existing agreements with a vendor across all connected systems — CLM, CRM, email, and document storage — with gap analysis and upcoming deadlines. Use when onboarding or renewing a vendor, when you need a consolidated view of what's signed and what's missing (MSA, DPA, SOW), or when checking for approaching expirations and surviving obligations.
Ingest supplied source material into an Obsidian vault with provenance and claim tracking: pasted text, files staged in the selected vault's inbox or .raw archive, or explicitly approved URLs. Use for a single source or bounded batch, not for saving an assistant answer. Triggers: ingest, ingest this file, ingest this URL, process this source, read and file this source, batch ingest, ingest these sources.
How to use it
Take cafe3310/long-chat-task-processor from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.