name: work-report-writer description: “从零散的工作记录和 git log 生成结构化的周报或月报，支持数据导向、叙事型和 OKR 对齐等多种汇报风格。当用户提到周报、月报、工作总结、weekly report、monthly report、sprint summary、迭代总结、写周报、写月报、OKR 进展汇报，或需要把散乱的工作记录整理成结构化报告时触发。” license: MIT
weekly-report-generator
从零散工作记录 + git 提交历史，生成结构化的周报或月报。支持数据导向 / 叙事型 / OKR 对齐三种风格，适配不同汇报场景。
使用流程
当用户要求生成周报或月报时，按以下步骤执行：
第一步：收集信息
需要收集两类信息：
1. 工作记录（用户提供）
向用户询问以下内容（缺失项可跳过）：
- 本周期完成的主要工作事项
- 进行中尚未完成的事项
- 遇到的问题或阻塞
- 下周期计划
- 关键数据或指标（如有）
用户可以用任何形式提供：散乱的笔记、聊天记录摘要、待办清单截图、口头描述均可。
2. Git 提交记录（自动获取）
如果用户的工作目录是一个 git 仓库，自动执行以下命令获取提交记录：
# 先获取当前 git 用户名
GIT_USER=$(git config user.name)
# 周报：获取最近 7 天、当前用户的提交
git log --since="7 days ago" --author="$GIT_USER" --pretty=format:"%h %s (%ai)" --no-merges
# 月报：获取最近 30 天、当前用户的提交
git log --since="30 days ago" --author="$GIT_USER" --pretty=format:"%h %s (%ai)" --no-merges
如果用户指定了具体的时间范围或作者，替换对应参数。如果当前目录不是 git 仓库或用户明确表示不需要 git 记录，跳过此步。
第二步：确认报告参数
向用户确认以下参数（如用户已在初始请求中明确，可跳过确认）：
| 参数 | 选项 | 默认值 |
|---|---|---|
| 报告类型 | 周报 / 月报 | 周报 |
| 报告风格 | 数据导向 / 叙事型 / OKR 对齐 | 数据导向 |
| 时间范围 | 自定义日期 | 最近 7 天（周报）或 30 天（月报） |
| 输出语言 | 中文 / 英文 | 中文 |
| 汇报对象 | 直属领导 / 团队 / 跨部门 | 直属领导 |
第三步：整理与分类
将收集到的所有信息按以下维度归类：
- 已完成事项 — 本周期内完成交付的工作
- 进行中事项 — 已开始但未完成的工作，附进度百分比估算
- 问题与风险 — 遇到的阻塞、延期、依赖等
- 下期计划 — 下一周期的重点工作
- 关键数据 — 相关的量化指标（如有）
对于 git 提交记录，按功能模块或工作事项聚合，而非逐条罗列。将相关的多个 commit 合并描述为一个工作事项。
第四步：按风格生成报告
根据用户选择的风格，使用对应的模板生成报告。
风格模板
风格一：数据导向
适合需要量化呈现工作成果的场景，强调数字、完成率、对比。
# [周报/月报] YYYY-MM-DD ~ YYYY-MM-DD
## 本期概览
- 完成事项：X 项 | 进行中：Y 项 | 延期：Z 项
- 代码提交：N 次 | 涉及模块：模块A、模块B
- 关键指标变化：[指标名] 从 A 提升至 B（+C%）
## 已完成
| # | 事项 | 分类 | 产出 |
|---|---|---|---|
| 1 | 事项描述 | 开发/设计/协调 | 具体产出物 |
| 2 | ... | ... | ... |
## 进行中
| # | 事项 | 进度 | 预计完成 | 阻塞 |
|---|---|---|---|---|
| 1 | 事项描述 | 70% | MM-DD | 无 / 描述阻塞 |
## 问题与风险
- **[问题1]**：描述 → 影响 → 当前应对方案
- **[问题2]**：...
## 下期计划
| # | 事项 | 优先级 | 预计工时 |
|---|---|---|---|
| 1 | 计划描述 | P0/P1/P2 | X天 |
风格二：叙事型
适合向非技术背景的领导汇报，或需要传达工作背景和价值的场景。
# [周报/月报] YYYY-MM-DD ~ YYYY-MM-DD
## 本期重点
用 2-3 句话概括本周期最重要的成果和进展，突出业务价值和影响。
## 工作进展
### [工作主题 1]
**背景**：为什么做这件事。
**本期进展**：做了什么、达成了什么效果。
**下一步**：接下来的计划。
### [工作主题 2]
（同上结构）
## 需要关注的问题
用平实的语言描述遇到的问题、对项目的影响，以及希望获得的支持。
## 下期重点
按优先级列出下周期 3-5 项重点工作。
风格三：OKR 对齐
适合 OKR 驱动的团队，将工作成果映射到目标和关键结果上。
# [周报/月报] YYYY-MM-DD ~ YYYY-MM-DD
## OKR 进展总览
| Objective | 本期进展 | 整体完成度 |
|---|---|---|
| O1: 目标描述 | 简要进展 | X% |
| O2: 目标描述 | 简要进展 | Y% |
## 详细进展
### O1: [目标描述]
**KR1: [关键结果描述]** — 当前进度 X%
- 本期完成：具体工作事项
- 下期计划：接下来要做的
**KR2: [关键结果描述]** — 当前进度 Y%
- 本期完成：...
- 遇到的问题：...
### O2: [目标描述]
（同上结构）
## 未对齐 OKR 的工作
本周期处理的但不直接对应 OKR 的工作（如临时需求、支持性工作等）。
- 事项 1：描述
- 事项 2：描述
## 风险与依赖
- **[风险1]**：影响的 OKR → 应对方案
- **[依赖1]**：依赖方 → 当前状态
## 下期 OKR 聚焦
列出下周期将重点推进的 KR 及预期目标。
生成规范
无论使用哪种风格，生成的报告都应遵循以下规范：
- 去碎片化：将多个相关的小事项合并为一个工作主题，避免流水账式罗列
- 量化优先：尽可能用数字说话（完成数量、进度百分比、指标变化）
- 区分事实与计划：已完成的用过去时，进行中的标注进度，计划中的标注预期时间
- 突出价值：每项工作尽量关联业务价值或项目目标，而非仅描述动作
- 风险前置：有阻塞或风险时优先提及，不要埋在细节中
- 语言简洁：每个事项描述控制在 1-2 句话，避免冗余
输出要求
- 输出格式为 Markdown
- 报告直接输出到对话中，用户可自行复制
- 如果用户要求保存到文件，写入用户指定的路径
- 时间范围在报告标题中明确标注