Codex Review

把最近一段时间的 Codex 使用记录整理成一份可快速浏览、能指导下一周行动的本地 HTML 报告。

执行原则

• 只读扫描，不删除或修改会话、缓存、项目文件、报告和 skills。
• 报告与中间数据保存在本地，不上传到外部分析服务。
• 按项目和共性问题归并，不输出聊天流水账。
• 面向普通使用者，不展示内部调试术语和低价值备注。
• 时间与 Token 使用本地记录估算；无法精确时说明口径，不编造。
• 正常使用由 skill 自动执行脚本，不要求用户操作命令行。

1. 扫描

默认复盘最近 7 天；用户指定时间范围时按用户要求。

优先运行仓库内脚本：

node scripts/scan_usage.mjs --workspace <workspace> --output /tmp/codex_review_scan.json

扫描范围：

• Codex 主会话、辅助线程、时间戳和 Token 事件。
• 工作区最近新增或修改的文档、代码、表格、网页、图片和其他产物。
• 最近的 skill 变更与同类自动化任务状态。
• 会话或目录损坏、权限不足、Token 缺失等异常。

不要把完整原始 Prompt、密钥、Token 或不必要的绝对路径写入扫描 JSON。辅助线程和明显的系统测试任务不计入主要使用时长。

2. 归并项目

读取 references/project-grouping.md，按证据强弱归并会话和产物。

必须满足：

• 开源默认规则不包含维护者个人项目名、行业词、组织名或本地路径。
• 同一个产物只归属一个项目。
• 优先使用自定义规则、明确工作目录、消息中的路径和产物目录。
• 证据不足时使用中性任务类型，不编造项目名称。
• 如果大部分内容都落进“其他任务”，先检查解析和归并，不直接交付正式报告。

3. 分析

每个主要项目至少分析：

• 做了什么、投入多久、形成哪些产物。
• 第一条请求是否说明最终交付物、输入材料、范围、约束、验收标准和验证方式。
• 后续是否反复补充“不要做什么”、修改方向或追加关键规则。
• 重复工作是否值得沉淀为模板、脚本、skill、自动化或项目规则。

建议必须来自本次扫描数据。不要固定输出某个职业、某类项目或维护者个人习惯的结论。

4. 生成报告

读取 references/report-design.md，使用现有模板生成报告：

node scripts/build_report.mjs --input /tmp/codex_review_scan.json --output <report.html>

默认自动打开浏览器。只有用户明确要求静默执行或只生成文件时才使用 --no-open。

报告阅读顺序：

1. 本周结论与总览。
2. 效率信号与 Token 大致消耗。
3. 任务分布和项目投入。
4. 项目复盘。
5. 跨项目 Prompt 诊断。
6. 本周协作方式与使用画像。
7. 去重后的可复制 Prompt。
8. 可复用机会。

颜色含义只放在右上角说明按钮里。数据诊断仅在存在异常时折叠展示。不要把自动化状态、附录或单独的颜色诊断做成正文板块。

5. 自动化任务

每次执行时检查是否已有同类周度复盘任务。

• 用户要求“每周、定期、自动、持续检查”且没有同类任务：使用 Codex 自动化工具创建，默认每周一 09:30。
• 已有同类任务：不重复创建，只说明现有状态。
• 用户只要求本次复盘：完成报告后，用一句话提示可以创建周度任务。

自动化任务也应在报告生成后打开页面。创建、查看或更新任务必须使用 Codex 自动化工具，不直接编辑自动化配置文件。

推荐任务提示词：

使用 $codex-review 复盘我最近 7 天的 Codex 使用情况，生成并打开本地 HTML 报告。
重点看主要项目、投入时间、产出文件、Token 大致消耗、低效步骤、Prompt 问题和下周行动。
已有同类自动化任务时不要重复创建。

6. 交付

对话中只返回：

• 一句话结论。
• 总时长、主要项目和 Token 大致消耗。
• 最值得调整的 1-3 个习惯。
• HTML 报告路径和自动化任务状态。

详细内容留在 HTML 中。报告未能自动打开时，要区分“文件已生成”和“浏览器打开失败”，并给出可直接处理的下一步。

遇到异常时读取 references/troubleshooting.md。