/sdlc-retro — 周度工程复盘
生成全面的工程复盘报告，分析提交历史、工作模式和代码质量指标。
参数
/sdlc-retro— 默认：最近7天/sdlc-retro 24h— 最近24小时/sdlc-retro 14d— 最近14天/sdlc-retro 30d— 最近30天/sdlc-retro compare— 比较当前周期与上一周期/sdlc-retro compare 14d— 使用指定窗口比较
指令
解析参数确定时间窗口。默认7天。使用 --since="N days ago" 进行 git log 查询。
所有时间使用本地时区报告。
参数验证: 如果参数不匹配数字后跟 d、h、w，或 compare 关键词，显示用法并停止：
用法: /sdlc-retro [窗口]
/sdlc-retro — 最近7天（默认）
/sdlc-retro 24h — 最近24小时
/sdlc-retro 14d — 最近14天
/sdlc-retro 30d — 最近30天
/sdlc-retro compare — 比较本周期与上一周期
/sdlc-retro compare 14d — 使用指定窗口比较
Step 1: 收集原始数据
首先，获取 origin 并识别当前用户：
git fetch origin <default-branch> --quiet
# 识别谁在运行复盘
git config user.name
git config user.email
git config user.name 返回的名字是 "你" —— 正在阅读这个复盘的人。所有其他作者是队友。
并行运行所有这些 git 命令（它们是独立的）：
# 1. 窗口内所有提交：时间戳、主题、哈希、作者、文件变更、插入、删除
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. 从提交消息中提取 PR 编号
git log origin/<default> --since="<window>" --format="%s" | grep -oE '#[0-9]+' | sed 's/^#//' | sort -n | uniq
# 6. 每个作者的文件热点（谁触碰了什么）
git log origin/<default> --since="<window>" --format="AUTHOR:%aN" --name-only
# 7. 每个作者的提交计数（快速摘要）
git shortlog origin/<default> --since="<window>" -sn --no-merges
# 8. TODOS.md 待办（如果可用）
cat TODOS.md 2>/dev/null || true
# 9. 测试文件计数
find . -name '*.test.*' -o -name '*.spec.*' -o -name '*_test.*' -o -name '*_spec.*' 2>/dev/null | grep -v node_modules | wc -l
# 10. 窗口内的回归测试提交
git log origin/<default> --since="<window>" --oneline --grep="test:" --grep="fix:"
# 11. 窗口内变更的测试文件
git log origin/<default> --since="<window>" --format="" --name-only | grep -E '\.(test|spec)\.' | sort -u | wc -l
Step 2: 计算指标
计算并在摘要表中展示这些指标：
| 指标 | 值 | |------|-----| | 提交到主分支 | N | | 贡献者 | N | | PR 合并数 | N | | 总插入行 | N | | 总删除行 | N | | 净增 LOC | N | | 测试 LOC（插入） | N | | 测试 LOC 比例 | N% | | 活跃天数 | N | | 检测到的会话 | N | | 平均 LOC/会话小时 | N | | 测试健康度 | N 总测试 · M 本期新增 · K 回归测试 |
然后立即展示 每作者排行榜：
贡献者 提交数 +/- 主要领域
你 (张三) 32 +2400/-300 browse/
李四 12 +800/-150 app/services/
王五 3 +120/-40 tests/
按提交数降序排列。当前用户始终排在第一位，标记为"你 (名字)"。
待办健康度（如果 TODOS.md 存在）: 读取 TODOS.md，计算：
- 总开放 TODO（排除
## Completed部分的项目） - P0/P1 计数（关键/紧急项目）
- P2 计数（重要项目）
- 本期完成的项目
- 本期新增的项目
Step 3: 提交时间分布
展示小时直方图：
小时 提交数 ████████████████
00: 4 ████
07: 5 █████
...
识别并指出：
- 高峰时段
- 空闲时段
- 模式是否双峰（上午/晚上）或连续
- 深夜编码集群（晚上10点后）
Step 4: 工作会话检测
使用 45分钟间隔 阈值检测连续提交之间的会话。 对每个会话报告：
- 开始/结束时间
- 提交数量
- 持续时间（分钟）
分类会话：
- 深度会话（50+ 分钟）
- 中等会话（20-50 分钟）
- 微型会话（<20 分钟，通常是单次提交）
计算：
- 总活跃编码时间（会话持续时间之和）
- 平均会话长度
- 每小时活跃时间的 LOC
Step 5: 提交类型分解
按约定式提交前缀分类。 显示为百分比条：
feat: 20 (40%) ████████████████████
fix: 27 (54%) ███████████████████████████
refactor: 2 ( 4%) ██
如果 fix 比例超过 50%，标记为"快速发布、快速修复"模式，可能表示审查缺口。
Step 6: 热点分析
展示前10个最常变更的文件。 标记：
- 变更5次以上的文件（流失热点）
- 热点列表中的测试文件 vs 生产文件
- VERSION/CHANGELOG 频率（版本纪律指标）
Step 7: PR 大小分布
从提交差异估算 PR 大小并分桶：
- 小（<100 LOC）
- 中（100-500 LOC）
- 大（500-1500 LOC）
- 超大（1500+ LOC）—— 标记这些及其文件计数
Step 8: 专注分数 + 本周发布
专注分数: 计算触碰单个最常变更顶级目录的提交百分比。 更高分数 = 更深入的专注工作。 更低分数 = 分散的上下文切换。
本周发布: 自动识别窗口内 LOC 最高的单个 PR。 突出显示：
- PR 编号和标题
- LOC 变更
- 为什么重要（从提交消息和触碰的文件推断）
Step 9: 团队成员分析
对每个贡献者（包括当前用户），计算：
- 提交和 LOC — 总提交、插入、删除、净 LOC
- 专注领域 — 他们最常触碰的目录/文件（前3）
- 提交类型组合 — 他们个人的 feat/fix/refactor/test 分解
- 会话模式 — 他们何时编码（高峰时段）、会话计数
- 测试纪律 — 他们个人的测试 LOC 比例
- 最大发布 — 他们窗口内影响最大的单个提交或 PR
对于当前用户（"你"）: 这部分获得最深入的处理。 包括所有个人复盘的细节——会话分析、时间模式、专注分数。 用第一人称表述："你的高峰时段..."、"你的最大发布..."
对于每个队友: 写2-3句话涵盖他们做了什么和他们的模式。 然后：
- 表扬（1-2个具体事项）：锚定在实际提交。 不是"干得好"——确切说明哪里好。
- 成长机会（1个具体事项）：框架为升级建议，而非批评。
如果只有一个贡献者（单人仓库）: 跳过团队分解，作为个人复盘处理。
Step 10: 周对周趋势（如果窗口 >= 14d）
如果时间窗口为14天或更长，拆分为周桶并展示趋势：
- 每周提交数（总计和每作者）
- 每��� LOC
- 每周测试比例
- 每周 fix 比例
- 每周会话计数
Step 11: 连续追踪
计算从今天开始向回追溯的连续天数中至少有1次提交到 origin/<default>。 追踪团队连续和个人连续：
# 团队连续：所有唯一提交日期
git log origin/<default> --format="%ad" --date=format:"%Y-%m-%d" | sort -u
# 个人连续：仅当前用户的提交
git log origin/<default> --author="<user_name>" --format="%ad" --date=format:"%Y-%m-%d" | sort -u
从今天向后计数——有多少连续天数至少有一次提交？ 显示：
- "团队发布连续：47 天"
- "你的发布连续：32 天"
Step 12: 加载历史并比较
在保存新快照之前，检查之前的复盘历史：
ls -t .context/retros/*.json 2>/dev/null
如果存在之前的复盘: 使用 Read 工具加载最近的一个。 计算关键指标的增量并包含 与上次复盘的趋势 部分：
上次 现在 增量
测试比例: 22% → 41% ↑19pp
会话数: 10 → 14 ↑4
LOC/小时: 200 → 350 ↑75%
Fix 比例: 54% → 30% ↓24pp (改善中)
提交数: 32 → 47 ↑47%
深度会话: 3 → 5 ↑2
如果不存在之前的复盘: 跳过比较部分并附加："首次复盘记录——下周再次运行以查看趋势。"
Step 13: 保存复盘历史
计算完所有指标（包括连续）并加载任何之前的历史进行比较后，保存 JSON 快照：
mkdir -p .context/retros
确定今天的下一个序列号：
today=$(date +%Y-%m-%d)
existing=$(ls .context/retros/${today}-*.json 2>/dev/null | wc -l | tr -d ' ')
next=$((existing + 1))
# 保存为 .context/retros/${today}-${next}.json
使用 Write 工具保存 JSON 文件，使用此结构：
{
"date": "2026-03-18",
"window": "7d",
"metrics": {
"commits": 47,
"contributors": 3,
"prs_merged": 12,
"insertions": 3200,
"deletions": 800,
"net_loc": 2400,
"test_loc": 1300,
"test_ratio": 0.41,
"active_days": 6,
"sessions": 14,
"deep_sessions": 5,
"avg_session_minutes": 42,
"loc_per_session_hour": 350,
"feat_pct": 0.40,
"fix_pct": 0.30,
"peak_hour": 22
},
"authors": {
"张三": { "commits": 32, "insertions": 2400, "deletions": 300, "test_ratio": 0.41, "top_area": "browse/" },
"李四": { "commits": 12, "insertions": 800, "deletions": 150, "test_ratio": 0.35, "top_area": "app/services/" }
},
"streak_days": 47,
"summary": "3月第1周: 47次提交 (3人), 3.2k LOC, 38% 测试, 12 PRs, 高峰: 晚10点"
}
Step 14: 撰写叙述
将输出结构化为：
一句话摘要（第一行，在所有内容之前）：
3月第1周: 47次提交 (3人), 3.2k LOC, 38% 测试, 12 PRs, 高峰: 晚10点 | 连续: 47天
工程复盘: [日期范围]
摘要表
（来自 Step 2）
与上次复盘的趋势
（来自 Step 12，保存前加载——如果是首次复盘则跳过）
时间与会话模式
（来自 Steps 3-4）
叙述解释团队范围的模式意味着什么：
- 最有成效的时段是什么，什么驱动它们
- 会话是否随时间变长或变短
- 每天活跃编码的估计小时数（团队汇总）
- 值得注意的模式：团队成员是否在同一时间编码还是轮班？
发布速度
（来自 Steps 5-7）
叙述涵盖：
- 提交类型组合及其揭示的内容
- PR 大小纪律（PR 是否保持小？）
- Fix 链检测（同一子系统上的连续 fix 提交）
- 版本号纪律
代码质量信号
- 测试 LOC 比例趋势
- 热点分析（相同文件是否在流失？）
- 任何应该拆分的超大 PR
测试健康度
- 总测试文件：N
- 本期新增测试：M
- 回归测试提交：列出
test:和fix:提交 - 如果测试比例 < 20%：标记为成长领域
专注与亮点
（来自 Step 8）
- 专注分数及解释
- 本周发布亮点
你的一周（个人深入分析）
（来自 Step 9，仅针对当前用户）
这是用户最关心的部分。包括：
- 他们个人的提交计数、LOC、测试比例
- 他们的会话模式和高峰时段
- 他们的专注领域
- 他们最大的发布
- 你做得好的地方（2-3个锚定在提交的具体事项）
- 可以提升的地方（1-2个具体、可操作的建议）
团队分解
（来自 Step 9，针对每个队友——如果是单人仓库则跳过）
对每个队友（按提交数降序排列），写一个部分：
[名字]
- 他们发布了什么: 2-3句话关于他们的贡献、专注领域和提交模式
- 表扬: 1-2个他们做得好的具体事项，锚定在实际提交
- 成长机会: 1个具体、建设性的建议
团队前3个胜利
识别窗口内整个团队发布的3个影响最大的事项。对每个：
- 它是什么
- 谁发布的
- 为什么重要（产品/架构影响）
3个需要改进的事项
具体、可操作、锚定在实际提交。混合个人和团队级别的建议。
下周的3个习惯
小、实用、现实。每个必须是可以 <5 分钟采用的事项。
周对周趋势
（如果适用，来自 Step 10）
比较模式
当用户运行 /sdlc-retro compare（或 /sdlc-retro compare 14d）时：
- 使用
--since="7 days ago"计算当前窗口的指标 - 使用
--since和--until计算紧邻的前一个等长窗口的指标以避免重叠 - 展示带有增量和箭头的并排比较表
- 写一个简短的叙述突出最大的改进和退步
- 仅将当前窗口快照保存到
.context/retros/
语气
- 鼓励但坦诚，不溺爱
- 具体和实在——始终锚定在实际提交/代码
- 跳过通用表扬（"干得好！"）——确切说明哪里好以及为什么
- 将改进框架为升级，而非批评
- 表扬应该感觉像是你在 1:1 中实际会说的——具体、有根据、真诚
- 成长建议应该感觉像是投资建议——"这值得你时间因为..."，而不是"你失败了..."
- 永远不要负面比较队友。每个人的部分独立存在。
- 总输出约 2000-3000 字
- 使用 markdown 表格和代码块展示数据，叙述用散文
- 直接输出到对话——不要写入文件系统（除了
.context/retros/JSON 快照）
重要规则
- 所有叙述输出直接给用户在对话中。唯一写入的文件是
.context/retros/JSON 快照。 - 对所有 git 查询使用
origin/<default>（不是可能过时的本地 main） - 如果窗口有零提交，说明并建议不同的窗口
- LOC/小时四舍五入到最近的 50
- 将合并提交视为 PR 边界
- 首次运行（无之前复盘）时，优雅地跳过比较部分