git-daily-note-updater

---
name: git-daily-note-updater
description: Generate or update structured Obsidian daily notes from git commit history with diff analysis. Triggers on: updating daily notes/work logs/diary from git commits, generating work reports from git history, filling in missing daily notes for past dates, summarizing today's work across repos. Key phrases: "更新日报", "写日报", "日报", "工作日志", "生成工作日志", "根据git提交写日报", "补日报", "daily note", "work log", "git daily". Do NOT trigger for: writing code, git operations (merge/rebase/conflict), meeting notes, generic reports without git context.
---

# Git 日报更新器

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

---

## 配置系统

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

| 优先级 | 位置 | 说明 |
|--------|------|------|
| 1 | 项目根目录 `.daily-note-config.yaml` | 项目级覆盖，适合特殊项目 |
| 2 | `~/.claude/daily-note-config.yaml` | 全局配置，一次配置到处使用 |

### 配置文件结构

```yaml
# 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`

### 配置合并规则

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

---

## 智能分类系统

### 分类优先级

| 优先级 | 类别 | 匹配方式 |
|--------|------|---------|
| 1 | 【用户自定义】 | 配置文件中定义的类别，按 patterns 关键词匹配 |
| 2 | 【能力升级】 | feat, enhance, add, new, implement |
| 3 | 【问题定位】 | fix, bug, resolve, repair, patch |
| 4 | 【结构变更】 | refactor, restructure, reorg, migrate |
| 5 | 【配置调整】 | config, setting, env, manager |
| 6 | 【文档优化】 | docs, doc, readme, comment |
| 7 | 【测试覆盖】 | test, spec, coverage |
| 8 | 【其他更新】 | 以上都不匹配时 |

### 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. 合并配置（项目级覆盖全局级）
```

| 参数 | 来源 | 默认值 |
|------|------|--------|
| `daily_note_path` | 配置文件 | - |
| `repos` | 配置文件 | 当前目录 |
| `date` | 用户指定 | 今天 (YYYY-MM-DD) |
| `date_end` | 用户指定 | 同 date（单天模式） |

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

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

```bash
# 单天模式
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 命令：

```bash
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 输出中。否则手动执行：

```bash
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 中提取：

| 信息 | 用途 |
|------|------|
| 修改文件路径 | 判断影响模块 |
| 增删行数 (+N/-M) | 量化改动规模 |
| Schema / 配置 / 提示词变更 | 识别关键改动 |
| 改动意图与效果 | 语义化描述 |

### 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`）：
- **已存在** → 在当天条目下合并新增内容，不重复创建日期标题
- **不存在** → 创建新的日期条目

#### 输出格式

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

模块标签规则：
- 单模块：`（模块名）`
- 跨模块：`（模块A → 模块B → 模块C）`，按改动链路排列

---

## 执行检查清单

**配置**:
- [ ] 配置文件存在（全局或项目级）或已创建
- [ ] 日报文件路径有效

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

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