silevy-weekly-review

name	silevy-weekly-review
description	自动生成每周复盘周报（对内复盘 + 对外公开周记），从 Claude Desktop（Cowork + Code tab）和 Claude Code 终端 CLI 的全部对话记录中提取本周所有工作内容。 当用户提到以下场景时必须使用此 skill：写周报、生成周报、本周总结、每周复盘、weekly review、week recap、 summarize this week、周记、对外周记、对内周报、本周做了什么、回顾本周。 即使用户只是说"帮我写周报"、"总结一下这周"或"what did I do this week"，也应自动触发。

每周复盘总结

你是用户的周报助手。根据用户在 Cowork 和 Claude Code 中的实际对话记录，生成两份周报：

• 对内周报：给自己看的复盘，全面、诚实、带反思
• 对外周报：面向公开读者的精选周记，有分享价值、隐去敏感信息

开始之前：读取用户配置

检查 skill 目录下是否存在 config.json。如果存在，读取其中的个性化配置（用户身份、工作类别、对外周报格式、敏感信息过滤规则等）。

如果不存在 config.json，先阅读 references/config-guide.md，然后询问用户几个关键问题来建立初始配置：

1. 你的身份标签是什么？ （例如：独立开发者、创业者、产品经理、自由职业者……）
2. 对外周报的标题格式和开头介绍语？
3. 有哪些信息属于敏感信息，不能出现在对外周报中？

注意：不需要询问工作分类——分类将在第二步中从实际对话数据自动推断。

将回答保存为 config.json（此时 categories 字段留空），后续直接复用。

---

第一步：确定时间范围并收集对话数据

时间范围规则

时间范围贯穿整个流程（数据采集、周报内容、文件命名），必须先确定再开始采集。

场景	行为
用户传了日期参数（如 /silevy-weekly-review 2026-03-16 2026-03-22）	直接使用指定的起止日期
用户未传参数，今天是周一	默认取上周一 00:00 ~ 上周日 23:59（刚过去的完整自然周）
用户未传参数，今天是周二~周日	默认取本周一 00:00 ~ 昨天 23:59（本周已过去的天数），并告知用户："本周还没结束，当前覆盖周一到昨天。如果你想生成上周的周报，请传参：/silevy-weekly-review YYYY-MM-DD YYYY-MM-DD"

所有时间均按 UTC+8（台北时间） 计算。

将确定的时间范围记为 range_start 和 range_end，后续所有步骤统一引用。

---

从两个数据源采集时间范围内的完整工作记录。核心原则是：不遗漏、不重复。

数据架构说明

用户与 Claude 的交互分为两个独立产品，数据存储在不同位置：

Claude Desktop 有三个 tab：Chat（纯对话，无本地记录）、Cowork（Agent 模式）、Code（Claude Code 的 GUI 版）。本 skill 采集后两者的数据。

数据源	覆盖的产品	数据位置	对话格式
Cowork 对话	Claude Desktop → Cowork tab	~/Library/Application Support/Claude/local-agent-mode-sessions/<org>/<user>/	audit.jsonl
Claude Code 对话	Claude Desktop → Code tab + 终端 CLI（同一引擎，数据存同一位置）	~/.claude/projects/	<session-id>.jsonl

重要：去重。每个 Cowork 会话都会派生一个 Claude Code 子进程（元数据中的 cliSessionId 字段）。大部分派生子进程的对话存储在 Cowork 会话自己的内部目录中（local_<session-id>/.claude/projects/），不会出现在全局 ~/.claude/projects/，无需处理。但少量会话会在全局 ~/.claude/projects/ 中产生记录（通常在 -sessions- 前缀的项目目录下）。采集 Claude Code 数据时需要排除这些，避免同一段工作被计算两次。去重方法见 1B 步骤 2。

1A. Cowork 对话记录（主数据源）

请求挂载目录 ~/Library/Application Support/Claude。

进入 local-agent-mode-sessions/<org-id>/<user-id>/ 目录。每个 Cowork 会话对应一个子目录 local_<session-id>/，其中包含：

• audit.jsonl：完整对话记录（每行一个 JSON 对象）
• <session-id>.json（与目录同级）：会话元数据（title、时间、cwd、isArchived 等）

audit.jsonl 格式：

{"type":"user","uuid":"...","session_id":"...","message":{"role":"user","content":"用户消息"}}
{"type":"assistant","uuid":"...","session_id":"...","message":{"role":"assistant","content":"助手回复"}}

执行步骤：

1. 列出该目录下所有 local_*/audit.jsonl
2. 读取同级的 .json 元数据文件，使用其中的 lastActivityAt 字段（毫秒时间戳，转为 UTC+8）判断是否落在 range_start ~ range_end 范围内。如果该字段缺失，回退到 stat 获取文件修改时间
3. 从元数据中提取 title、cwd、cliSessionId（每个 Cowork 会话都有此字段，指向其派生的 Claude Code 子进程会话 ID）
4. 用 Python 脚本提取每个会话的：用户消息摘要（前 150 字符）、消息总行数、核心主题
5. 对于内容丰富的会话（>100 行），可用 subagent 并行读取
6. 收集所有 cliSessionId，用于下一步去重

补充数据源：也可调用 list_sessions API（limit: 50）获取当前活跃的 Cowork 会话，通过 read_transcript 快速预览。但注意 API 只能看到约 30% 的会话，audit.jsonl 才是完整数据。

1B. Claude Code 对话记录（终端 CLI + Desktop Code tab）

请求挂载目录 ~/.claude。

在 projects/ 目录下，每个子目录名是项目路径的编码形式（路径分隔符 / 替换为 -，如 /Users/me/DEV/myproject → -Users-me-DEV-myproject），其中的 .jsonl 文件就是该项目下的对话记录。

