Work Report Writer

---
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 仓库，自动执行以下命令获取提交记录：

```bash
# 先获取当前 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 天（月报） |
| 输出语言 | 中文 / 英文 | 中文 |
| 汇报对象 | 直属领导 / 团队 / 跨部门 | 直属领导 |

### 第三步：整理与分类

将收集到的所有信息按以下维度归类：

1. **已完成事项** — 本周期内完成交付的工作
2. **进行中事项** — 已开始但未完成的工作，附进度百分比估算
3. **问题与风险** — 遇到的阻塞、延期、依赖等
4. **下期计划** — 下一周期的重点工作
5. **关键数据** — 相关的量化指标（如有）

对于 git 提交记录，按功能模块或工作事项聚合，而非逐条罗列。将相关的多个 commit 合并描述为一个工作事项。

### 第四步：按风格生成报告

根据用户选择的风格，使用对应的模板生成报告。

---

## 风格模板

### 风格一：数据导向

适合需要量化呈现工作成果的场景，强调数字、完成率、对比。

```markdown
# [周报/月报] 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天 |
```

### 风格二：叙事型

适合向非技术背景的领导汇报，或需要传达工作背景和价值的场景。

```markdown
# [周报/月报] YYYY-MM-DD ~ YYYY-MM-DD

## 本期重点

用 2-3 句话概括本周期最重要的成果和进展，突出业务价值和影响。

## 工作进展

### [工作主题 1]

**背景**：为什么做这件事。
**本期进展**：做了什么、达成了什么效果。
**下一步**：接下来的计划。

### [工作主题 2]

（同上结构）

## 需要关注的问题

用平实的语言描述遇到的问题、对项目的影响，以及希望获得的支持。

## 下期重点

按优先级列出下周期 3-5 项重点工作。
```

### 风格三：OKR 对齐

适合 OKR 驱动的团队，将工作成果映射到目标和关键结果上。

```markdown
# [周报/月报] 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. **量化优先**：尽可能用数字说话（完成数量、进度百分比、指标变化）
3. **区分事实与计划**：已完成的用过去时，进行中的标注进度，计划中的标注预期时间
4. **突出价值**：每项工作尽量关联业务价值或项目目标，而非仅描述动作
5. **风险前置**：有阻塞或风险时优先提及，不要埋在细节中
6. **语言简洁**：每个事项描述控制在 1-2 句话，避免冗余

## 输出要求

- 输出格式为 Markdown
- 报告直接输出到对话中，用户可自行复制
- 如果用户要求保存到文件，写入用户指定的路径
- 时间范围在报告标题中明确标注