mi4646 开发周报生成技能
根据 git commit 区间自动生成结构化的开发周报。
触发条件
当用户请求生成周报、工作总结、或回顾近期代码提交时使用此技能。
工作流程
第一步：确定 commit 区间
根据用户输入判断分析范围：
- 用户提供了明确的 commit 区间（如
abc123..def456）—— 直接使用该区间 - 用户提供了时间范围（如"上周"、"本周"）—— 根据时间计算对应的 commit 范围
- 用户未指定—— 默认获取上周工作日（上周一 00:00 到 上周五 23:59）的提交
计算上周工作日的方法：
# 获取上周一的日期（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 详情
执行以下命令获取完整信息：
# 获取 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