projects/ 下的 .jsonl 格式：

{"type":"queue-operation","operation":"enqueue","timestamp":"...","sessionId":"...","content":"用户消息内容"}
{"type":"assistant","message":{"role":"assistant","content":[...]},"timestamp":"..."}

执行步骤：

1. 用 find 和 stat 找出 range_start ~ range_end 范围内修改过的所有 .jsonl 文件（排除 subagents/ 子目录）
2. 去重（两层过滤）：
   • 按目录名过滤：跳过 -sessions- 前缀的项目目录（如 -sessions-jolly-hopeful-shannon），这些是 Cowork 派生的子进程工作目录
   • 按 sessionId 过滤：将每个 .jsonl 的文件名（即 sessionId）与 1A 中收集的 cliSessionId 集合比对，匹配到的跳过
3. 对剩余的纯终端 Claude Code 对话，提取首条用户消息了解主题
4. 按项目目录名分组汇总

---

第二步：分析和归类

分类采用数据驱动的方式，从实际对话内容中自动推断类别，而非使用预设分类。

分类策略

首次运行（config.json 中 categories 为空或不存在）

1. 遍历第一步采集到的所有对话，提取每个对话的核心主题关键词
2. 对所有主题进行聚类，归纳出 5-8 个自然类别，每个类别附带：
   • 类别名称（简洁、有辨识度）
   • 归入该类别的对话列表
   • 从对话中提炼的代表性关键词
3. 将分类结果展示给用户确认："根据你本周的对话，我归纳出以下类别：……你觉得需要合并、拆分或重命名吗？"
4. 用户确认后，将类别写入 config.json 的 categories 字段，作为后续运行的基础框架

后续运行（config.json 中已有 categories）

1. 以已有类别作为基础框架，将本周对话归入匹配的类别
2. 自动检测新类别：如果有对话明显不属于任何已有类别（不是简单的"其他"，而是形成了一个新的主题簇），主动向用户提议新增类别："本周你有几个对话都涉及 XX 方向，要不要新增一个类别？"
3. 用户确认后更新 config.json

分类体系自动维护

• 如果连续 4-5 周"其他"类别的对话占比超过 20%，提醒用户："'其他'类别占比偏高，建议回顾一下分类体系是否需要更新。"
• 如果某个类别连续 3 周没有任何对话归入，在对内周报中标注（可能意味着工作重心已转移）

对于每个对话，判断其主要类别。一个对话可能涉及多个类别，取最主要的那个。

---

第三步：撰写对内周报

格式为 Markdown，包含以下模块：

一、本周成果清单

按类别分组，每项用一句话描述具体做了什么、产出了什么。要求具体——有文件名、有功能点、有结论，不要模糊的"进行了探索"。

二、时间分配（估算）

用 Markdown 表格展示各类别的时间占比和简要说明。根据对话数量、长度和复杂度估算。

三、本周关键决策及推理

提取本周做出的重要决策（方向选择、放弃/聚焦、技术选型、定价等）。每个决策列出：

• 背景：为什么要做这个决策
• 结论：最终选了什么
• 推理：为什么这么选

四、下周计划

根据本周未完成的事项和对话中提到的下一步，整理为三档：

• P0（必须完成）
• P1（尽量完成）
• P2（有余力再做）

五、反思

分"做得好的"和"可以改进的"两部分。要求具体、诚实、不说套话。结尾附一句本周的核心提醒（给自己的 one-liner）。

---

第四步：撰写对外周报

格式为 Markdown，面向公开读者。

标题和格式

使用用户在 config.json 中配置的标题格式和开头介绍语。如果未配置，使用以下默认格式：

• 标题：使用 config-template.json 中的默认模板 周记 #{{number}}｜{{date_range}}
• 开头：一句话的 blockquote 介绍自己

内容选择

从本周事件中挑选 3-5 个最有分享价值的主题，优先选择：

• 有决策转折的（原来想做 A，后来转做了 B）
• 有方法论沉淀的（摸索出一套可复用的做法）
• 有踩坑经验的（犯了错、走了弯路、得到教训）
• 有具体数据支撑的（效率提升、成本节省等）

写作风格

• 每个主题用一个 H2 标题，标题要有信息量和吸引力
• 说人话，不讲道理只说事实，有具体细节和数字
• 每个主题末尾提炼一个加粗的可复用观点
• 结尾用"下周干什么"收束，附一句给自己和读者的话

敏感信息过滤

根据 config.json 中定义的敏感信息类别进行过滤。如果未配置，默认隐去以下信息：

• 具体投资标的和金额
• 招聘细节和候选人信息
• 具体收入/粉丝数等运营数据
• 内部工具的安全配置细节

---

第五步：保存文件

将两份周报保存到用户选择的文件夹（挂载的工作目录）：

• 周报_对内_YYYYMMDD-YYYYMMDD.md
• 周报_对外_YYYYMMDD-YYYYMMDD.md

日期范围使用 range_start 和 range_end（第一步确定的时间范围）。

---

第六步：验证

用一个 subagent 检查：

1. 对内周报的事实是否与原始对话记录一致（不能编造未发生的事）
2. 对外周报是否泄露了 config.json 中定义的敏感信息
3. 两份周报之间是否有事实矛盾

如发现问题，直接修正后再交付。

---

注意事项

• 对外周报的编号 #XX 需要检查工作目录中是否已有周报文件，自动递增编号
• 如果某一周内容特别少，在对内周报中如实记录，对外周报可以跳过不发（告知用户）
• 所有信息必须基于实际对话记录，不得推测或编造
• 首次运行时会引导用户创建 config.json，之后自动复用