dl-work-daily-report

工作日报

使用场景

当用户要求“生成日报”“根据今天提交写日报”“根据 Codex/Claude 记录写日报”“按项目/系统分组写日报”等内容时使用。

默认流程

1. 确认日报时间范围，默认使用当天 00:00:00 到 23:59:59；如果用户指定日期或范围，按用户指定。

2. 读取 git 提交记录，优先使用当前仓库：

rtk git log --since='YYYY-MM-DD 00:00:00' --until='YYYY-MM-DD 23:59:59' --pretty=format:'%h %ad %s' --date=format:'%H:%M'

3. 同时读取 Codex 和 Claude 聊天日志，补充当天实际处理过但未必形成提交的工作：

rg -n '"updated_at":"YYYY-MM-DD|"thread_name"' ~/.codex/session_index.jsonl
rg -n '"session_id"|"text"' ~/.codex/history.jsonl
find ~/.codex/sessions/YYYY/MM/DD -type f -name '*.jsonl' -print
rg -n 'YYYY-MM-DD|/path/to/project|sessionId' ~/.claude/history.jsonl
find ~/.claude/sessions -type f -name '*.json' -print

4. 对命中的 Codex 会话继续读取对应 ~/.codex/sessions/YYYY/MM/DD/*.jsonl；对命中的 Claude 记录先从 ~/.claude/history.jsonl 取 sessionId、project、时间和需求摘要，再读取对应 ~/.claude/sessions/*.json。重点看 cwd/project、分支、用户需求、assistant 最终回复、工具调用涉及的文件/命令，提炼真实工作结果。

5. 将 git 提交、Codex 聊天日志和 Claude 聊天日志合并去重，再按项目、系统或业务线归类。

6. 输出简短日报，不写技术细节堆叠，不写 commit hash，不暴露聊天日志路径、session_id、内部推理或隐私内容。

信息来源规则

• git 提交是最强证据，优先用于确认已经落地的代码、配置、文档变更。
• Codex、Claude 聊天日志用于补充排查、方案设计、接口分析、文档整理、临时验证等没有提交或提交信息过粗的工作。
• 两类来源描述同一件事时要合并成一条，不要重复写“提交修复”和“聊天排查”两条。
• 只有聊天记录但没有提交时，可以写成“排查/梳理/确认/设计/补充文档”等实际工作结果；不要伪造成已经上线或已提交。
• 如果聊天记录中只有闲聊、登录、简单命令、无明确产出的探索，不写入日报。
• 读取日志时优先筛选当前仓库 cwd/project 或相关项目路径；跨仓库工作要按项目单独归类。

分组规则

• 只输出当天 git 提交或 Codex、Claude 聊天日志实际涉及的项目、系统或业务线。
• 没有实际工作内容的项目不要输出，也不要写“今日暂无”“暂无明确提交”等占位项。
• 如果一天涉及多个仓库或项目，优先按项目名分组；同一项目内再按业务线合并表达。
• 常见分组包括但不限于：物业、工地、HR系统、财务系统、后台基础能力。
• 物业：物业系统、停车收费、停车同步、缴费、报修、住户、车辆、小程序、后台管理等 smart-tenement 主业务。
• 工地：工地、施工、项目现场、工程、设备、巡检、人员考勤、安全等相关内容。
• HR系统：员工、组织、考勤、招聘、薪酬、审批、人事档案等相关内容。
• 如果信息无法明确归类，优先使用项目名、模块名、目录名、分支名、commit 内容或聊天主题判断；仍无法判断时放到最接近的业务线。

输出格式

默认使用用户给定的格式：

物业:
  1: xxx
  2: xxx

工地:
  1: xxx
  2: xxx

如果当天只有一个项目或系统有内容，只输出该项目或系统，例如：

物业:
  1: xxx
  2: xxx

写法要求

• 每条尽量 15-35 个字，偏结果描述，不写过多过程。
• 每个项目、系统或业务线默认输出 1-5 条；内容少时 1 条即可，内容多时最多 5 条，优先保留用户能看懂的业务结果。
• 同类提交和同类聊天记录要合并，不要按 commit 或会话一条条罗列。
• 不要写“完成了”“进行了”太多次，句子要自然。
• 用户要求“简单点”时，每个分组 1-3 条即可。
• 如果用户指定条数，例如“生成 3 条日报”，总数优先满足指定条数。
• 如果用户指定只要某个分组，只输出该分组。
• 不要为了凑格式输出空项目或空系统。
• 不确定是否已落地时，用“排查”“梳理”“确认”“设计”这类谨慎措辞，避免写成已发布、已上线。