retro

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Preamble (run first)

前置步骤（首先执行）

bash

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"

If output shows

UPGRADE_AVAILABLE <old> <new>

: read

~/.claude/skills/gstack/gstack-upgrade/SKILL.md

and follow the "Inline upgrade flow" (auto-upgrade if configured, otherwise AskUserQuestion with 4 options, write snooze state if declined). If

JUST_UPGRADED <from> <to>

: tell user "Running gstack v{to} (just updated!)" and continue.

bash

_UPD=$(~/.claude/skills/gstack/bin/gstack-update-check 2>/dev/null || .claude/skills/gstack/bin/gstack-update-check 2>/dev/null || true)
[ -n "$_UPD" ] && echo "$_UPD" || true
mkdir -p ~/.gstack/sessions
touch ~/.gstack/sessions/"$PPID"
_SESSIONS=$(find ~/.gstack/sessions -mmin -120 -type f 2>/dev/null | wc -l | tr -d ' ')
find ~/.gstack/sessions -mmin +120 -type f -delete 2>/dev/null || true
_CONTRIB=$(~/.claude/skills/gstack/bin/gstack-config get gstack_contributor 2>/dev/null || true)
_BRANCH=$(git branch --show-current 2>/dev/null || echo "unknown")
echo "BRANCH: $_BRANCH"

如果输出显示

UPGRADE_AVAILABLE <old> <new>

：请阅读

~/.claude/skills/gstack/gstack-upgrade/SKILL.md

并遵循「在线升级流程」（如果已配置则自动升级，否则向用户提供4个选项，若用户拒绝则记录snooze状态）。如果显示

JUST_UPGRADED <from> <to>

：告知用户「正在运行gstack v{to}（刚完成更新！）」并继续。

AskUserQuestion Format

提问格式规范

ALWAYS follow this structure for every AskUserQuestion call:

Re-ground: State the project, the current branch (use the
```
_BRANCH
```
value printed by the preamble — NOT any branch from conversation history or gitStatus), and the current plan/task. (1-2 sentences)
Simplify: Explain the problem in plain English a smart 16-year-old could follow. No raw function names, no internal jargon, no implementation details. Use concrete examples and analogies. Say what it DOES, not what it's called.

Recommend:

RECOMMENDATION: Choose [X] because [one-line reason]

Options: Lettered options:
```
A) ... B) ... C) ...
```

Assume the user hasn't looked at this window in 20 minutes and doesn't have the code open. If you'd need to read the source to understand your own explanation, it's too complex.

Per-skill instructions may add additional formatting rules on top of this baseline.

每次调用AskUserQuestion时必须严格遵循以下结构：

重新梳理上下文： 说明当前项目、当前分支（使用前置步骤输出的
```
_BRANCH
```
值，而非对话历史或gitStatus中的分支），以及当前计划/任务。（1-2句话）
简化解释： 用一个聪明的16岁少年能理解的直白语言解释问题。不要使用原始函数名、内部术语或实现细节。使用具体示例和类比，说明功能是什么，而非叫什么名字。

推荐方案：

RECOMMENDATION: 选择[X]，因为[一句话理由]

选项： 带字母的选项：
```
A) ... B) ... C) ...
```

假设用户已经20分钟没看这个窗口，也没有打开代码。如果你的解释需要阅读源代码才能理解，说明过于复杂。

特定技能的说明可能会在此基础格式上添加额外的格式规则。

Contributor Mode

贡献者模式

_CONTRIB

true

: you are in contributor mode. You're a gstack user who also helps make it better.

At the end of each major workflow step (not after every single command), reflect on the gstack tooling you used. Rate your experience 0 to 10. If it wasn't a 10, think about why. If there is an obvious, actionable bug OR an insightful, interesting thing that could have been done better by gstack code or skill markdown — file a field report. Maybe our contributor will help make us better!

Calibration — this is the bar: For example,

$B js "await fetch(...)"

used to fail with

SyntaxError: await is only valid in async functions

because gstack didn't wrap expressions in async context. Small, but the input was reasonable and gstack should have handled it — that's the kind of thing worth filing. Things less consequential than this, ignore.

NOT worth filing: user's app bugs, network errors to user's URL, auth failures on user's site, user's own JS logic bugs.

To file: write

~/.gstack/contributor-logs/{slug}.md

with all sections below (do not truncate — include every section through the Date/Version footer):

undefined

如果

_CONTRIB

为

true

：你处于贡献者模式。你是gstack的用户，同时也帮助改进它。

在每个主要工作流步骤结束时（不是每个命令后），反思你使用的gstack工具。给你的体验打分0到10。如果不是10分，思考原因。如果存在明显的、可操作的bug，或者gstack代码或技能markdown有可以改进的地方——提交一份现场报告。也许我们的贡献者能帮助我们变得更好！

校准标准： 例如，

$B js "await fetch(...)"

曾经因为gstack没有将表达式包装在async上下文中而失败，报错

SyntaxError: await is only valid in async functions

。这是一个小问题，但输入是合理的，gstack应该处理它——这种情况值得提交报告。比这影响更小的问题，可以忽略。

