用途
work-summary 用于根据一个或多个仓库的 git 提交历史，生成已完成工作的摘要报告。资料中列出的典型用途包括：为站会或状态报告生成工作摘要、为工时表或计费创建摘要、回顾某时间段内完成的工作、准备回顾会议或评审，以及跨多个仓库追踪工作。
主要能力
技能以作者名、起止时间、一个或多个仓库路径为参数，执行以下处理：
- 解析参数；若未提供参数，则向用户询问作者名、开始日期/时间、结束日期/时间以及仓库路径。
- 对每个仓库收集 git 数据：使用
git log按作者和时间范围获取提交（格式%h|%s），并使用带--shortstat的命令获取统计信息。 - 将相关提交分组为逻辑任务（同一功能的多条提交、相关缺陷修复、单次重构等），并借助提交信息前缀（feat、fix、refactor、chore、docs、test）辅助归类；同时按规模将任务分为大、中、小三档。
- 计算总计：跨所有仓库的提交总数、新增行数、删除行数、不同任务总数。
- 生成一份自包含 HTML 报告，默认保存到 /tmp/work-summary.html，并向用户报告该路径。
使用方式
参数格式为：
<author> <start_datetime> <end_datetime> <repo1> [repo2] [repo3]...
示例：
/work-summary Alice "2026-01-08 09:00" "2026-01-09 18:00" frontend backend/work-summary "Alice Smith" "2026-01-07 09:00" "2026-01-07 18:00" .
若不提供参数，技能会以交互方式提示：作者名（如 "Alice" 或 "Alice Smith"）、开始时间与结束时间（格式 YYYY-MM-DD HH:MM，本地时区）、仓库路径（以空格分隔，可为相对路径或绝对路径，使用 "." 表示当前目录）。
收集数据时使用的命令为：
- 获取提交：
cd <repo> && git log --author="<author>" --since="<start>" --until="<end>" --pretty=format:"%h|%s" - 获取统计：
cd <repo> && git log --author="<author>" --since="<start>" --until="<end>" --shortstat --pretty=format:"%h"
资料说明：默认假定为用户本地时区，除非另行指定；需处理相对路径（必要时转换为绝对路径）；若仓库不存在，则警告并跳过。
报告结构包含标题（起止时间）、作者、汇总条（提交数、新增行数、删除行数、任务数）以及按大、中、小任务分组的列表。保存文件后需向用户报告路径。
任务分组与规模判断
技能将相关提交组合为逻辑任务，例如同一功能跨多条提交、相关缺陷修复、单次重构。规模判断参考如下：
- 大任务：新包或主要模块、包含多个组件的重大新功能、重大架构变更、跨多个文件的复杂功能。示例："Add authentication system"、"Implement payment processing"。
- 中任务：对现有模块的功能新增、较大规模重构、中等复杂度的多文件改动、新增 API 端点。示例："Add user profile editing"、"Refactor API error handling"。
- 小任务：缺陷修复、UI 调整与样式、单文件改动、清理与格式化、文档更新、小幅重构。示例："Fix typo"、"Update button color"、"Add JSDoc"。
适用场景
适用于需要把一段时间内的 git 提交转化为可读工作摘要的场合，例如站会汇报、工时与计费、阶段回顾、评审准备，以及跨仓库的工作追踪。资料示例中提到了单仓库、多仓库（frontend、backend、docs）以及交互式无参数三种使用情形。
限制与注意事项
- 该技能在提交信息清晰、具有描述性时效果最佳。
- 对于非常大的时间范围，建议按天或按周汇总。
- 若未找到任何提交，需明确说明，并核实作者名与日期范围。
- 需优雅处理错误，包括缺失仓库、无效日期和 git 错误。
- 默认使用本地时区，但若用户指定时区则应遵循。
- 仓库名仅在分析多个仓库时显示。
- 任务描述应清晰并聚焦业务价值；行数需根据 git 统计准确计数。
- 上述 HTML 模板与样式为资料给出的固定结构，用于生成报告。