majiayu000 Claude Recap — 近期活动回顾与操作系统审计
从原始行为数据（而非用户自述）回答三个问题：
- 我最近都在做什么？
- 里面有什么可复用的模式？
- 我的工作系统该加什么、该删什么？
与近亲 skill 的边界（不要重复造）
- 深度认知分析（Dreyfus/Bloom 五层画像）→ 转交
cognitive-portrait - 组合违规核验（冻结仓库、未推送工作）→ 转交
better-audit - Codex 历史自省 → 转交
codex-retrospective - 本 skill 只做：轻量、无依赖、直接读 jsonl 的活动回顾 + 系统级建议
Step 1: 提取数据（确定性部分，用脚本）
脚本随本 skill 分发（scripts/extract_sessions.py）。Claude 安装位于 ~/.claude/skills/recap，Codex 安装位于 ~/.agents/skills/recap，先解析实际位置再运行：
SKILL_DIR=$(ls -d ~/.claude/skills/recap ~/.agents/skills/recap 2>/dev/null | head -1)
python3 "$SKILL_DIR/scripts/extract_sessions.py" --days 2
--days N调整回看窗口（默认 2；周回顾用 7）--json输出结构化数据供进一步处理- 输出：每个主会话的机器、项目、窗口内起止时间、用户消息数、工具调用数、子 agent 数、体积、前 3 条用户消息
- 统计只计入窗口内的消息；跨窗口 resume 的老会话会标
resumed，其窗口前的历史不会混入本次回顾
跨机器汇聚（可选）
scripts/sync_remote_sessions.sh 把远程机器的 ~/.claude/projects rsync 到本机 ~/.claude/remote-sessions/<host>/projects，extract 脚本会自动发现这些目录并一并扫描（会话标 @<host>）：
"$SKILL_DIR/scripts/sync_remote_sessions.sh" starlight # 或 RECAP_SYNC_HOSTS="host1 host2"
- 前提：目标机器已配置 SSH 免密（
~/.ssh/config里的 host 别名） - 建议挂 cron 每日同步；某台机器同步失败会返回失败状态，避免误以为数据完整
- 其他目录可用
--extra-root label=path显式加入扫描；显式路径不存在时应先修正路径再继续
如果用户提到 Codex，补充检查 ~/.codex/sessions（如存在）并说明覆盖范围。
Step 2: 主题分组（LLM 分析）
把会话按意图而非项目分组。常见类别：
- 库审计/改造（"看看这个库有什么问题"类）
- 元层面审计（读自己的记录、设计管理系统）
- 方向/战略探索（"我该做什么"、影响力）
- 内容生产
- 日常运维（诊断、清理）
每组列出：涉及项目、会话数、代表性原话（引用用户消息，不要改写）。
Step 3: 操作系统覆盖映射（固定维度，每次必做）
把 Step 2 的分组映射到六大个人操作系统，输出覆盖表。判定只依据本窗口内的会话证据，没有证据就标"未运转"，不推测。
| 操作系统 | 判定信号（会话中出现即计入） |
|---|---|
| 编码生产 | 库审计、spec/issue 生成、实现 PR、代码 review、构建修复、验证动作 |
| 本地/混合 AI 实验室 | GPU/推理调度、模型路由、gateway/proxy 运营、成本或质量监控 |
| 内容与知识合成 | 信息源调研、深度阅读、文章/线程/脚本产出、素材整理 |
| Agentic 编排与记忆 | 多 agent 协调、workflow/harness 设计、memory 系统操作 |
| 成长与基础设施 | portfolio/goals 管理、billing/proxy 优化、工具链演进、机器运维 |
| 分发与影响力 | 发布动作、仓库门面整改、增长实验、发布后数据回收 |
覆盖表格式（每行必须附会话 ID 证据或标注缺失）：
| 操作系统 | 覆盖度 | 证据（会话ID）| 缺失环节 |
- 覆盖度分四档：重度运转 / 有活动 / 未运转 / 有活动但闭环缺失（要指明缺上游还是下游）
- 特别检查闭环完整性：内容系统看有无"发布后数据回流"，编码系统看有无"验证收尾"，实验室系统看有无"成本/质量监控"
- 连续多次 recap 中"未运转"的系统 → 在建议区提示：是主动挂起（合理）还是资产闲置（该处置）
Step 4: 模式与风险识别
在分组之上找跨会话模式，重点检查：
| 信号 | 说明 |
|---|---|
| 重复出现的 prompt 句式 | 候选固化为 skill（引用 3 次以上的原话为证据） |
| 流水线形态 | 同一套步骤在多个项目上重复执行（如 审计→spec→实现→验证） |
| spec 通胀 | spec/issue 生成速度远超实现与验证速度 |
| 未闭环会话 | 有生成动作但无验证动作的会话 |
| 救火占比 | 诊断/修复类会话占总量的比例 |
Step 5: 输出增删建议
按以下格式收尾（遵守 W-11：事实标来源，推断标置信度）：
## 你这 N 天做了什么（事实）
<分组汇总，每条附会话 ID>
## 操作系统覆盖表（事实）
<Step 3 的六系统覆盖表>
## 模式（推断，附置信度）
<跨会话模式，引用原话为证据>
## 建议（附前提假设）
- 该固化的：<重复 3 次以上的流程 → skill 候选>
- 该删的：<零触发的规则/skill、未闭环的 spec>
- 该警惕的：<spec 通胀、验证缺口等>
规则
- 只读，不修改任何会话文件
- 引用用户消息时保留原文，最多截断不改写
- 建议数量克制：每类最多 3 条，宁缺毋滥
- 若窗口内会话超过 30 个，先按项目聚合再分析，避免逐条展开