| name | write-daily-report |
| description | 将用户提供的工作记录，或按用户批准的工作目录从当日 Codex、Claude Code 与 Pi Agent 会话中采集的事实，整理成可直接提交的高质量日报、日结或 standup update。用户要求写、润色或审阅日报，汇总今日工作或 AI 会话，提炼目标、成果、风险、阻塞或明日优先事项时都应使用；适用于不同组织、岗位、项目目录和输出语言，不预设任何个人路径。 |
高质量日报
把原始工作信息整理成让读者能快速判断“目标是什么、做了什么、做到什么程度、有什么风险、下一步是什么”的日报。
输入来源
- 用户直接提供流水账、聊天记录、会议纪要或零散事项时，直接进入“工作流程”。
- 用户要求从今天的本地 AI 会话自动生成日报时，先完整读取
references/session-collection.md，按其中规则确定工作范围，再发现、过滤、读取和去重 Codex、Claude Code 与 Pi Agent 会话。
- 用户同时提供材料并要求扫描会话时，合并两个来源；同一成果只保留一份，以状态最新、证据最完整的来源为准。
先确定汇报契约
- 优先遵循用户提供的公司模板、字段、语言、日期、时区、字数和读者偏好。
- 用户未指定语言时，沿用其请求所用语言；未指定日期和时区时，使用当前本地日期与时区。
- 根据用户明确的岗位、项目和工作目录判断工作相关性，不预设某种职业的内容一定属于或不属于工作。
- 只有自动采集本地会话时才需要工作目录。按“用户本次指定 →
DAILY_REPORT_WORK_ROOTS → 当前明确的工作仓库”确定范围；无法安全确定时，在读取会话正文前只问一个简短问题。
- 某个客户端或会话源不可用时，继续处理其他可用来源并如实说明覆盖范围，不把缺少某一工具视为失败。
工作流程
- 自动采集时，先按
references/session-collection.md 完成工作目录白名单和相关性判定；不要把“今天使用过 AI”等同于“今天的工作”。
- 提取日期、项目或任务、目标、动作、结果、数据或交付物、协作对象、问题、原因、处理动作、待办、截止时间和优先级。
- 合并同一目标下的碎片动作；删除与汇报范围无关的个人事务、重复内容和不影响判断的过程噪声。
- 区分事实、判断和计划。不要虚构数字、完成状态、原因、责任人、截止时间或业务价值。
- 将重点事项改写为“目标/背景 → 关键动作 → 结果/进度 → 影响或问题 → 下一步”的短链路。
- 按
references/quality-rubric.md 自检并改写，但不要向用户展示分数或内部推理。
- 输出可直接粘贴到日报系统的最终正文。
信息处理规则
- 优先保留可验证结果：完成量、完成率、交付物、里程碑、结论、问题闭环、影响范围、反馈和链接名称。
- 用户只提供动作而未提供结果时，如实写“已完成某动作，当前待某结果/反馈”，不要擅自写“已完成”或“效果良好”。
- 用户提供数量时保留准确数字；未提供数字时使用准确的定性表达，不自行估算。
- 把“开会、沟通、跟进、处理”等空泛动词改为具体对象和产出，例如“与产品确认退款规则，统一 3 项口径，待研发评估排期”。
- 同一任务的多条时间线合并为一条成果链；不同目标分条呈现。
- 同一工作在不同客户端、主任务、委派任务或续接任务中重复出现时，按最终交付物合并，不重复累计测试数、覆盖率或缺陷数。
- 明确区分
已完成、进行中、待确认/待反馈、受阻，不要混淆状态。
- 暗点同时说明影响、已采取动作或下一步；避免甩锅、情绪化表达和只报问题不报方案。
- 亮点由事实支撑，优先体现超预期、提效、降本、风险前置、跨团队推进或方法沉淀；无事实支撑时不强行设置。
- 不重复填写姓名、汇报对象和汇报时间等系统字段，除非用户明确要求。
信息不足时
- 只要能形成真实、有用的日报，就直接产出，不要先追问。
- 不影响事实的缺失信息直接省略，不使用空洞占位语。
- 关键事实缺失且会造成误导时，在对应位置使用
【待补充：具体问题】；全文最多保留 3 个待补充项。
- 只有在完全无法判断任务、结果或明日安排时，才提出一个合并后的简短问题。
默认输出格式
用户没有提供固定格式时，输出以下两个区块，并把标题翻译成用户所用语言。不要附加前言、评分、写作说明或原文复述。自动采集且有来源不可用时，可以在正文末尾增加一行简短的“采集范围”说明，避免让用户误以为已经完整扫描。
今日工作总结/目标及达成/亮点与暗点
1. 【项目/目标】
- 进展与结果：……
- 亮点/暗点：……（仅在确有价值时保留）
2. 【项目/目标】
- 进展与结果：……
明日要事
1. 【P0】……；预期产出：……；完成标准/时间：……
2. 【P1】……；预期产出：……；完成标准/时间：……
根据内容自然调整：
- 每个一级事项对应一个目标或交付物，不按时间顺序机械罗列。
- 简单事项用一句话写完；只有复杂事项才拆分子项。
- 没有真实亮点或暗点时，删除“亮点/暗点”行。
- 用户未提供优先级、时间或完成标准时，不编造；省略对应字段。
- 明日计划必须是可执行动作，尽量包含对象、产出和完成标准，避免只写“继续跟进”。
- 默认简洁、专业、克制；中文通常控制在 300–600 字，其他语言保持相当的信息密度，事项很多时可适度增加。
- 默认不展示被排除的会话；用户要求核对采集范围时，再列出“纳入/排除及原因”。
最终检查
提交输出前逐项确认：
- 是否覆盖所有重要工作、结果、阻塞和明日事项？
- 是否能看出目标、实际进度和完成状态？
- 是否至少在重点事项中呈现可验证结果或明确产出？
- 是否把问题写成“问题—影响—措施/下一步”的闭环？
- 明日要事是否具体、可执行、可验收？
- 是否删除重复、空话、流水账、夸张表述和未经用户提供的事实？
- 自动采集时，是否只读取批准工作目录内的会话和经 Git 验证来源属于这些目录的 Codex worktree？
- 是否检查了当前环境中可用的 Codex、Claude Code 与 Pi Agent 记录，并说明不可用来源？
- 是否排除当前日报任务，并对跨会话续接、委派任务和累计指标完成去重？
