mcpField
G
gstack-openclaw-retro

gstack-openclaw-retro

github.com/garrytan开发138.1k290 次安装今天更新
代码仓库

关于 gstack-openclaw-retro

gstack-openclaw-retro 是一项根据仓库提交历史和代码指标生成工程回顾的技能。它支持指定时间范围和周期比较，并保存快照以追踪趋势。

主要功能

  1. 01自定义回顾时间范围
  2. 02提交与代码指标统计
  3. 03按贡献者分析
  4. 04工作时段与会话分析
  5. 05保存历史快照并比较

适用场景

  1. 01回顾团队近期工程工作
  2. 02比较不同时间段的活动
  3. 03追踪代码与测试趋势

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/garrytan/gstack --skill gstack-openclaw-retro

安装后在 Claude Code 中输入/gstack-openclaw-retro确认已加载。

详细介绍

每周工程回顾

生成一份全面的工程回顾，分析提交历史、工作模式和代码质量指标。可感知团队：识别运行命令的用户，然后分析每位贡献者，并分别指出优点和成长机会。

参数

  • 默认：过去 7 天
  • 24h：过去 24 小时
  • 14d：过去 14 天
  • 30d：过去 30 天
  • compare：比较当前时间窗口与此前相同长度的时间窗口

指令

解析参数以确定时间窗口。默认为 7 天。所有时间都应以用户的本地时区报告。

按午夜对齐的时间窗口： 对于以天为单位的时间窗口，计算一个以当地午夜为起点的绝对日期。例如，如果今天是 2026-03-18，时间窗口为 7 天，则起始日期为 2026-03-11。对 git log 查询使用 --since="2026-03-11T00:00:00"。对于以小时为单位的时间窗口，使用 --since="N hours ago"。

步骤 1：收集原始数据

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

git fetch origin main --quiet
git config user.name
git config user.email

git config user.name 返回的名称就是**“你”**……也就是阅读这份回顾的人。其他所有作者都是队友。

运行以下所有 git 命令（这些命令彼此独立）：

# All commits with timestamps, subject, hash, author, files changed
git log origin/main --since="<window>" --format="%H|%aN|%ae|%ai|%s" --shortstat

# Per-commit test vs total LOC breakdown with author
git log origin/main --since="<window>" --format="COMMIT:%H|%aN" --numstat

# Commit timestamps for session detection and hourly distribution
git log origin/main --since="<window>" --format="%at|%aN|%ai|%s" | sort -n

# Files most frequently changed (hotspot analysis)
git log origin/main --since="<window>" --format="" --name-only | grep -v '^$' | sort | uniq -c | sort -rn

# PR numbers from commit messages
git log origin/main --since="<window>" --format="%s" | grep -oE '[#!][0-9]+' | sort -t'#' -k1 | uniq

# Per-author file hotspots
git log origin/main --since="<window>" --format="AUTHOR:%aN" --name-only

# Per-author commit counts
git shortlog origin/main --since="<window>" -sn --no-merges

# Test file count
git ls-files 2>/dev/null | grep -E '(\.test\.|\.spec\.|_test\.|_spec\.)' | wc -l

# Test files changed in window
git log origin/main --since="<window>" --format="" --name-only | grep -E '\.(test|spec)\.' | sort -u | wc -l
步骤 2：计算指标

在摘要中计算并展示以下指标：

  • 合并到 main 的提交数： N
  • 贡献者： N
  • 已合并的 PR： N
  • 新增行总数： N
  • 删除行总数： N
  • 净增代码行数： N
  • 测试代码行数（新增）： N
  • 测试代码行占比： N%
  • 版本范围： vX.Y.Z → vX.Y.Z
  • 活跃天数： N
  • 检测到的工作时段： N
  • 每个时段小时数的平均代码行数： N

然后立即在下方展示作者排行榜：

Contributor         Commits   +/-          Top area
You (garry)              32   +2400/-300   browse/
alice                    12   +800/-150    app/services/
bob                       3   +120/-40     tests/

按提交数降序排序。当前用户始终排在第一位，标签为“You (name)”。

步骤 3：提交时间分布

以本地时间显示每小时的直方图：

Hour  Commits  ████████████████
 00:    4      ████
 07:    5      █████
 ...

识别：

  • 高峰时段
  • 空档时段
  • 双峰模式（早晨／傍晚）还是连续分布
  • 深夜编码集中时段（晚上 10 点后）
步骤 4：检测工作时段

使用连续提交之间45 分钟的间隔作为阈值来检测时段。

对时段分类：

  • 深度时段（50 分钟以上）
  • 中等时段（20–50 分钟）
  • 微型时段（不足 20 分钟，单次提交）

计算：

  • 活跃编码总时长
  • 平均时段长度
  • 活跃时长内每小时的代码行数
步骤 5：提交类型细分

按 Conventional Commits 前缀（feat/fix/refactor/test/chore/docs）分类。以百分比条形图显示：

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

如果 fix 占比超过 50%，请标记……这表明存在“快速发布、快速修复”的模式，可能意味着代码审查存在缺口。

步骤 6：热点分析

展示改动最多的 10 个文件。标记：

  • 改动 5 次以上的文件（高频变更热点）
  • 热点列表中的测试文件与生产文件
  • VERSION/CHANGELOG 的变更频率
步骤 7：PR 大小分布

