/guijios-weekly-review

name: guijios-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` 字段留空），后续直接复用。

---

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

时间范围规则

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

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