# Daily Work Summary

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

- Skill: `nangongwentian-fe/daily-work-summary` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add nangongwentian-fe/daily-work-summary`
- Raw SKILL.md: https://api.skillmd.com/api/skills/nangongwentian-fe/daily-work-summary/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: nangongwentian-fe (https://skillmd.com/u/nangongwentian-fe)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/nangongwentian-fe/daily-work-summary

---


# 每日工作内容总结

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

## 确认输入

1. 获取项目路径。未提供时使用当前工作目录。
2. 获取单日、多个离散日期或连续日期区间。日期缺失时必须询问，不猜测日期。
3. 默认只统计提交作者为用户本人的提交，绝不把其他作者的提交纳入总结。
4. 确认本人的 Git 作者身份：
   - 用户明确提供作者邮箱、姓名或多个历史身份时，以用户提供的身份为准。
   - 否则在仓库内读取当前生效的 `git config --get user.email`，以该邮箱作为本人身份；同时读取 `user.name` 仅用于核对，不用姓名替代已取得的邮箱。
   - 使用仓库 `.mailmap` 归一化提交作者身份，以覆盖其中已声明的历史邮箱或姓名别名。
   - 无法取得邮箱，或可见历史表明当前邮箱不足以唯一识别本人时，必须询问用户本人提交所使用的邮箱或身份列表；不得改为统计全部作者，也不得仅凭相似姓名猜测。
5. 使用用户指定的时区；未指定时使用运行环境的本地时区。
6. 用 `git rev-parse --show-toplevel` 确认仓库根目录。路径不存在或不是 Git 仓库时，直接说明问题。

## 提取证据

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

先读取提交元数据：

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

- 读取元数据后，按已确认的本人身份精确过滤作者字段：邮箱比较忽略大小写但必须完整相等；用户只明确提供姓名时，姓名必须完整相等。不要用模糊匹配或未经转义的 `--author` 正则代替精确过滤。
- 有多个已确认的本人身份时按“任一身份匹配”处理；未匹配的提交一律排除。
- 日期区间应覆盖用户指定的全部日期，再按提交时间归入每一天。
- 使用 `%cI` 和提交时间归入工作日期；使用 `%aN`、`%aE` 判断提交作者，不用 committer 身份替代 author 身份。
- 不自动执行 `git fetch`、`git pull` 或切换分支。

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

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

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

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

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

## 归并工作事项

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

## 输出格式

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

单日格式：

```markdown
### 7 月 16 日

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

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

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

## 异常处理

- 路径无效：指出无法访问的项目路径。
- 非 Git 目录：指出目标不是 Git 仓库。
- 日期无效或边界不明确：要求用户提供可解析的日期。
- 本人身份无法可靠确认：要求用户提供 commit 中使用的作者邮箱或身份列表，不继续生成可能混入他人提交的总结。
- 作者过滤无结果：说明本人在指定日期没有可见提交，不改为统计其他作者。
- 大量提交：仍按完成事项聚合；只有用户明确要求时才输出 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 的工作内容。`

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