# Daily Report > 根据一个或多个 Git 仓库的提交记录生成工作日报与周功能总结，按作者过滤后汇总工作价值、变更范围与结果，并可按阶段标记关联 GitLab Work Item。当用户要求生成、总结或补充工作日报、周报、周功能总结、上周做了什么时使用。 - Skill: `forsakesoul/daily-report` (Agent Skill, multi-file: 7 files) - Install (CLI): `npx skillmds@latest add forsakesoul/daily-report` - Raw SKILL.md: https://api.skillmd.com/api/skills/forsakesoul/daily-report/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Docs & Writing - Author: forsakesoul (https://skillmd.com/u/forsakesoul) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/forsakesoul/daily-report --- # Daily Report Skill 基于 Git 提交记录生成工作日报。可选地把每个分支/提交关联的 GitLab Work Item 按阶段（需求梳理 / 技术设计 / 开发中 / 测试中 / 验收中 / 待上线 / 已上线 / 已合入主干）标记出来。 ## 按模式读取使用已有配置；仅缺少配置或需调整来源/输出时读取 [配置说明](references/configuration.md)。`` 是当前已加载 SKILL.md 的父目录，配置也在该目录中，不依赖调用时 cwd。 - 日报：读取 [日报流程与模板](references/daily.md)。 - 周报/周功能总结：读取 [周报流程与模板](references/weekly.md)，不把日报的逐分支表机械重复一遍。 - 用户只要求口头总结时直接回复；已有明确文件输出要求时才写到指定位置。GitLab Work Item 默认只做来源关联，写 tracker 需独立授权。 ## 使用方式用户说「生成日报」「总结日报」「今日日报」「更新下今天的日报」等触发词即生成日报。用户说「生成周报」「周功能总结」「上周做了什么」「把上周做的总结下」等触发词即生成周功能总结（按上方指针读取周报参考）。如需指定日期，可说「生成 6 月 15 日的日报」。如需指定其他仓库，可补充仓库路径。生成前先冻结目标日期和时区。指定日期时优先运行随 Skill 提供的采集脚本： ```bash python3 "/scripts/collect_commits.py" \ --date YYYY-MM-DD --timezone Asia/Shanghai -a '' ``` 脚本输出的精确半开区间 `[当天 00:00, 次日 00:00)` 是提交归属的事实边界；不得把区间外提交写进当天。周末归并只改变日报展示归属，原始提交仍按各自自然日分别采集并保留边界。 ## 保持 config.json 同步 `config.json` 是**本地真实配置**：它在 `.gitignore` 里、不会被提交，所以**真实仓库路径、分支名、Work Item 标题等内部信息只写在这里**。受版本控制的 `SKILL.md` 与 `references/*` **只写泛化示例**，不出现真实项目名、内网地址、真实分支名。 **每次生成日报后都要回填 `config.json`**，让它始终反映当前实际环境： 1. 本次实际采集的仓库路径若与 `repos` 不一致（新增 / 改名 / 移除），先更新 `repos`，再同步 `workItems.gitlab.project_paths`。 2. 本次识别出的**集成 / 重放类分支**记进 `dedup.integration_branches`，**同远端多 checkout 的目录组**记进 `dedup.same_remote_paths`，供下次生成时直接引用（见 [日报流程与模板](references/daily.md)）。 3. 本次新出现的 Work Item 归属，按下面的优先级回填，**ID 与标题必须来自实际查询或提交正文，绝不靠猜**： - 先补「提交级」的 `workItems.reference_map`：把提交正文里出现过的引用 token（如 `#12`、`group/project-a#12`）解析成实际所属项目与编号，带上 `title` / `state` / `confidence` / `evidence`。 - 再补「分支级」的 `workItems.branch_work_items`。每条要写 `work_items`（一个分支对应多张票据时用列表）与 `stage`；**`project` 字段跨项目时必填**，缺省时才按「拥有该分支的本地目录」经 `gitlab.project_paths` 推导（见注意事项里的跨项目条目）。 - 核实后确认**不挂 Work Item** 的分支记进 `workItems.unmapped.branches`，避免下次重复排查或硬凑编号。 - 仍无法确认的，放进 `_pending.branch_work_items` 并把 `candidate_id` 留 `null`，同时在日报的「需要留意」里列为待确认——不要写看起来合理的假条目。 4. 回填后校验 JSON 合法性：`python3 -c "import json;json.load(open('config.json'))"`。 ## 注意事项 - 日报总结应由 AI 根据提交内容自行总结，不要让用户自己写。 - 只纳入 config.author.patterns 匹配到的作者提交（个人日报视角）；若需团队视角，临时放宽 author 或说明。 - 分支名取 remote 分支的简称（去掉 `origin/`）；worktree 分支也按实际分支名标注。 - 如果某个仓库无提交，仍然列出并标注「0 个提交」。 - “0 个提交”只表示该日期、时区、作者和仓库集合下没有匹配的 Git commit。输出前必须确认已覆盖全部配置仓库且未使用 `--no-all`；未提交改动、设计、QA、验收和沟通另列为“非提交活动”，不得据此写成“当天没有工作”。 - 代码统计只统计文件变更，不含 merge commit。 - 采集务必用 `git log --all`，否则会漏掉 worktree / 未合入 feature 分支的提交。 - **日期口径必须用 author date（`%aI`）**：`git log --since/--until` 只按 committer date 预筛，而 rebase / cherry-pick 重放会刷新 committer date。采集脚本已改用 `%aI` 归属，并把预筛窗口前后各放宽 `SLACK_DAYS`（7 天）后在 Python 侧按 author date 精确裁剪。**不要把 `%aI` 改回 `%cI`**，也不要把 git 原始 `--since/--until` 结果直接当归属日期，否则重放当天会把旧工作重复计入（实测一个窗口内 58 个唯一提交有 14 笔 committer date ≠ author date）。 - **跨分支同改动要去重**：`--all` 会让同一改动落在集成分支上的 cherry-pick 副本各算一次。用 `git patch-id --stable` 比对：patch-id 相同只计一份，并在报告的去重说明里逐组列出「保留 / 去重」的 hash 对；**同名同目的但 patch-id 不同（改动量有差）要各计一笔**，不能当重复删掉。 - **代表侧（保留哪一侧）选择规则，按优先级**：① 保留**不在集成/重放分支上**的一侧——集成分支是 cherry-pick 的目的地，取它会把工作记到集成分支的语境里；② 两侧都不在集成分支时，保留**已合入主干**的那侧；③ 仍并列时保留 **author date 靠前**的。抽象原则是「保留实现分支、去重重放分支」，**具体对比的是分支名而不是时间先后**（实测曾因先按时间排序而误选集成侧）。 - 若集成/重放分支名不固定，把该类分支列进 `config.json` 的 `dedup.integration_branches`（见「保持 config.json 同步」一节），生成报告时按该列表判定代表侧，**不要硬编码分支名**。 - 自动检测周目录结构（第一周 / 第二周 / 第三周 …），日报写入对应周子目录。**若目标周目录不存在，直接创建**（路径形如 `/YYYY//第N周`，月份**无前导零**、周次用中文序数，如 `2026/9/第三周`）；写文件前先确认目录存在。 - **同一远端多个 checkout 要去重**：两个本地目录可能指向**同一个远端仓库**（常见于「主仓 + 独立验证仓」、或仓库改名后留下旧 checkout），`--all` 会让同一批提交各算一次；采集后按「唯一远端」只计一份，并在报告中注明。**若配置的仓库不在同一个父目录下**（例如一部分在 `~/Code/公司/`、另一部分在 `~/Code/个人/`），必须显式把路径都传进采集脚本，否则会静默跳过。 - **写长日报要分段落盘**：目标在**云同步目录**（如 iCloud Drive、Obsidian 库等由系统同步守护的路径）下且内容较长（约 5KB 以上）时，`Write` 工具或单条 `cat <> "$F" <<'MDEOF' … MDEOF` 每次追加 3~5KB。 - **更省事的等价做法（推荐用于含大量反引号/`$` 的 Markdown）**：先用 `Write` 把待追加片段写到 `/tmp//tail.md`（临时目录不受该审批拦截），再 `cat /tmp//tail.md >> "$F"`。这样完全绕开 heredoc 的引号与变量转义问题（日报正文里 `` ` `` 和 `$` 极多，heredoc 容易踩坑）。用 `before=$(wc -l < "$F"); …; after=$(wc -l < "$F")` 前后比对行数确认真的追加上了。 - **中途修改已写章节**：`Edit` 工具对同一份文件可直接使用，不受上面的「写长内容」限制——只有首次大批量落盘才需要分段。 - **落盘后必须回读校验**：确认采集清单里每个 commit hash 都出现在文件内（缺失即漏笔），并用正则统计各章节的 `- **\`hash\`` 条目数，看是否与该节标题声明的笔数、以及总数一致。 - **Work Item 关联**：阶段判定是本地启发式（分支名关键字 + 合入状态 + `branch_work_items` 映射），不是 GitLab 真实状态；未检测到 ID 引用的分支归入「未分类」或靠映射补全。连 GitLab 后（配置 token）可升级为查真实阶段。 - **Work Item 引用可能跨项目，先定项目再定编号**：提交正文里的引用**不等于本仓项目的票据**。实测同一批工作里，代码仓在 `group/project-a`，而提交正文引用的是 `group/project-b` 的票据（账号/登录类需求挂在另一个仓）和 `group/feedback-tickets` 的 QA 反馈票据（该反馈项目**本机没有 checkout**）。因此： - 解析顺序：① 正文自带全路径（如 `group/project-b#12`）或 `Refs: //-/work_items/` 尾注 → 直接采信；② 裸 `#NN` → 必须按正文描述与该编号的标题**逐字比对**后再归属；③ 只有主题相符、标题对不上的，标为待确认，不写进映射。 - **裸编号会跨项目重号**：同一个 `#9` 在三个相关项目里各有不同含义，`#15`、`#33` 之类也重号。**默认把 `#NN` 落到本仓项目是错的**，归属必须显式写明 `project`。查编号时不要只查一个项目就下结论，至少要覆盖本仓项目 + 已知可能承载该主题的相邻项目。 - 提交正文里还有大量**不指向 Work Item** 的 `#NN`：MR IID（性能对照表里成串出现）、十六进制色值（`#0507` 之类）、代码/样式引用。进映射前先判断它到底是不是票据号。 - 一个分支可以对应**多张票据**（QA 反馈批次常见，如一个分支同时修 `#11`/`#12`/`#13`），此时用列表而不是硬塞一张；一张票据也可能横跨多个项目与多个分支（父需求 + 各侧实现 + 验证），要在 `note` 里写清拆分关系，避免后续报告把同一件事拆成互不相关的几笔。 - **周末提交归类（周与日报边界）**：周六、周日的提交**不生成独立的当日日报**，统一归入**下一个周一**的日报（即「周末提交 → 下周一日报」）。周报统计区间按**周一至周五工作日**——周末（上周六、日）的提交不计入上周周报，而归入本周一所在的周（及该周一日报）。例：8/22（周六）、8/23（周日）的提交记入 0824（周一）日报，不计入 0817–0823 周报。生成周报时若用 `git log --since=周一首日 --until=周日+1` 整周采集，需手动剔除周末两天的提交，或将周末单独归入下周一。 --- ## 采集完成条件记录实际成功/失败/跳过仓库与精确日期区间。采集器非零或 incomplete 表示覆盖不全，合计只代表成功仓库；可继续产出明确标注缺口的部分报告，不能写成完整日报或零工作。零提交、未提交改动、QA/设计/沟通分别取证。