不值得提交的情况： 用户应用的bug、用户URL的网络错误、用户网站的认证失败、用户自己的JS逻辑bug。

提交报告： 写入

~/.gstack/contributor-logs/{slug}.md

，包含以下所有部分（不要截断——包括到日期/版本页脚的每个部分）：

undefined

{Title}

{标题}

Hey gstack team — ran into this while using /{skill-name}:

What I was trying to do: {what the user/agent was attempting} What happened instead: {what actually happened} My rating: {0-10} — {one sentence on why it wasn't a 10}

嘿gstack团队——我在使用/{skill-name}时遇到了这个问题：

我尝试做的事情： {用户/agent的操作意图} 实际发生的情况： {实际结果} 我的评分： {0-10} — {一句话说明为什么不是10分}

Steps to reproduce

复现步骤

{step}

{步骤}

Raw output

原始输出

{paste the actual error or unexpected output here}

{在此粘贴实际错误或意外输出}

What would make this a 10

如何达到10分体验

{one sentence: what gstack should have done differently}

Date: {YYYY-MM-DD} | Version: {gstack version} | Skill: /{skill}


Slug: lowercase, hyphens, max 60 chars (e.g. `browse-js-no-await`). Skip if file already exists. Max 3 reports per session. File inline and continue — don't stop the workflow. Tell user: "Filed gstack field report: {title}"

{一句话：gstack应该做出哪些不同的处理}

日期： {YYYY-MM-DD} | 版本： {gstack版本} | 技能： /{skill}


Slug：小写，用连字符分隔，最多60个字符（例如`browse-js-no-await`）。如果文件已存在则跳过。每个会话最多提交3份报告。直接在线提交并继续工作流——不要中断工作流。告知用户："已提交gstack现场报告：{title}"

Detect default branch

检测默认分支

Before gathering data, detect the repo's default branch name:

gh repo view --json defaultBranchRef -q .defaultBranchRef.name

If this fails, fall back to

main

. Use the detected name wherever the instructions say

origin/<default>

below.

收集数据前，检测仓库的默认分支名称：

gh repo view --json defaultBranchRef -q .defaultBranchRef.name

如果失败，回退到

main

。在后续说明中提到

origin/<default>

的地方，使用检测到的分支名。

/retro — Weekly Engineering Retrospective

/retro — 每周工程回顾

Generates a comprehensive engineering retrospective analyzing commit history, work patterns, and code quality metrics. Team-aware: identifies the user running the command, then analyzes every contributor with per-person praise and growth opportunities. Designed for a senior IC/CTO-level builder using Claude Code as a force multiplier.

生成全面的工程回顾报告，分析提交历史、工作模式和代码质量指标。支持团队分析：识别运行命令的用户，然后分析每位贡献者的情况，给出个人表扬和成长机会。专为资深IC/CTO级别的开发者设计，将Claude Code作为效能倍增工具。

User-invocable

用户触发方式

When the user types

/retro

, run this skill.

当用户输入

/retro

时，运行此技能。

Arguments

参数

```
/retro
```
— default: last 7 days
```
/retro 24h
```
— last 24 hours
```
/retro 14d
```
— last 14 days
```
/retro 30d
```
— last 30 days
```
/retro compare
```
— compare current window vs prior same-length window
```
/retro compare 14d
```
— compare with explicit window

```
/retro
```
— 默认：过去7天
```
/retro 24h
```
— 过去24小时
```
/retro 14d
```
— 过去14天
```
/retro 30d
```
— 过去30天
```
/retro compare
```
— 比较当前窗口与之前相同长度的窗口
```
/retro compare 14d
```
— 使用指定窗口进行比较

Instructions

操作说明

Parse the argument to determine the time window. Default to 7 days if no argument given. Use

--since="N days ago"

--since="N hours ago"

, or

--since="N weeks ago"

(for

units) for git log queries. All times should be reported in Pacific time (use

TZ=America/Los_Angeles

when converting timestamps).

Argument validation: If the argument doesn't match a number followed by

, or

, the word

compare

, or

compare

followed by a number and

, show this usage and stop:

Usage: /retro [window]
  /retro              — last 7 days (default)
  /retro 24h          — last 24 hours
  /retro 14d          — last 14 days
  /retro 30d          — last 30 days
  /retro compare      — compare this period vs prior period
  /retro compare 14d  — compare with explicit window

解析参数以确定时间窗口。如果没有参数，默认使用7天。在git log查询中使用

--since="N days ago"

、

--since="N hours ago"

或

--since="N weeks ago"

（针对

单位）。所有时间均以太平洋时间显示（转换时间戳时使用

TZ=America/Los_Angeles

）。

参数验证： 如果参数不符合「数字+d/h/w」、单词

compare

或

compare+数字+d/h/w

的格式，显示以下用法说明并停止执行：

用法：/retro [时间窗口]
  /retro              — 过去7天（默认）
  /retro 24h          — 过去24小时
  /retro 14d          — 过去14天
  /retro 30d          — 过去30天
  /retro compare      — 比较当前周期与之前周期
  /retro compare 14d  — 使用指定窗口进行比较

Step 1: Gather Raw Data

步骤1：收集原始数据

First, fetch origin and identify the current user:

bash

git fetch origin <default> --quiet

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

bash

git fetch origin <default> --quiet

Identify who is running the retro

识别运行回顾的用户

git config user.name git config user.email


The name returned by `git config user.name` is **"you"** — the person reading this retro. All other authors are teammates. Use this to orient the narrative: "your" commits vs teammate contributions.

Run ALL of these git commands in parallel (they are independent):

```bash

git config user.name git config user.email


`git config user.name`返回的名称是**"你"**——阅读此回顾的人。所有其他作者都是队友。以此为叙事导向："你的"提交 vs 队友的贡献。

并行运行所有这些git命令（它们相互独立）：

```bash

1. All commits in window with timestamps, subject, hash, AUTHOR, files changed, insertions, deletions

1. 时间窗口内的所有提交，包含时间戳、主题、哈希值、作者、修改的文件、插入行数、删除行数

git log origin/<default> --since="<window>" --format="%H|%aN|%ae|%ai|%s" --shortstat

2. Per-commit test vs total LOC breakdown with author

2. 按提交统计测试代码与总代码行数的占比，包含作者

Each commit block starts with COMMIT:<hash>|<author>, followed by numstat lines.

每个提交块以COMMIT:<hash>|<author>开头，后跟numstat行。

Separate test files (matching test/|spec/|tests/) from production files.

将测试文件（匹配test/|spec/|tests/）与生产文件分开。

git log origin/<default> --since="<window>" --format="COMMIT:%H|%aN" --numstat

3. Commit timestamps for session detection and hourly distribution (with author)

3. 用于会话检测和小时分布的提交时间戳（包含作者）

Use TZ=America/Los_Angeles for Pacific time conversion

使用TZ=America/Los_Angeles转换为太平洋时间

TZ=America/Los_Angeles git log origin/<default> --since="<window>" --format="%at|%aN|%ai|%s" | sort -n

4. Files most frequently changed (hotspot analysis)

4. 最常被修改的文件（热点分析）

git log origin/<default> --since="<window>" --format="" --name-only | grep -v '^$' | sort | uniq -c | sort -rn

5. PR numbers from commit messages (extract #NNN patterns)

5. 提交信息中的PR编号（提取#NNN模式）

6. Per-author file hotspots (who touches what)

6. 按作者统计的文件热点（谁修改了哪些文件）

git log origin/<default> --since="<window>" --format="AUTHOR:%aN" --name-only

7. Per-author commit counts (quick summary)

7. 按作者统计的提交次数（快速摘要）

git shortlog origin/<default> --since="<window>" -sn --no-merges

8. Greptile triage history (if available)

8. Greptile分类历史（如果可用）

cat ~/.gstack/greptile-history.md 2>/dev/null || true

9. TODOS.md backlog (if available)

9. TODOS.md待办事项（如果可用）

cat TODOS.md 2>/dev/null || true

undefined

cat TODOS.md 2>/dev/null || true

undefined

Step 2: Compute Metrics

步骤2：计算指标

Calculate and present these metrics in a summary table:

Metric	Value
Commits to main	N
Contributors	N
PRs merged	N
Total insertions	N
Total deletions	N
Net LOC added	N
Test LOC (insertions)	N
Test LOC ratio	N%
Version range	vX.Y.Z.W → vX.Y.Z.W
Active days	N
Detected sessions	N
Avg LOC/session-hour	N
Greptile signal	N% (Y catches, Z FPs)

Then show a per-author leaderboard immediately below:

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

Sort by commits descending. The current user (from

git config user.name

) always appears first, labeled "You (name)".

Greptile signal (if history exists): Read

~/.gstack/greptile-history.md

(fetched in Step 1, command 8). Filter entries within the retro time window by date. Count entries by type:

fix

fp

already-fixed

. Compute signal ratio:

(fix + already-fixed) / (fix + already-fixed + fp)

. If no entries exist in the window or the file doesn't exist, skip the Greptile metric row. Skip unparseable lines silently.

Backlog Health (if TODOS.md exists): Read

TODOS.md

(fetched in Step 1, command 9). Compute:

Total open TODOs (exclude items in
```
## Completed
```
section)
P0/P1 count (critical/urgent items)
P2 count (important items)
Items completed this period (items in Completed section with dates within the retro window)
Items added this period (cross-reference git log for commits that modified TODOS.md within the window)

Include in the metrics table:

| Backlog Health | N open (X P0/P1, Y P2) · Z completed this period |

If TODOS.md doesn't exist, skip the Backlog Health row.

计算并在汇总表中展示以下指标：

指标	数值
提交到主分支的次数	N
贡献者数量	N
合并的PR数量	N
总插入行数	N
总删除行数	N
净增加代码行数	N
测试代码插入行数	N
测试代码占比	N%
版本范围	vX.Y.Z.W → vX.Y.Z.W
活跃天数	N
检测到的会话数	N
平均每会话小时代码行数	N
Greptile信号率	N%（Y次有效捕获，Z次误报）

然后在下方立即显示按作者排名的榜单：

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

按提交次数降序排序。当前用户（来自

git config user.name

）始终排在第一位，标注为"你（姓名）"。

Greptile信号率（如果有历史记录）： 读取

~/.gstack/greptile-history.md

（步骤1中获取的命令8）。按日期筛选回顾时间窗口内的条目。按类型统计条目：

fix

、

fp

、

already-fixed

。计算信号率：

(fix + already-fixed) / (fix + already-fixed + fp)

。如果窗口内没有条目或文件不存在，跳过Greptile指标行。静默跳过无法解析的行。

待办事项健康度（如果TODOS.md存在）： 读取

TODOS.md

（步骤1中获取的命令9）。计算：

未完成的总TODO数（排除
```
## Completed
```
部分的条目）
P0/P1数量（关键/紧急条目）
P2数量（重要条目）
本周期完成的条目（Completed部分中日期在回顾窗口内的条目）
本周期新增的条目（交叉引用git log中在窗口内修改TODOS.md的提交）

在指标表中添加：

| 待办事项健康度 | N个未完成（X个P0/P1，Y个P2）· 本周期完成Z个 |

如果TODOS.md不存在，跳过待办事项健康度行。

Step 3: Commit Time Distribution

步骤3：提交时间分布

Show hourly histogram in Pacific time using bar chart:

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

Identify and call out:

Peak hours
Dead zones
Whether pattern is bimodal (morning/evening) or continuous
Late-night coding clusters (after 10pm)

使用柱状图展示太平洋时间的小时分布：

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

识别并指出：

高峰时段
低谷时段
模式是双峰（早/晚）还是连续
深夜代码集群（晚上10点后）

Step 4: Work Session Detection

步骤4：工作会话检测

Detect sessions using 45-minute gap threshold between consecutive commits. For each session report:

Start/end time (Pacific)
Number of commits
Duration in minutes

Classify sessions:

Deep sessions (50+ min)
Medium sessions (20-50 min)
Micro sessions (<20 min, typically single-commit fire-and-forget)

Calculate:

Total active coding time (sum of session durations)
Average session length
LOC per hour of active time

使用45分钟间隔阈值检测会话，即连续提交之间的间隔超过45分钟则视为不同会话。每个会话报告：

开始/结束时间（太平洋时间）
提交次数
持续时间（分钟）

将会话分类：

深度会话（50分钟以上）
中等会话（20-50分钟）
微型会话（少于20分钟，通常是单次提交即完成）

计算：

总活跃编码时间（会话持续时间之和）
平均会话长度
每活跃小时的代码行数

Step 5: Commit Type Breakdown

步骤5：提交类型分类

Categorize by conventional commit prefix (feat/fix/refactor/test/chore/docs). Show as percentage bar:

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

Flag if fix ratio exceeds 50% — this signals a "ship fast, fix fast" pattern that may indicate review gaps.

按约定式提交前缀分类（feat/fix/refactor/test/chore/docs）。以百分比柱状图展示：

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

如果修复提交占比超过50%，标记出来——这表明"快速发布，快速修复"的模式，可能意味着代码审查存在漏洞。

Step 6: Hotspot Analysis

步骤6：热点分析

Show top 10 most-changed files. Flag:

Files changed 5+ times (churn hotspots)
Test files vs production files in the hotspot list
VERSION/CHANGELOG frequency (version discipline indicator)

显示前10个最常被修改的文件。标记：

被修改5次以上的文件（频繁变动热点）
热点列表中的测试文件与生产文件
VERSION/CHANGELOG的修改频率（版本规范指标）

Step 7: PR Size Distribution

步骤7：PR大小分布

From commit diffs, estimate PR sizes and bucket them:

Small (<100 LOC)
Medium (100-500 LOC)
Large (500-1500 LOC)
XL (1500+ LOC) — flag these with file counts

从提交差异中估算PR大小并分组：

小型（少于100行代码）
中型（100-500行代码）
大型（500-1500行代码）
超大型（1500行以上）——标记这些并显示文件数量

Step 8: Focus Score + Ship of the Week

步骤8：专注度评分 + 本周重点交付

Focus score: Calculate the percentage of commits touching the single most-changed top-level directory (e.g.,

app/services/

app/views/

). Higher score = deeper focused work. Lower score = scattered context-switching. Report as: "Focus score: 62% (app/services/)"

Ship of the week: Auto-identify the single highest-LOC PR in the window. Highlight it:

PR number and title
LOC changed
Why it matters (infer from commit messages and files touched)

专注度评分： 计算提交中触及单个最常修改的顶级目录的百分比（例如

app/services/

、

app/views/

）。评分越高表示工作越专注，评分越低表示上下文切换频繁。报告格式："专注度评分：62%（app/services/）"

本周重点交付： 自动识别窗口内代码行数最多的单个PR。突出显示：

PR编号和标题
修改的代码行数
重要性（从提交信息和修改的文件推断）

Step 9: Team Member Analysis

步骤9：团队成员分析

For each contributor (including the current user), compute:

Commits and LOC — total commits, insertions, deletions, net LOC
Areas of focus — which directories/files they touched most (top 3)
Commit type mix — their personal feat/fix/refactor/test breakdown
Session patterns — when they code (their peak hours), session count
Test discipline — their personal test LOC ratio
Biggest ship — their single highest-impact commit or PR in the window

For the current user ("You"): This section gets the deepest treatment. Include all the detail from the solo retro — session analysis, time patterns, focus score. Frame it in first person: "Your peak hours...", "Your biggest ship..."

For each teammate: Write 2-3 sentences covering what they worked on and their pattern. Then:

Praise (1-2 specific things): Anchor in actual commits. Not "great work" — say exactly what was good. Examples: "Shipped the entire auth middleware rewrite in 3 focused sessions with 45% test coverage", "Every PR under 200 LOC — disciplined decomposition."
Opportunity for growth (1 specific thing): Frame as a leveling-up suggestion, not criticism. Anchor in actual data. Examples: "Test ratio was 12% this week — adding test coverage to the payment module before it gets more complex would pay off", "5 fix commits on the same file suggest the original PR could have used a review pass."

If only one contributor (solo repo): Skip the team breakdown and proceed as before — the retro is personal.

If there are Co-Authored-By trailers: Parse

Co-Authored-By:

lines in commit messages. Credit those authors for the commit alongside the primary author. Note AI co-authors (e.g.,

noreply@anthropic.com

) but do not include them as team members — instead, track "AI-assisted commits" as a separate metric.

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

提交次数和代码行数 — 总提交次数、插入行数、删除行数、净代码行数
专注领域 — 他们最常修改的目录/文件（前3个）
提交类型占比 — 个人的feat/fix/refactor/test分类
会话模式 — 他们的编码时间（高峰时段）、会话数量
测试规范 — 个人的测试代码占比
最大交付 — 他们在窗口内影响最大的单个提交或PR

对于当前用户（"你"）： 此部分最详细。包含个人回顾的所有细节——会话分析、时间模式、专注度评分。以第一人称表述："你的高峰时段..."、"你的最大交付..."

对于每位队友： 写2-3句话介绍他们的工作内容和模式。然后：

表扬（1-2个具体事项）：基于实际提交。不要说"做得好"——要具体说明好在哪里。例如："在3个专注的会话中完成了整个认证中间件的重写，测试覆盖率达45%"、"每个PR都控制在200行代码以内——分解工作很规范。"
成长机会（1个具体事项）：作为提升建议，而非批评。基于实际数据。例如："本周测试代码占比为12%——在支付模块变得更复杂之前增加测试覆盖率会有回报"、"同一文件有5次修复提交，表明原始PR可能需要一次审查。"

如果只有一位贡献者（个人仓库）： 跳过团队分解，按之前的步骤进行——回顾是个人的。

如果有Co-Authored-By尾注： 解析提交信息中的

Co-Authored-By:

行。将这些作者与主要作者一起计入提交。注意AI合作者（例如

noreply@anthropic.com

），但不要将其作为团队成员——而是将"AI辅助提交"作为单独的指标跟踪。

Step 10: Week-over-Week Trends (if window >= 14d)

步骤10：周同比趋势（如果窗口≥14天）

If the time window is 14 days or more, split into weekly buckets and show trends:

Commits per week (total and per-author)
LOC per week
Test ratio per week
Fix ratio per week
Session count per week

如果时间窗口为14天或更长，按周拆分并显示趋势：

每周提交次数（总数和按作者统计）
每周代码行数
每周测试代码占比
每周修复提交占比
每周会话数量

Step 11: Streak Tracking

步骤11：连续提交追踪

Count consecutive days with at least 1 commit to origin/<default>, going back from today. Track both team streak and personal streak:

bash

undefined

从今天开始回溯，统计连续提交到origin/<default>的天数。同时跟踪团队连续提交天数和个人连续提交天数：

bash

undefined

Team streak: all unique commit dates (Pacific time) — no hard cutoff

团队连续提交天数：所有唯一的提交日期（太平洋时间）——无硬性截止

TZ=America/Los_Angeles git log origin/<default> --format="%ad" --date=format:"%Y-%m-%d" | sort -u

Personal streak: only the current user's commits

个人连续提交天数：仅当前用户的提交

TZ=America/Los_Angeles git log origin/<default> --author="<user_name>" --format="%ad" --date=format:"%Y-%m-%d" | sort -u


Count backward from today — how many consecutive days have at least one commit? This queries the full history so streaks of any length are reported accurately. Display both:
- "Team shipping streak: 47 consecutive days"
- "Your shipping streak: 32 consecutive days"

TZ=America/Los_Angeles git log origin/<default> --author="<user_name>" --format="%ad" --date=format:"%Y-%m-%d" | sort -u


从今天开始回溯——有多少连续的天数至少有一次提交？此查询会读取完整历史，因此可以准确报告任意长度的连续提交天数。同时显示：
- "团队连续交付天数：47天"
- "你的连续交付天数：32天"

Step 12: Load History & Compare

步骤12：加载历史记录并比较

Before saving the new snapshot, check for prior retro history:

bash

ls -t .context/retros/*.json 2>/dev/null

If prior retros exist: Load the most recent one using the Read tool. Calculate deltas for key metrics and include a Trends vs Last Retro section:

                    Last        Now         Delta
Test ratio:         22%    →    41%         ↑19pp
Sessions:           10     →    14          ↑4
LOC/hour:           200    →    350         ↑75%
Fix ratio:          54%    →    30%         ↓24pp (improving)
Commits:            32     →    47          ↑47%
Deep sessions:      3      →    5           ↑2

If no prior retros exist: Skip the comparison section and append: "First retro recorded — run again next week to see trends."

保存新快照前，检查是否有之前的回顾历史：

bash

ls -t .context/retros/*.json 2>/dev/null

如果有之前的回顾记录： 使用Read工具加载最近的一次。计算关键指标的变化量，并添加与上次回顾的趋势对比部分：

                    上次        当前         变化
测试代码占比:         22%    →    41%         ↑19个百分点
会话数量:           10     →    14          ↑4
每小时代码行数:           200    →    350         ↑75%
修复提交占比:          54%    →    30%         ↓24个百分点（有所改善）
提交次数:            32     →    47          ↑47%
深度会话数量:      3      →    5           ↑2

如果没有之前的回顾记录： 跳过对比部分，并添加："首次记录回顾——下周再次运行以查看趋势。"

Step 13: Save Retro History

步骤13：保存回顾历史

After computing all metrics (including streak) and loading any prior history for comparison, save a JSON snapshot:

bash

mkdir -p .context/retros

Determine the next sequence number for today (substitute the actual date for

$(date +%Y-%m-%d)

bash

undefined

计算所有指标（包括连续提交天数）并加载任何之前的历史记录进行比较后，保存JSON快照：

bash

mkdir -p .context/retros

确定今天的下一个序列号（将

$(date +%Y-%m-%d)

替换为实际日期）：

bash

undefined

Count existing retros for today to get next sequence number

统计今天已有的回顾数量以获取下一个序列号

today=$(TZ=America/Los_Angeles date +%Y-%m-%d) existing=$(ls .context/retros/${today}-*.json 2>/dev/null | wc -l | tr -d ' ') next=$((existing + 1))

Save as .context/retros/${today}-${next}.json

保存为.context/retros/${today}-${next}.json


Use the Write tool to save the JSON file with this schema:
```json
{
  "date": "2026-03-08",
  "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,
    "ai_assisted_commits": 32
  },
  "authors": {
    "Garry Tan": { "commits": 32, "insertions": 2400, "deletions": 300, "test_ratio": 0.41, "top_area": "browse/" },
    "Alice": { "commits": 12, "insertions": 800, "deletions": 150, "test_ratio": 0.35, "top_area": "app/services/" }
  },
  "version_range": ["1.16.0.0", "1.16.1.0"],
  "streak_days": 47,
  "tweetable": "Week of Mar 1: 47 commits (3 contributors), 3.2k LOC, 38% tests, 12 PRs, peak: 10pm",
  "greptile": {
    "fixes": 3,
    "fps": 1,
    "already_fixed": 2,
    "signal_pct": 83
  }
}

Note: Only include the

greptile

field if

~/.gstack/greptile-history.md

exists and has entries within the time window. Only include the

backlog

field if

TODOS.md

exists. If either has no data, omit the field entirely.

Include backlog data in the JSON when TODOS.md exists:

json

  "backlog": {
    "total_open": 28,
    "p0_p1": 2,
    "p2": 8,
    "completed_this_period": 3,
    "added_this_period": 1
  }


使用Write工具保存JSON文件，遵循以下 schema：
```json
{
  "date": "2026-03-08",
  "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,
    "ai_assisted_commits": 32
  },
  "authors": {
    "Garry Tan": { "commits": 32, "insertions": 2400, "deletions": 300, "test_ratio": 0.41, "top_area": "browse/" },
    "Alice": { "commits": 12, "insertions": 800, "deletions": 150, "test_ratio": 0.35, "top_area": "app/services/" }
  },
  "version_range": ["1.16.0.0", "1.16.1.0"],
  "streak_days": 47,
  "tweetable": "3月1日当周：47次提交（3位贡献者），3.2k行代码，38%测试代码，12个PR，高峰时段：晚上10点",
  "greptile": {
    "fixes": 3,
    "fps": 1,
    "already_fixed": 2,
    "signal_pct": 83
  }
}

注意： 只有当

~/.gstack/greptile-history.md

存在且时间窗口内有条目时，才包含

greptile

字段。只有当TODOS.md存在时，才包含

backlog

字段。如果其中任何一个没有数据，完全省略该字段。

当TODOS.md存在时，在JSON中包含待办事项数据：

json

  "backlog": {
    "total_open": 28,
    "p0_p1": 2,
    "p2": 8,
    "completed_this_period": 3,
    "added_this_period": 1
  }

Step 14: Write the Narrative

步骤14：撰写叙事报告

Structure the output as:

Tweetable summary (first line, before everything else):

Week of Mar 1: 47 commits (3 contributors), 3.2k LOC, 38% tests, 12 PRs, peak: 10pm | Streak: 47d

输出结构如下：

可分享摘要（第一行，在所有内容之前）：

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

Engineering Retro: [date range]

工程回顾：[日期范围]

Summary Table

摘要表

(from Step 2)

（来自步骤2）

Trends vs Last Retro

与上次回顾的趋势对比

(from Step 11, loaded before save — skip if first retro)

（来自步骤11，保存前加载——首次回顾时跳过）

Time & Session Patterns

时间与会话模式

(from Steps 3-4)

Narrative interpreting what the team-wide patterns mean:

When the most productive hours are and what drives them
Whether sessions are getting longer or shorter over time
Estimated hours per day of active coding (team aggregate)
Notable patterns: do team members code at the same time or in shifts?

（来自步骤3-4）

解释团队模式含义的叙事：

最高效的时段是什么，驱动因素是什么
会话时长是变长还是变短
估算团队每天的活跃编码小时数
值得注意的模式：团队成员是同时编码还是轮班编码？

Shipping Velocity

交付速度

(from Steps 5-7)

Narrative covering:

Commit type mix and what it reveals
PR size discipline (are PRs staying small?)
Fix-chain detection (sequences of fix commits on the same subsystem)
Version bump discipline

（来自步骤5-7）

叙事内容包括：

提交类型占比及其揭示的信息
PR大小规范（PR是否保持小型？）
修复链检测（同一子系统的连续修复提交序列）
版本更新规范

Code Quality Signals

代码质量信号

Test LOC ratio trend
Hotspot analysis (are the same files churning?)
Any XL PRs that should have been split
Greptile signal ratio and trend (if history exists): "Greptile: X% signal (Y valid catches, Z false positives)"

测试代码占比趋势
热点分析（相同文件是否频繁变动？）
任何应该拆分的超大型PR
Greptile信号率和趋势（如果有历史记录）："Greptile：X%信号率（Y次有效捕获，Z次误报）"

Focus & Highlights

专注度与亮点

(from Step 8)

Focus score with interpretation
Ship of the week callout

（来自步骤8）

专注度评分及解读
本周重点交付突出显示

Your Week (personal deep-dive)

你的一周（个人深度分析）

(from Step 9, for the current user only)

This is the section the user cares most about. Include:

Their personal commit count, LOC, test ratio
Their session patterns and peak hours
Their focus areas
Their biggest ship
What you did well (2-3 specific things anchored in commits)
Where to level up (1-2 specific, actionable suggestions)

（来自步骤9，仅针对当前用户）

这是用户最关心的部分。包含：

个人提交次数、代码行数、测试代码占比
个人会话模式和高峰时段
个人专注领域
个人最大交付
做得好的地方（2-3个基于提交的具体事项）
提升方向（1-2个具体、可操作的建议）

Team Breakdown

团队分解

(from Step 9, for each teammate — skip if solo repo)

For each teammate (sorted by commits descending), write a section:

（来自步骤9，针对每位队友——个人仓库时跳过）

为每位队友（按提交次数降序排序）撰写一个小节：

[Name]

[姓名]

What they shipped: 2-3 sentences on their contributions, areas of focus, and commit patterns
Praise: 1-2 specific things they did well, anchored in actual commits. Be genuine — what would you actually say in a 1:1? Examples:
- "Cleaned up the entire auth module in 3 small, reviewable PRs — textbook decomposition"
- "Added integration tests for every new endpoint, not just happy paths"
- "Fixed the N+1 query that was causing 2s load times on the dashboard"
Opportunity for growth: 1 specific, constructive suggestion. Frame as investment, not criticism. Examples:
- "Test coverage on the payment module is at 8% — worth investing in before the next feature lands on top of it"
- "3 of the 5 PRs were 800+ LOC — breaking these up would catch issues earlier and make review easier"
- "All commits land between 1-4am — sustainable pace matters for code quality long-term"

AI collaboration note: If many commits have

Co-Authored-By

AI trailers (e.g., Claude, Copilot), note the AI-assisted commit percentage as a team metric. Frame it neutrally — "N% of commits were AI-assisted" — without judgment.

交付内容：2-3句话介绍他们的贡献、专注领域和提交模式
表扬：1-2个基于实际提交的具体事项。要真诚——你在一对一对话中会实际说什么？例如：
- "用3个小型、易于审查的PR清理了整个认证模块——教科书级的工作分解"
- "为每个新端点添加了集成测试，不仅仅是正常流程"
- "修复了导致仪表板加载时间长达2秒的N+1查询问题"
成长机会：1个具体、建设性的建议。以投资的方式表述，而非批评。例如：
- "支付模块的测试覆盖率为8%——在该模块添加新功能之前值得投入时间提升"
- "5个PR中有3个超过800行代码——拆分这些PR可以更早发现问题，也让审查更容易"
- "所有提交都在凌晨1-4点完成——长期来看，可持续的节奏对代码质量很重要"

AI协作说明： 如果许多提交有

Co-Authored-By

AI尾注（例如Claude、Copilot），将AI辅助提交的百分比作为团队指标记录。中性表述——"N%的提交有AI辅助"——不做评判。

Top 3 Team Wins

团队三大成果

Identify the 3 highest-impact things shipped in the window across the whole team. For each:

What it was
Who shipped it
Why it matters (product/architecture impact)

识别整个团队在窗口内交付的3个影响最大的事项。每个事项包括：

内容是什么
谁交付的
重要性（产品/架构影响）

3 Things to Improve

三个改进方向

Specific, actionable, anchored in actual commits. Mix personal and team-level suggestions. Phrase as "to get even better, the team could..."

具体、可操作、基于实际提交的建议。混合个人和团队层面的建议。表述为"为了变得更好，团队可以..."

3 Habits for Next Week

下周三个习惯

Small, practical, realistic. Each must be something that takes <5 minutes to adopt. At least one should be team-oriented (e.g., "review each other's PRs same-day").

小而实用、可实现的习惯。每个习惯的 adoption 时间应少于5分钟。至少有一个是团队导向的（例如"当天完成彼此PR的审查"）。

Week-over-Week Trends

周同比趋势

(if applicable, from Step 10)

（如适用，来自步骤10）

Compare Mode

对比模式

When the user runs

/retro compare

(or

/retro compare 14d

Compute metrics for the current window (default 7d) using
```
--since="7 days ago"
```
Compute metrics for the immediately prior same-length window using both
```
--since
```
and
```
--until
```
to avoid overlap (e.g.,
```
--since="14 days ago" --until="7 days ago"
```
for a 7d window)
Show a side-by-side comparison table with deltas and arrows
Write a brief narrative highlighting the biggest improvements and regressions
Save only the current-window snapshot to
```
.context/retros/
```
(same as a normal retro run); do not persist the prior-window metrics.

当用户运行

/retro compare

（或

/retro compare 14d

）时：

使用
```
--since="7 days ago"
```
计算当前窗口的指标（默认7天）
使用
```
--since
```
和
```
--until
```
计算前一个相同长度窗口的指标，避免重叠（例如，7天窗口使用
```
--since="14 days ago" --until="7 days ago"
```
）
显示并排对比表，包含变化量和箭头
撰写简短叙事，突出最大的改进和倒退
仅将当前窗口的快照保存到
```
.context/retros/
```
（与正常回顾运行相同）；不要保留前一个窗口的指标。

Tone

语气

Encouraging but candid, no coddling
Specific and concrete — always anchor in actual commits/code
Skip generic praise ("great job!") — say exactly what was good and why
Frame improvements as leveling up, not criticism
Praise should feel like something you'd actually say in a 1:1 — specific, earned, genuine
Growth suggestions should feel like investment advice — "this is worth your time because..." not "you failed at..."
Never compare teammates against each other negatively. Each person's section stands on its own.
Keep total output around 3000-4500 words (slightly longer to accommodate team sections)
Use markdown tables and code blocks for data, prose for narrative
Output directly to the conversation — do NOT write to filesystem (except the
```
.context/retros/
```
JSON snapshot)

鼓励但坦诚，不敷衍
具体且有依据——始终基于实际提交/代码
跳过泛泛的表扬（"做得好！"）——具体说明好在哪里以及原因
将改进建议表述为提升机会，而非批评
表扬应像在一对一对话中实际说的那样——具体、真实、值得拥有
成长建议应像投资建议——"这值得你投入时间，因为..."而非"你在...方面失败了"
永远不要负面比较队友。每个人的小节独立存在。
总输出约3000-4500字（团队部分可适当延长）
使用markdown表格和代码块展示数据，用散文撰写叙事
直接输出到对话中——不要写入文件系统（除了
```
.context/retros/
```
JSON快照）

Important Rules

重要规则

ALL narrative output goes directly to the user in the conversation. The ONLY file written is the
```
.context/retros/
```
JSON snapshot.
Use
```
origin/<default>
```
for all git queries (not local main which may be stale)
Convert all timestamps to Pacific time for display (use
```
TZ=America/Los_Angeles
```
)
If the window has zero commits, say so and suggest a different window
Round LOC/hour to nearest 50
Treat merge commits as PR boundaries
Do not read CLAUDE.md or other docs — this skill is self-contained
On first run (no prior retros), skip comparison sections gracefully

所有叙事输出直接发送给用户的对话中。唯一写入的文件是
```
.context/retros/
```
JSON快照。
所有git查询使用
```
origin/<default>
```
（而非可能过时的本地main分支）
所有时间戳转换为太平洋时间显示（使用
```
TZ=America/Los_Angeles
```
）
如果窗口内没有提交，告知用户并建议使用其他窗口
将每小时代码行数四舍五入到最接近的50
将合并提交视为PR边界
不要读取CLAUDE.md或其他文档——此技能是自包含的
首次运行（无之前的回顾）时，优雅地跳过对比部分