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` 格式：
```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` 格式：
```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`，之后自动复用