日报成稿

把当天的会议记录、聊天记录或零散事项，整理成只属于用户本人、可核对、可直接发送的日报草稿。任务不是泛泛总结，而是只写有依据的事实，确保完成状态不被夸大。

输入

用户可能提供（任意组合）：

1. 会议转写稿、会议笔记、聊天记录，或用户口述的零散事项；
2. 用户姓名或在会议中的称呼（用于识别哪些是"我的事"）；
3. 日报日期；
4. 用户对事项状态、结果、截止时间的补充。

工作流程

第一步：收集今日事实

• 只提取与用户本人有关、且在输入中有依据的事项；与用户无关的他人协作信息不进日报。
• 为每个事项判定状态：已完成（有明确结果）/ 进行中（在做、待做、状态不清）/ 明日计划（尚未开始、明确安排在明天）。
• 保留业务名词、关键数字、交付物名称；发现转写错误、角色不明或前后矛盾，明确标记并向用户核对，不静默修正。

第二步：事实核对

• 检查每个事项的完成状态、结果证据、关键数字是否明确。
• 缺少关键信息时，一次只问用户一个最影响结果的问题。
• 没有依据的事项不写；用户没有确认的信息写"待确认"，不得自行补全。
• 当天确实没有已完成事项时，✅ 区写"无"，不得为了好看把进行中的事提前到已完成。

第三步：生成日报

严格使用以下格式，不增加、不删除栏目：

X月X日工作总结
✅：
1、
🚶：
1、
明日计划：
1、

状态规则：

• "✅"只用于输入中明确已经完成并有结果的事项，写清结果：交付了什么、数据是多少、发给了谁。
• 未完成、进行中或状态不清的事项统一用"🚶"，写清当前进展与下一步。
• 明日计划只放尚未开始、明确安排在明天的动作；不得把明日计划写进 ✅。
• 同一事项当天有多次进展时，只写最新状态，不重复罗列。
• 没有内容的状态区保留栏目并写"无"。

第四步：核对后交付

• 所有输出都必须先让用户核对；未收到"确认"前只能生成草稿，不得代替用户发送到群、文档或其他渠道。
• 提醒文字必须放在可复制正文之外，原文为： "请逐条核对完成状态、结果数据和明日计划，确认无误后再发送。"
• 用户纠正事实后，基于新事实重新生成，并说明修改了哪一条。

表达要求

• 一条一事，动词开头，简洁具体，保留业务名词与关键数字。
• 不夸大、不编造、不改变原意；不写"持续推进""有序开展"这类没有信息量的空话。
• 事项较多时按重要程度排序，不按聊天或会议中的出现顺序机械堆砌。

与其他 Skill 的关系

• 输入是会议转写稿，且同时需要会议纪要或周报素材卡时，使用「会记成报」；本 Skill 只负责个人日报。
• 周五需要把本周多份已确认日报按事项合并去重成周报时，使用「会记成报」的合并周报流程。

示例

参见 examples.md，了解输入、单次追问、V1/纠错/V2 的完整示例。