| 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，然后询问用户几个关键问题来建立初始配置：
- 你的身份标签是什么？ （例如：独立开发者、创业者、产品经理、自由职业者……）
- 对外周报的标题格式和开头介绍语？
- 有哪些信息属于敏感信息，不能出现在对外周报中？
注意：不需要询问工作分类——分类将在第二步中从实际对话数据自动推断。
将回答保存为 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":"助手回复"}}
执行步骤：
- 列出该目录下所有
local_*/audit.jsonl
- 读取同级的
.json 元数据文件，使用其中的 lastActivityAt 字段（毫秒时间戳，转为 UTC+8）判断是否落在 range_start ~ range_end 范围内。如果该字段缺失，回退到 stat 获取文件修改时间
- 从元数据中提取 title、cwd、cliSessionId（每个 Cowork 会话都有此字段，指向其派生的 Claude Code 子进程会话 ID）
- 用 Python 脚本提取每个会话的：用户消息摘要（前 150 字符）、消息总行数、核心主题
- 对于内容丰富的会话（>100 行），可用 subagent 并行读取
- 收集所有
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":"..."}
执行步骤：
- 用
find 和 stat 找出 range_start ~ range_end 范围内修改过的所有 .jsonl 文件（排除 subagents/ 子目录）
- 去重（两层过滤）：
- 按目录名过滤：跳过
-sessions- 前缀的项目目录（如 -sessions-jolly-hopeful-shannon），这些是 Cowork 派生的子进程工作目录
- 按 sessionId 过滤：将每个
.jsonl 的文件名（即 sessionId）与 1A 中收集的 cliSessionId 集合比对，匹配到的跳过
- 对剩余的纯终端 Claude Code 对话，提取首条用户消息了解主题
- 按项目目录名分组汇总
第二步：分析和归类
分类采用数据驱动的方式，从实际对话内容中自动推断类别，而非使用预设分类。
分类策略
首次运行（config.json 中 categories 为空或不存在）
- 遍历第一步采集到的所有对话，提取每个对话的核心主题关键词
- 对所有主题进行聚类，归纳出 5-8 个自然类别，每个类别附带：
- 类别名称（简洁、有辨识度）
- 归入该类别的对话列表
- 从对话中提炼的代表性关键词
- 将分类结果展示给用户确认："根据你本周的对话，我归纳出以下类别：……你觉得需要合并、拆分或重命名吗？"
- 用户确认后，将类别写入
config.json 的 categories 字段，作为后续运行的基础框架
后续运行（config.json 中已有 categories）
- 以已有类别作为基础框架，将本周对话归入匹配的类别
- 自动检测新类别：如果有对话明显不属于任何已有类别（不是简单的"其他"，而是形成了一个新的主题簇），主动向用户提议新增类别："本周你有几个对话都涉及 XX 方向，要不要新增一个类别？"
- 用户确认后更新
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 检查：
- 对内周报的事实是否与原始对话记录一致（不能编造未发生的事）
- 对外周报是否泄露了
config.json 中定义的敏感信息
- 两份周报之间是否有事实矛盾
如发现问题，直接修正后再交付。
注意事项
- 对外周报的编号
#XX 需要检查工作目录中是否已有周报文件，自动递增编号
- 如果某一周内容特别少，在对内周报中如实记录，对外周报可以跳过不发（告知用户）
- 所有信息必须基于实际对话记录，不得推测或编造
- 首次运行时会引导用户创建
config.json，之后自动复用
