# Weekly Report

> 生成开发周报，根据 git commit 历史归纳本周/上周的工作成果。当用户提到"周报"、"工作总结"、"本周工作"、"上周工作"、"weekly report"、"写周报"、"生成本周总结"时触发此技能，即使用户没有明确说"周报"但表达了回顾近期工作的意图也应触发。默认输出精简版（每条35~50字），用户要求时可输出详细版。

- Skill: `mi4646/weekly-report` (Agent Skill, multi-file: 2 files)
- Install (CLI): `npx skillmds@latest add mi4646/weekly-report`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mi4646/weekly-report/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: mi4646 (https://skillmd.com/u/mi4646)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mi4646/weekly-report

---


# 开发周报生成技能

根据 git commit 区间自动生成结构化的开发周报。

## 触发条件

当用户请求生成周报、工作总结、或回顾近期代码提交时使用此技能。

## 工作流程

### 第一步：确定 commit 区间

根据用户输入判断分析范围：

1. **用户提供了明确的 commit 区间**（如 `abc123..def456`）—— 直接使用该区间
2. **用户提供了时间范围**（如"上周"、"本周"）—— 根据时间计算对应的 commit 范围
3. **用户未指定**—— 默认获取**上周工作日**（上周一 00:00 到 上周五 23:59）的提交

计算上周工作日的方法：

```bash
# 获取上周一的日期（ISO格式 YYYY-MM-DD）
last_monday=$(date -d "last monday" +%Y-%m-%d)
# 如果今天是周一，"last monday"是昨天；否则是上一个周一
# 获取上周五的日期
last_friday=$(date -d "$last_monday +4 days" +%Y-%m-%d)

# 用 git log 获取时间范围内的提交
git log --after="${last_monday}T00:00:00" --before="${last_friday}T23:59:59" --oneline --no-merges
```

如果用户说的是"本周"，则用本周一到今天的范围。

### 第二步：获取 commit 详情

执行以下命令获取完整信息：

```bash
# 获取 commit 列表（排除 merge commit）
git log --oneline --no-merges <commit-range 或 时间范围>

# 获取每个 commit 的文件变更统计
git log --no-merges <range> --format="%H %s" | while read hash msg; do
  echo "=== $msg ==="
  git show $hash --stat --format=""
done
```

如果用户提供了 commit 区间（`A..B` 格式），使用该格式；如果使用时间范围，用 `--after` / `--before` 参数。

### 第三步：过滤与归纳

**过滤规则** —— 忽略以下类型的提交：
- Merge / merge branch 开头的
- 纯 chore / docs / style / test / build / ci 类型的（注意：如果 `docs:` 提交对应的是实际的代码/配置变更而非文档撰写，不应过滤）
- typo / README / 纯注释修改
- 自动生成内容

**归纳规则** —— 这是生成高质量周报的核心：
- 多个相似/相关的提交 → 合并为一个事项
- 多次修复同一问题 → 汇总描述
- 零碎提交 → 提炼为完整工作成果
- 关联的 feat + refactor + fix → 归纳为一个完整的成果条目

**表达要求**：
- 每条表示"一项已完成的工作"，禁止逐条复述 commit
- 使用"动词 + 结果"表达（实现了 / 优化了 / 修复了 / 重构了）
- 优先体现功能或业务价值，而不是细节改动
- 避免空泛描述（如：修改代码、调整逻辑）
- 如果能识别模块（前端 / 后端 / API / 性能 / 部署等），自然体现即可

### 第四步：输出周报

**模式选择**：
- **精简版（默认）**：每条 35~50 字，只保留"动词 + 结果 + 核心价值"，删掉括号注释、模块罗列、版本号等细节。
- **详细版**：仅当用户明确要求"详细 / 详细版 / 展开"时才输出，每条可 60~100 字，补充具体模块、改动点与成果体量。

**数量控制**：输出 3~6 条，必须合并重复内容，避免流水账。

**格式** —— 严格按以下格式输出，不要额外解释：

```
1. xxx
2. xxx
3. xxx
4. xxx
```

**精简版示例**（每条 35~50 字）：
```
1. 完成全库国际化清网，全部模块英文源化，locale 重建并补齐越语繁体翻译
2. 部署运维一键化改造，新增交互式安装卸载与清理脚本，升级持久化不丢数据
3. 消除命令注入面，全面 shell=False 化，加装安全响应头与 Redis 保护模式
4. 升级核心依赖至修复版本，运行组件同步升版并瘦身镜像
5. 品牌与语言按部署时区自动派生，VietGuard/appGuard 一键切换
```

## 注意事项

- 如果 commit 区间内没有有效提交，告知用户"该时间范围内没有找到有效的代码提交"
- 如果有效提交太少（不足3条），按实际数量输出即可，不必凑数
- 如果有效提交太多，优先选取业务价值最高、工作量最大的条目进行归纳
- 默认输出精简版（每条 35~50 字）；仅当用户明确要求"详细版"时再展开细节
- 输出语言与用户输入语言保持一致
version: v1.1.0