周期报告生成器

要解决的问题

周报和月报最耗时的不是写，而是收集。开发者要回忆本周改了哪些模块、哪些 commit 对应哪项工作、哪些事项根本没碰代码（比如评审、沟通、值班）。纯手工整理有三个痛点：

• 从 git log 里翻提交记录，遇到多仓库时更容易遗漏；
• 日历事件和代码提交分散在不同工具里，时间线对不上；
• 讨论过的关键决策没有记录载体，写报告时想不起来。

核心能力与工作步骤

这个技能把「收集—聚合—渲染」拆成固定流程，底层调用 report_generator.py，分五个阶段执行：

1. 参数确认：一次性提取报告类型（weekly / monthly）、时间范围、git 仓库路径（支持多仓库）、输出路径和日历来源；关键参数缺失时集中询问，不会中途反复打断。
2. 数据采集：依次跑三种模式——--mode git 读取 commit hash、作者、日期、message 和变更文件；--mode calendar 读取日历事件；--mode memory 从对话上下文中提取关键决策。
3. 跨源聚合：把三条时间线对齐。commit 与日历事件时间重合时标注关联；同一模块的多条 commit 合并为一条工作项；没有 git 覆盖但日历或记忆里有的记录，标记为「非代码工作」。
4. 模板渲染：按内置模板或 --template 指定的自定义模板渲染。
5. 写入文件：输出为 周报_YYYY-WXX.md 或 月报_YYYY-MM.md，默认落在 output/ 目录。

适用边界与注意点

先想清楚它不做什么：只处理本地文件和 git 数据，不接 Jira、Notion 等第三方系统；日历需要你提供文本或文件路径，没有自动同步能力。

实际使用中要注意：

• memory 依赖上下文：如果运行前没有相关讨论，memory 段会标注「暂无记录」，报告质量随之下降，建议在会话里先交代关键事项。
• 降级行为要知情：路径不是 git 仓库时跳过 git 采集；日历解析失败降级为「手动补充」；时间范围内零提交时生成空模板。报告依然会生成，但内容会偏空。
• 错误码用于定位：E1.1 表示所有路径都不是 git 仓库，E1.2 表示输出目录不可写，E2.1 表示区间内无提交，E2.2 表示日历解析失败。遇到报告内容异常时，先对照这些码排查。