Git 日报更新器

自动从 git 提交历史（包含 diff 分析）生成结构化的 Obsidian 日报内容。

配置系统

配置文件位置（优先级从高到低）

配置文件结构

# Daily Note Updater Configuration
# Generated by git-daily-note-updater skill

# 日报文件路径（必填）
daily_note_path: /path/to/your/Daily Note.md

# 工作仓库列表（可选，不配置则使用当前目录）
repos:
  - /path/to/repo1
  - /path/to/repo2

# 自定义类别（可选，不配置则使用默认类别）
categories:
  - name: 【安全加固】
    patterns: ["security", "auth", "permission"]
  - name: 【性能优化】
    patterns: ["perf", "optimize", "speed"]

# 启用 LLM 语义分类（可选，默认 false）
# 开启后，当关键词匹配不到合适类别时，会将 diff 内容交给 LLM 判断分类
enable_smart_classify: false

首次使用

如果没有找到任何配置文件：

1. 提示用户：检测到首次使用 git-daily-note-updater。请提供日报文件路径来创建全局配置：
2. 将配置写入 ~/.claude/daily-note-config.yaml
3. 如果用户希望项目特定配置，则写入项目根目录的 .daily-note-config.yaml

配置合并规则

项目级配置覆盖全局配置的同名字段。未配置的字段从全局配置继承。

智能分类系统

分类优先级

LLM 语义分类（当 enable_smart_classify: true 时）

当关键词匹配落入【其他更新】时，启用语义分类作为回退：

1. 关键词匹配 — 先用上表的快速路径匹配（零开销）
2. 语义回退 — 如果关键词匹配失败（落入【其他更新】），将 commit subject + diff 摘要交给 LLM 判断
3. LLM 判断依据：
   • diff 中新增了功能代码 → 【能力升级】
   • diff 中修复了错误处理/边界条件 → 【问题定位】
   • diff 中重新组织了代码结构 → 【结构变更】
   • diff 中调整了配置/参数 → 【配置调整】
   • diff 中仅有注释/文档 → 【文档优化】
   • diff 中仅增加了测试用例 → 【测试覆盖】
4. LLM 也可以创造新类别 — 如果 diff 内容明显属于一个尚未定义的类别（如"依赖升级"、"CI/CD 调整"），LLM 可以用 【新类别名】 标注，并在日报末尾附注说明

语义分类的目标是让日报分类更贴近实际工作内容，而非机械匹配关键词。

写作风格：语义化优先

日报是给人读的工作日志，不是 code review 记录。

• 写意图，不写实现 — "数据格式从嵌套对象简化为自然语言" 而非 "SomeSchema.field_a 从 dict 改为 str"
• 写效果，不写手段 — "绑定时能匹配到正确选项" 而非 "新增 _resolve_match() 遍历查找"
• 标注模块归属 — 每条改动用 （模块A → 模块B） 标注影响范围，从 commit scope 和 diff 文件路径推断
• 保留关键实体名作为锚点 — 配置项名、schema 名可保留，但不要堆砌整个句子

工作流程

Step 1: 加载配置

1. 检查项目根目录 .daily-note-config.yaml
2. 检查 ~/.claude/daily-note-config.yaml
3. 如果都不存在 → 首次使用引导，创建全局配置
4. 合并配置（项目级覆盖全局级）

Step 2: 获取提交历史（优先使用脚本）

如果 scripts/git-stats.sh 可访问，优先使用它获取结构化数据：

# 单天模式
bash <skill-path>/scripts/git-stats.sh <repo_path> <date>

# 多天模式（含 date_end）
bash <skill-path>/scripts/git-stats.sh <repo_path> <date> <date_end>

脚本输出 JSON，包含每个提交的 hash、subject、body、stat、insertions、deletions、files_changed。

如果脚本不可用，回退到手动 git 命令：

git log --since="<date> 00:00:00" --until="<date> 23:59:59" --pretty=format:"%h %s"
git reflog --since="<date> 00:00:00" | head -50

对每个仓库执行后，合并所有提交进行分析。

Step 3: 获取每个提交的完整信息

如果使用了 git-stats.sh，此步骤的数据已包含在 JSON 输出中。否则手动执行：

git log -1 --format="%s%n%b" <hash>      # 提交消息
git show <hash> --stat --format=""        # 文件变更统计
git show <hash> --format=""               # 完整 diff

diff 是主要信息源，commit message 常遗漏细节。跳过 diff = 日报不完整。

Step 4: Diff 分析

从 diff 中提取：

Step 5: 分类 + 智能合并

5a. 分类

按分类优先级匹配。如果 enable_smart_classify: true，关键词匹配失败时启用 LLM 语义分类回退。

5b. 同功能多 commit 智能合并

识别属于同一功能/任务的多个 commit，合并为一条日报条目：

合并信号（满足任一即可合并）：

• commit scope 相同（如 feat(auth): ... 和 fix(auth): ...）
• diff 涉及相同的核心文件
• commit message 语义关联（如 "add X" 后跟 "fix X edge case"）

合并规则：

• 取最高优先级的类别作为合并后的类别（如 feat + fix → 【能力升级】）
• 行数累加（+N1+N2 / -M1-M2）
• 语义描述合并为一条，涵盖整体意图
• 详细说明保留每个 commit 的关键信息

不合并：完全无关的 commit 保持独立。

Step 6: 生成日报内容

多日期支持

用户可以指定日期范围（如 "补过去三天的日报"），此时 date_end > date：

• 每天生成独立的日期条目
• 按日期从新到旧排列

增量更新检测

生成前先检查日报文件中是否已有当天条目（匹配 ### YYYY.MM.DD 或 ### YYYY-MM-DD）：

• 已存在 → 在当天条目下合并新增内容，不重复创建日期标题
• 不存在 → 创建新的日期条目

输出格式

### YYYY.MM.DD
- [项目名称]
	- {模块}
		- 【类别】
			- [x] （模块A → 模块B）语义化描述（+N/-M 行）
				- 详细说明

模块标签规则：

• 单模块：（模块名）
• 跨模块：（模块A → 模块B → 模块C），按改动链路排列

执行检查清单

配置:

• 配置文件存在（全局或项目级）或已创建
• 日报文件路径有效

提交分析:

• 获取了当天所有提交（reflog 交叉验证）
• 每个提交都获取了完整 diff
• 量化了改动规模（+N/-M 行）

输出质量:

• 语义化描述（意图/效果，非函数名/字段名）
• 每条改动标注了模块归属
• 格式与现有日报一致
• 已检查当天是否有重复条目
• 相关 commit 已智能合并
• 分类准确（必要时使用了语义分类）