work-report-writer

name	work-report-writer
description	从零散的工作记录和 git log 生成结构化的周报或月报，支持数据导向、叙事型和 OKR 对齐等多种汇报风格。当用户提到周报、月报、工作总结、weekly report、monthly report、sprint summary、迭代总结、写周报、写月报、OKR 进展汇报，或需要把散乱的工作记录整理成结构化报告时触发。
license	MIT
metadata	{"version":"0.1.0","tabtin":{"category":"collab","displayName":"周报月报生成"}}

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

第三步：整理与分类

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

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

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

输出要求

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