技能介绍

工程师写周报时，常面临这样的困境：对着终端里的 git log 逐条翻提交，手动筛选哪些是昨天完成的功能、哪些是还在 WIP 的模块、哪些是修复了鉴权漏洞的关键变更，再整理成符合团队规范的周报。这个过程不仅耗时，还容易遗漏重要事项——比如把一个 breaking change 混在普通提交里，或者忘记标注临时方案的进展状态。## 从 Git 提交到结构化周报的核心能力这个技能要解决的正是「如何快速把零散的 Git 提交转化为结构化的周/日报」。它的核心逻辑分三步：首先按时间范围（日报取昨天到今天、周报取本周一到今天，也支持自定义日期）和作者、仓库维度筛选提交；接着根据分类指南把提交归入完成事项（如 feat: 登录页重构）、进行中事项（如带 WIP 标记的 report-export 模块）、重要事项（如安全修复、breaking change）；最后生成包含这三块内容的 Markdown 周报，还能附带结构化的 WeeklyReportArtifact 方便下游工具处理。## 工作流里的关键约束技能的工作流设计有几个工程师会在意的细节：取提交时单仓库超 50 条不会逐条罗列，而是按类别汇总，但保留 short_hash 方便追溯具体提交；「下周计划」和「风险阻塞」必须向用户确认——这类信息无法从 Git 日志推导，强制确认避免凭空生成；日报默认不含计划与风险板块，除非用户明确要求。## 适用边界需要注意它不适用于单条提交的代码评审，也不处理分支合并、推送等非提交类 Git 操作。如果用户的需求是总结多个仓库的跨项目进展，或是准备站会时的快速汇总，这个技能能发挥最大价值；但如果要做代码质量分析或项目进度的量化统计，它暂时帮不上忙。