write-daily-report

name	write-daily-report
description	将用户提供的工作记录，或按用户批准的工作目录从当日 Codex、Claude Code 与 Pi Agent 会话中采集的事实，整理成可直接提交的高质量日报、日结或 standup update。用户要求写、润色或审阅日报，汇总今日工作或 AI 会话，提炼目标、成果、风险、阻塞或明日优先事项时都应使用；适用于不同组织、岗位、项目目录和输出语言，不预设任何个人路径。

高质量日报

把原始工作信息整理成让读者能快速判断“目标是什么、做了什么、做到什么程度、有什么风险、下一步是什么”的日报。

输入来源

• 用户直接提供流水账、聊天记录、会议纪要或零散事项时，直接进入“工作流程”。
• 用户要求从今天的本地 AI 会话自动生成日报时，先完整读取 references/session-collection.md，按其中规则确定工作范围，再发现、过滤、读取和去重 Codex、Claude Code 与 Pi Agent 会话。
• 用户同时提供材料并要求扫描会话时，合并两个来源；同一成果只保留一份，以状态最新、证据最完整的来源为准。

先确定汇报契约

1. 优先遵循用户提供的公司模板、字段、语言、日期、时区、字数和读者偏好。
2. 用户未指定语言时，沿用其请求所用语言；未指定日期和时区时，使用当前本地日期与时区。
3. 根据用户明确的岗位、项目和工作目录判断工作相关性，不预设某种职业的内容一定属于或不属于工作。
4. 只有自动采集本地会话时才需要工作目录。按“用户本次指定 → DAILY_REPORT_WORK_ROOTS → 当前明确的工作仓库”确定范围；无法安全确定时，在读取会话正文前只问一个简短问题。
5. 某个客户端或会话源不可用时，继续处理其他可用来源并如实说明覆盖范围，不把缺少某一工具视为失败。

工作流程

1. 自动采集时，先按 references/session-collection.md 完成工作目录白名单和相关性判定；不要把“今天使用过 AI”等同于“今天的工作”。
2. 提取日期、项目或任务、目标、动作、结果、数据或交付物、协作对象、问题、原因、处理动作、待办、截止时间和优先级。
3. 合并同一目标下的碎片动作；删除与汇报范围无关的个人事务、重复内容和不影响判断的过程噪声。
4. 区分事实、判断和计划。不要虚构数字、完成状态、原因、责任人、截止时间或业务价值。
5. 将重点事项改写为“目标/背景 → 关键动作 → 结果/进度 → 影响或问题 → 下一步”的短链路。
6. 按 references/quality-rubric.md 自检并改写，但不要向用户展示分数或内部推理。
7. 输出可直接粘贴到日报系统的最终正文。

信息处理规则

• 优先保留可验证结果：完成量、完成率、交付物、里程碑、结论、问题闭环、影响范围、反馈和链接名称。
• 用户只提供动作而未提供结果时，如实写“已完成某动作，当前待某结果/反馈”，不要擅自写“已完成”或“效果良好”。
• 用户提供数量时保留准确数字；未提供数字时使用准确的定性表达，不自行估算。
• 把“开会、沟通、跟进、处理”等空泛动词改为具体对象和产出，例如“与产品确认退款规则，统一 3 项口径，待研发评估排期”。
• 同一任务的多条时间线合并为一条成果链；不同目标分条呈现。
• 同一工作在不同客户端、主任务、委派任务或续接任务中重复出现时，按最终交付物合并，不重复累计测试数、覆盖率或缺陷数。
• 明确区分 已完成、进行中、待确认/待反馈、受阻，不要混淆状态。
• 暗点同时说明影响、已采取动作或下一步；避免甩锅、情绪化表达和只报问题不报方案。
• 亮点由事实支撑，优先体现超预期、提效、降本、风险前置、跨团队推进或方法沉淀；无事实支撑时不强行设置。
• 不重复填写姓名、汇报对象和汇报时间等系统字段，除非用户明确要求。

信息不足时

• 只要能形成真实、有用的日报，就直接产出，不要先追问。
• 不影响事实的缺失信息直接省略，不使用空洞占位语。
• 关键事实缺失且会造成误导时，在对应位置使用 【待补充：具体问题】；全文最多保留 3 个待补充项。
• 只有在完全无法判断任务、结果或明日安排时，才提出一个合并后的简短问题。

默认输出格式

用户没有提供固定格式时，输出以下两个区块，并把标题翻译成用户所用语言。不要附加前言、评分、写作说明或原文复述。自动采集且有来源不可用时，可以在正文末尾增加一行简短的“采集范围”说明，避免让用户误以为已经完整扫描。

今日工作总结/目标及达成/亮点与暗点
1. 【项目/目标】
   - 进展与结果：……
   - 亮点/暗点：……（仅在确有价值时保留）

2. 【项目/目标】
   - 进展与结果：……

明日要事
1. 【P0】……；预期产出：……；完成标准/时间：……
2. 【P1】……；预期产出：……；完成标准/时间：……

根据内容自然调整：

• 每个一级事项对应一个目标或交付物，不按时间顺序机械罗列。
• 简单事项用一句话写完；只有复杂事项才拆分子项。
• 没有真实亮点或暗点时，删除“亮点/暗点”行。
• 用户未提供优先级、时间或完成标准时，不编造；省略对应字段。
• 明日计划必须是可执行动作，尽量包含对象、产出和完成标准，避免只写“继续跟进”。
• 默认简洁、专业、克制；中文通常控制在 300–600 字，其他语言保持相当的信息密度，事项很多时可适度增加。
• 默认不展示被排除的会话；用户要求核对采集范围时，再列出“纳入/排除及原因”。

最终检查

提交输出前逐项确认：

• 是否覆盖所有重要工作、结果、阻塞和明日事项？
• 是否能看出目标、实际进度和完成状态？
• 是否至少在重点事项中呈现可验证结果或明确产出？
• 是否把问题写成“问题—影响—措施/下一步”的闭环？
• 明日要事是否具体、可执行、可验收？
• 是否删除重复、空话、流水账、夸张表述和未经用户提供的事实？
• 自动采集时，是否只读取批准工作目录内的会话和经 Git 验证来源属于这些目录的 Codex worktree？
• 是否检查了当前环境中可用的 Codex、Claude Code 与 Pi Agent 记录，并说明不可用来源？
• 是否排除当前日报任务，并对跨会话续接、委派任务和累计指标完成去重？