daily-work-summary

name	daily-work-summary
description	根据指定 Git 仓库和日期，从 commit、提交正文、文件变更及必要的 diff 中提炼每日工作内容。用于用户要求按项目和日期生成日报、每日工作总结、根据 Git commit 总结工作，或要求用 1、2、3 编号列出某天或某段日期完成事项的场景。

每日工作内容总结

以 Git 历史为唯一事实来源，把相关提交合并成完成事项，输出简洁的中文编号清单。

确认输入

1. 获取项目路径。未提供时使用当前工作目录。
2. 获取单日、多个离散日期或连续日期区间。日期缺失时必须询问，不猜测日期。
3. 仅在用户明确指定时按作者过滤；默认统计项目内全部提交。
4. 使用用户指定的时区；未指定时使用运行环境的本地时区。
5. 用 git rev-parse --show-toplevel 确认仓库根目录。路径不存在或不是 Git 仓库时，直接说明问题。

提取证据

对每个目标日期建立本地时间的半开区间：当日 00:00:00 到次日 00:00:00。使用提交时间筛选，结束边界不得包含在当前日期内。

先读取提交元数据：

git log --all --since="<开始时间>" --until="<结束时间>" --date=iso-local --pretty=format:"%H`t%cI`t%an`t%ae`t%s%n%b"

• 用户指定作者时追加 --author="<作者>"。
• 日期区间应覆盖用户指定的全部日期，再按提交时间归入每一天。
• 使用 %cI 和提交时间，不用作者时间推断工作日期。
• 不自动执行 git fetch、git pull 或切换分支。

对筛出的每个提交检查改动范围：

git show --stat --summary --name-status <commit>

提交标题和正文不能说明实际工作时，再读取必要 diff：

git show --format= --unified=2 <commit> -- <相关文件>

优先检查实现代码、测试、迁移、部署配置和直接相关文档。不要仅凭 commit 标题总结，也不要无差别展开所有大型 diff。

归并工作事项

1. 按实际目标合并提交，不逐条复述 commit。
2. 将同一功能的实现、后续修复、测试和文档合并为一个事项。
3. 将独立的功能、性能优化、缺陷修复、部署改造和文档交付拆成不同事项。
4. 描述完成的行为和结果；只有在有 diff 证据时才写具体技术变化。
5. 避免重复：后续提交仅完善前一提交时，不新增一条工作事项。
6. 不把工作区未提交文件、当前代码状态、记忆内容或其他日期的提交写入总结。
7. 合并提交与普通提交表达同一工作时，只保留一次。

输出格式

默认只输出工作内容，不输出取证过程、命令、表格、commit 数量或总结说明。

单日格式：

### 7 月 16 日

1. 完成事项……
2. 完成事项……

多日或日期区间按日期分别使用同样结构，每天重新编号。事项使用适合日报的完成式表述，保留必要的项目术语，但控制技术细节。

• 默认不显示 commit hash。
• 用户要求可追溯时，在对应事项末尾附相关短 hash。
• 当日没有符合条件的提交时，输出：该日期没有已提交工作内容。
• 仓库是浅克隆或历史明显不完整时，补充：仅基于当前可见 Git 历史。
• 不把“没有提交”改写成“没有工作”。

异常处理

• 路径无效：指出无法访问的项目路径。
• 非 Git 目录：指出目标不是 Git 仓库。
• 日期无效或边界不明确：要求用户提供可解析的日期。
• 作者过滤无结果：说明该作者在指定日期没有可见提交，不改为统计其他作者。
• 大量提交：仍按完成事项聚合；只有用户明确要求时才输出 commit 级明细。

示例

单日

用户：使用 $daily-work-summary 总结 E:\Code\Project\Demo 2026-07-16 的工作内容。

输出：只列出 7 月 16 日的编号工作事项。

多个日期

用户：使用 $daily-work-summary 总结当前项目 7 月 16 日和 7 月 17 日的工作内容。

输出：按两个日期分组，每天独立编号。

日期区间

用户：使用 $daily-work-summary 总结 D:\work\app 2026-07-01 至 2026-07-05 的每日工作。

输出：覆盖区间内每个日期，包括没有提交的日期。

无提交日期

用户：使用 $daily-work-summary 总结当前项目 2026-01-01 的工作内容。

输出：该日期没有已提交工作内容。