ClawLite Retro — 工程回顾#

当用户输入 /retro 时，运行此 skill。

参数#

• /retro — 默认：最近 7 天
• /retro 24h — 最近 24 小时
• /retro 14d — 最近 14 天
• /retro 30d — 最近 30 天

解析参数确定时间窗口。如果没有给出参数，默认为 7 天。

午夜对齐窗口： 对于 d（天）单位，从本地午夜计算绝对开始日期。例如，如果今天是 2026-03-21 且窗口是 7 天：开始日期是 2026-03-14。使用 --since="2026-03-14T00:00:00" 进行 git log 查询。

---

Step 1：收集原始数据#

首先，获取 origin 并识别当前用户：

bash

git fetch origin <default> --quiet
git config user.name
git config user.email

git config user.name 返回的名称是\\"你"\\ — 读取这个 retro 的人。所有其他作者是队友。

并行运行所有这些 git 命令：

bash

# 1. 窗口内所有提交（时间戳、主题、hash、作者、文件变化、行数变化）
git log origin/<default> --since="<window>" --format="%H|%aN|%ae|%ai|%s" --shortstat

# 2. 每次提交的测试 vs 总 LOC 细分（带作者）
git log origin/<default> --since="<window>" --format="COMMIT:%H|%aN" --numstat

# 3. 提交时间戳（用于会话检测和每小时分布）
git log origin/<default> --since="<window>" --format="%at|%aN|%ai|%s" | sort -n

# 4. 最常更改的文件（热点分析）
git log origin/<default> --since="<window>" --format="" --name-only | grep -v '^$' | sort | uniq -c | sort -rn

# 5. 每位作者的提交数量
git shortlog origin/<default> --since="<window>" -sn --no-merges

# 6. 测试文件数量
find . -name '*.test.*' -o -name '*.spec.*' 2>/dev/null | grep -v node_modules | wc -l

# 7. TODOS.md 积压
cat TODOS.md 2>/dev/null || true

---

Step 2：计算指标#

以摘要表形式计算和呈现这些指标：

指标值提交到 mainN贡献者N合并 PRN总插入行数N总删除行数N净增 LOCN测试 LOC（插入）N测试 LOC 比例N%版本范围vX.Y.Z → vX.Y.Z活跃天数N检测到的会话N平均 LOC/会话小时N

然后在下面立即显示 每位作者排行榜：

text

贡献者            提交数   +/-          主要区域
你 (garry)           32   +2400/-300   browse/
alice                12   +800/-150    app/services/
bob                   3   +120/-40     tests/

按提交数降序排序。当前用户（来自 git config user.name）总是排第一，标记为"你 (名称)"。

积压健康（如果 TODOS.md 存在）：

• 总开放 TODOs（排除 ## Completed 章节中的项目）
• P0/P1 计数（关键/紧急项目）
• 此期间完成的项目

---

Step 3：提交时间分布#

以小条形图显示本地时间的每小时提交直方图：

text

小时  提交数  ████████████████
 00:    4      ████
 07:    5      █████
...

识别并标注：

• 高峰时间
• 死区
• 模式是双峰（早晨/晚上）还是连续的
• 深夜编码集群（晚上 10 点后）

---

Step 4：工作会话检测#

使用连续提交之间的 45 分钟间隔 阈值检测会话。

分类会话：

• 深度会话（50+ 分钟）
• 中等会话（20-50 分钟）
• 微型会话（<20 分钟，通常是单次提交的快速修复）

计算：

• 总活跃编码时间（会话持续时间总和）
• 平均会话长度
• 每活跃小时的 LOC

---

Step 5：提交类型细分#

按常规提交前缀分类（feat/fix/refactor/test/chore/docs）。显示为百分比条：

text

feat:     20  (40%)  ████████████████████
fix:      27  (54%)  ███████████████████████████
refactor:  2  ( 4%)  ██

如果 fix 比例超过 50% — 标记为"快速发货，快速修复"模式，可能表明审查缺口。

---

Step 6：热点分析#

显示 top 10 最常更改的文件。标记：

• 更改 5+ 次的文件（流失热点）
• 热点列表中的测试文件 vs 生产文件
• VERSION/CHANGELOG 频率（版本纪律指标）

---

Step 7：本周发布#

专注度分数： 计算触及最常更改的顶级目录（例如 app/services/）的提交百分比。更高分数 = 更深入的专注工作。更低分数 = 分散的上下文切换。报告为："专注度分数：62%（app/services/）"

本周最大发布： 自动识别窗口中单个最高 LOC 的 PR。突出显示：

• PR 编号和标题
• LOC 变化
• 为什么重要（从提交消息和改动文件推断）

---

Step 8：团队成员分析#

对于每位贡献者（以你（当前用户）开始，然后是队友）：

你#

text

📊 你的本周回顾
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
提交数:    N    [commit type breakdown]
代码变化:  +X/-Y  (净 Z LOC)
测试覆盖:  N% 的提交有测试变化
专注区域:  主要在 [top directory]
会话:      N 次（其中 D 次深度会话）

本周亮点:
• [基于实际提交的具体内容]
• [这周值得注意的内容]

值得关注:
• [具体的、建设性的反馈，基于数据]

每位队友#

text

👤 [姓名]
━━━━━━━━━━━━━
提交数:    N
代码变化:  +X/-Y
专注区域:  [directory]

表扬:
• [基于他们做的具体内容 — 引用真实提交/文件]

成长机会:
• [具体的、建设性的内容，基于数据，不是泛泛而谈]

反表扬规则（反垃圾 AI）：

• 好的："你在 auth/ 重构了 UserSessionManager — 这是真正的架构改进，不只是移动代码。"
• 坏的："你展示了强大的工程技能。"
• 好的："修复了 3 个单独的错误，但都在 checkout/ — 那个区域的 bug 密度值得深入研究。"
• 坏的："你解决了问题，显示了你解决问题能力。"

成长机会必须有数据： 如果你找不到来自实际提交的建设性内容，写"数据太少，无法给出有意义的建议" — 不要编造反馈。

---

Step 9：TODOS.md 积压审查#

如果 TODOS.md 存在：

1. 本周完成的项目： 交叉引用 diff 与 TODOS.md。哪些项目有证据表明已完成？
2. 添加的新 TODOs： 检查 diff 中的 TODO、 FIXME、 HACK 注释，与 TODOS.md 中已知项目交叉引用。
3. P0/P1 更新： 任何关键项目需要基于本周工作重新优先排序？

---

Step 10：本周总结 + 下周焦点#

一段总结 — 将这一切联系在一起。本周发生了什么？什么变得更好了？什么仍然是挑战？

下周建议焦点（1-3 项）：

• 基于数据，不是凭空想象
• 具体，可操作
• 按影响排序

---

输出格式#

以此顺序呈现：

1. 📈 指标摘要表
2. 👥 贡献者排行榜
3. ⏰ 时间分布直方图
4. 🔥 热点分析
5. 🚀 本周最大发布
6. 👤 团队成员分析（你先，然后队友）
7. 📋 积压审查（如果适用）
8. 📝 本周总结 + 下周焦点

---

完成状态#

• DONE — 回顾完成，覆盖所有贡献者
• DONE_WITH_CONCERNS — 完成但有值得注意的问题（例如 fix 比例高，热点集中）
• BLOCKED — 无法访问 git 历史或在指定窗口中没有提交