估算 PR 大小并分档：

  • 小型（不足 100 LOC）
  • 中型（100–500 LOC）
  • 大型（500–1500 LOC）
  • 超大型（1500 LOC 以上）
步骤 8：专注度得分 + 本周交付

专注度得分： 触及变更最多的单个顶层目录的提交所占百分比。得分越高，表示工作越专注深入；得分越低，表示上下文切换越分散。

本周交付： 时间窗口内 LOC 最高的单个 PR。突出显示 PR 编号、变更的 LOC，以及其重要性。

步骤 9：团队成员分析

针对每位贡献者（包括当前用户），计算：

  1. 提交和代码行数 ... 提交总数、新增行数、删除行数、净代码行数
  2. 关注领域 ... 他们修改最多的目录/文件（前 3 项）
  3. 提交类型构成 ... 个人的 feat/fix/refactor/test 分类情况
  4. 工作时段模式 ... 编码时间（高峰时段）、会话数量
  5. 测试规范性 ... 个人测试代码行数占比
  6. 最大交付成果 ... 影响最大的单次提交或 PR

对于当前用户（“你”）： 深入分析。包含所有会话分析、时间模式和专注度评分。使用第一人称表述。

对于每位队友： 用 2-3 句话介绍他们交付的成果和工作模式。然后列出：

  • 值得肯定之处（1-2 项具体表现）：以实际提交为依据。不要只说“做得很好” ... 要具体说明做得好的地方。
  • 成长机会（1 项具体建议）：以成长进阶的角度提出，而非批评。以实际数据为依据。

如果是个人项目仓库： 跳过团队分析。

AI 协作： 如果提交中有 Co-Authored-By AI 署名行，请将“AI 辅助提交”作为单独指标统计。

步骤 10：逐周趋势（如果时间范围 >= 14d）

按周分组并展示趋势：

  • 每周提交数（总数和按作者统计）
  • 每周代码行数
  • 每周测试占比
  • 每周修复占比
  • 每周会话数
步骤 11：连续提交天数追踪

从今天开始向前统计连续至少有 1 次提交的天数：

# Team streak
git log origin/main --format="%ad" --date=format:"%Y-%m-%d" | sort -u

# Personal streak
git log origin/main --author="<user_name>" --format="%ad" --date=format:"%Y-%m-%d" | sort -u

同时展示：

  • “团队连续交付天数：47 天”
  • “你的连续交付天数：32 天”
步骤 12：加载历史并进行比较

检查 memory/ 中是否有以往的回顾记录：

如果有以往的回顾记录，加载最近一份并计算变化量：

                    Last        Now         Delta
Test ratio:         22%    →    41%         ↑19pp
Sessions:           10     →    14          ↑4
LOC/hour:           200    →    350         ↑75%
Fix ratio:          54%    →    30%         ↓24pp (improving)

如果没有以往的回顾记录，请注明“首次记录回顾，请下周再次运行以查看趋势。”

步骤 13：保存回顾历史

将包含指标、作者、版本范围、连续提交天数和适合发推的摘要的 JSON 快照保存到 memory/retro-YYYY-MM-DD.json。

步骤 14：撰写回顾内容

Telegram 格式（使用项目符号、粗体，最终输出中不要使用 Markdown 表格）。

结构：

适合发推的摘要（首行）：

3 月 1 日当周：47 次提交（3 位贡献者）、3.2k 代码行、38% 测试、12 个 PR，高峰时段：晚上 10 点 | 连续交付：47 天

然后分为以下部分：

  • 摘要 ... 关键指标
  • 与上次回顾相比的趋势 ... 变化量（首次回顾时跳过）
  • 时间与会话模式 ... 团队的编码时间、会话时长、深度工作与碎片工作
  • 交付速度 ... 提交类型、PR 大小、修复链检测
  • 代码质量信号 ... 测试占比、热点、代码变更量
  • 专注度与亮点 ... 专注度评分、本周交付成果
  • 你的一周 ... 当前用户的个人深入分析
  • 团队成员分析 ... 每位队友的分析，包括值得肯定之处和成长建议（个人项目时跳过）
  • 团队 3 大成果 ... 影响最大的 3 项交付
  • 3 项改进建议 ... 具体、可执行，并以提交为依据
  • 下周 3 个习惯 ... 小巧、实用、现实（养成时间少于 5 分钟）

比较模式

用户说“比较”时：

  • 对当前时间范围运行回顾
  • 对此前相同长度的时间范围运行回顾
  • 并列展示指标，并用箭头标示提升或回退
  • 简要说明最大的变化

重要规则

  • 所有时间均使用本地时区。 绝不设置 TZ。
  • 使用 Telegram 格式。 使用项目符号和粗体。最终输出中避免使用 Markdown 表格。
  • 表扬必须以提交为依据。 不要只说“做得很好”，而不说明具体好在哪里。
  • 成长建议必须以数据为依据。 没有证据时不要批评。
  • 保存历史。 每次回顾都保存到 memory/，用于追踪趋势。
  • 完成状态：
    • DONE ... 已生成回顾并保存历史
    • DONE_WITH_CONCERNS ... 已生成回顾，但数据不完整（例如，没有以往的回顾记录可供比较）
    • BLOCKED ... 当前目录不是 git 仓库，或指定时间范围内没有提交

评论

支持 Markdown