Work report writer

Skill serejaris/kimi-skills/skills/work-report-writer

从零散的工作记录和 git log 生成结构化的周报或月报，支持数据导向、叙事型和 OKR 对齐等多种汇报风格。当用户提到周报、月报、工作总结、weekly report、monthly report、sprint summary、迭代总结、写周报、写月报、OKR 进展汇报，或需要把散乱的工作记录整理成结构化报告时触发。From its SKILL.md

Install

npx -y skills add serejaris/kimi-skills --skill work-report-writer

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its file declares

Copied from the file, not written here

The file declares its own license as MIT. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.

SKILL.md

6.3 KB, ~2.2k tokens by cl100k_base, as published. Nobody here has run it

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

What ships with it: 1 file

1.1 KB alongside SKILL.md

LICENSE1.1 KB