# Git Daily Commit Summary

> Use in any Git repository or multi-repository workspace when the user asks to summarize today's commits, generate a daily report / 日报, or turn git history into a readable work summary; inspect real commits, changed files, and key diffs before grouping results.

- Skill: `xfcycc/git-daily-commit-summary` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add xfcycc/git-daily-commit-summary`
- Raw SKILL.md: https://api.skillmd.com/api/skills/xfcycc/git-daily-commit-summary/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: xfcycc (https://skillmd.com/u/xfcycc)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/xfcycc/git-daily-commit-summary

---


# Git Daily Commit Summary

用于任意 Git 项目里“先读真实 commit，再整理成日报/工作记录”的通用流程。

## 触发场景

- 用户说“整理成日报”“汇总今天提交”“commit 汇总”“daily report”“work log”。
- 用户要求按项目、端、模块、平台、业务线或团队格式重组提交。
- 用户要求“读取提交代码进一步修正总结”。

## 输出目标

默认产出可直接转发的纯文本日报。除非用户要求 Markdown，否则不要用标题、表格或加粗。

基本原则：

- 不把 commit message 原样逐条贴出来。
- 不按“一条 commit = 一条日报”机械输出。
- 不输出无内容的空分组。
- 不把 merge、stash、WIP 临时提交混进正式日报正文。
- 后端、脚本或公共模块改动按实际影响面归入对应项目/模块/端；无法判断时明确说明不确定性。

## 工作流

### 1. 确认统计口径

先确认日期、作者和仓库范围：

```bash
date +%F
git config --global user.name
git config --global user.email
git rev-parse --show-toplevel
```

规则：

- 用户指定日期或时间范围时，以用户指定为准。
- 默认只汇总当前 git 用户的提交。
- 单仓项目只看当前仓库。
- 多仓工作区优先看本轮相关仓库、当前目录下包含 `.git` 的子仓库、用户点名的仓库。
- 如果用户说“所有项目提交”，再扩大到用户指定的根目录或当前工作区下的所有仓库。

### 2. 拉取提交记录

使用日期窗口和 author 过滤提交：

```bash
git -C <repo> log --since="<start>" --until="<end>" --author="<user.name>" --pretty=format:'%H%x09%ad%x09%s' --date=iso
git -C <repo> log --since="<start>" --until="<end>" --author="<user.email>" --pretty=format:'%H%x09%ad%x09%s' --date=iso
```

然后区分：

- 正式代码提交。
- merge 提交。
- stash/index/WIP 临时提交。

正式日报默认只使用正式代码提交。merge、stash、WIP 只在用户追问或要求完整清单时补充说明。

### 3. 读取真实改动

这是本 skill 最重要的规则：必须继续读取 changed files，必要时读取关键 diff。

```bash
git -C <repo> show --stat --oneline --name-only <commit>
git -C <repo> show --format=fuller --stat <commit>
git -C <repo> show -- <path>
```

不要只根据仓库名、提交标题或文件扩展名归类。公共服务、后端接口、脚本和配置可能影响多个端或多个模块。

### 4. 发现项目分组规则

优先按下面顺序确定日报分组：

1. 用户当次明确要求的格式。
2. 仓库内的 `AGENTS.md`、`.codex/daily-summary-rules.md`、`.codex/skills/*/SKILL.md` 或团队文档。
3. 路径、路由、包名、服务名、README、提交历史中稳定出现的项目/模块/平台。
4. 如果仍不确定，用“项目/模块/公共能力”这类中性分组，并在输出前说明假设。

常见分组维度：

- 产品或业务线。
- Web、移动端、小程序、服务端、CLI、文档。
- 页面、接口、服务、任务、配置、测试。
- 功能域，例如登录、支付、导出、通知、审核、搜索。

### 5. 合并表达

把同类改动合并成业务结果或工程结果：

```text
项目A：
  Web端：
    - 修复登录页验证码刷新后状态不同步的问题
    - 完成订单详情导出入口和异常提示调整

公共能力：
  服务端：
    - 补充导出任务的失败兜底和重复提交校验
```

表达要求：

- 先写用户能理解的结果，再补必要技术口径。
- 同一件事的多次修正合并成一条。
- 公共后端改动能明确影响某个端时，归入该端；不能明确时放入公共能力或服务端分组。
- 不编造未在 diff 中出现的范围、页面或能力。

### 6. 校验清单

输出前逐项自查：

- 是否读取了每个正式 commit 的 changed files 或关键 diff。
- 是否把 merge、stash、WIP 混进了正式日报。
- 是否错误地按仓库名代替真实影响面归类。
- 是否遗漏了公共服务对前端/移动端的实际影响。
- 是否包含空分组。
- 是否把技术实现写得过细，导致不像可转发日报。

## 最终输出

用户只要日报时，最终回复只保留日报正文。

如果存在不确定分组，先用一句话说明假设，再给日报。不要把排查过程、命令输出或 commit hash 混入正文，除非用户明确要求。