gstack Engineering Retrospective: Your AI Engineering Manager

What Is gstack Engineering Retrospective?

The gstack engineering retrospective is powered by the /retro skill, which functions as an AI engineering manager for your codebase. It mines your Git history, computes hard metrics, and produces a candid retrospective that reads like feedback from a thoughtful senior leader -- the kind of feedback you would actually give in a 1:1. No templated platitudes, no vague commentary. Every observation is backed by data pulled directly from your commit log, diff stats, and timestamp patterns.

Traditional engineering retrospectives suffer from recency bias, social dynamics, and the simple problem that nobody remembers what happened two weeks ago. The /retro skill solves this by treating your Git history as the single source of truth. It reads every commit, measures every diff, and produces a structured narrative that covers what shipped, who contributed what, where the team is accelerating, and where friction is building up.

This is not a dashboard or a chart generator. The gstack engineering retrospective produces written analysis -- paragraphs of context-aware commentary that connect the numbers to the narrative. It identifies your biggest ship of the week, calls out shipping streaks, flags hotspot files that keep accumulating changes, and gives each contributor specific praise alongside specific growth opportunities.

How the /retro Skill Works

The gstack engineering retrospective follows a systematic pipeline to transform raw Git data into actionable feedback. Here is how the analysis unfolds when you run /retro:

1. Identity detection -- The skill identifies who is running the command from Git configuration. This matters because the retrospective gives the deepest treatment to your own work, while still covering the full team.
2. Commit history ingestion -- Every commit in the analysis window is parsed for author, timestamp, message, file paths, insertions, and deletions.
3. Metric computation -- Raw data is transformed into meaningful metrics: total commits, lines of code changed, test-to-production code ratio, average PR size, fix ratio (how many commits are bug fixes vs. new features), and more.
4. Session detection -- Commit timestamps are analyzed to identify coding sessions. Clusters of commits within short time windows reveal focused work blocks, while gaps indicate context switches or breaks.
5. Pattern recognition -- The skill identifies hotspot files (files that keep getting modified), shipping streaks (consecutive days with commits), peak coding hours, and the biggest ship of the week.
6. Narrative generation -- All metrics and patterns feed into a written retrospective with per-contributor breakdowns, specific praise, and growth opportunities.
7. Snapshot persistence -- A JSON snapshot of all computed metrics is saved to .context/retros/ for trend tracking over time.

Metrics the Retrospective Computes

The gstack engineering retrospective goes well beyond simple commit counts. Here is the full set of metrics it computes for each contributor and for the team as a whole:

Coding Session Detection

One of the more sophisticated features of the gstack engineering retrospective is its ability to detect coding sessions from commit timestamps. Rather than treating each commit as an isolated event, the skill clusters commits that occur within short time windows into sessions. A burst of five commits over 45 minutes tells a very different story than five commits spread across five days.

Session detection reveals patterns that raw commit counts cannot: deep focus blocks where someone shipped significant work uninterrupted, fragmented days where context switching dominated, and late-night sessions that might signal deadline pressure or poor estimation. This temporal analysis adds a dimension of insight that traditional retrospective tools completely miss.

Hotspot File Analysis

The retrospective tracks which files accumulate the most changes over the analysis period. These hotspot files often indicate areas of active development, but they can also signal architectural problems. A file that gets modified in every other commit might be doing too much. A configuration file that keeps changing might indicate an environment management issue. The /retro skill surfaces these patterns so the team can discuss whether the churn is healthy or symptomatic.

Team-Aware Per-Contributor Breakdowns

The gstack engineering retrospective is team-aware by design. It identifies who is running the command and structures the output accordingly. Your own work gets the deepest treatment -- detailed session analysis, specific file-level observations, and candid growth feedback. Other contributors get concise but meaningful summaries with their own praise and growth areas.

Each per-contributor section includes:

• Specific praise -- Not generic "good job" statements, but observations tied to actual work. "You shipped the new authentication flow in a single focused session on Tuesday, with tests covering all edge cases" is the level of specificity you get.
• Growth opportunities -- Again, tied to data. "Your average PR size this week was 847 lines -- consider breaking the dashboard refactor into smaller, reviewable chunks" gives the contributor something concrete to act on.
• Contribution profile -- Commits, LOC, test ratio, and peak hours for the period. A quick numerical summary that contextualizes the narrative feedback.
• Biggest ship -- The single most significant contribution from each team member, identified by analyzing commit message content and diff size together.

Running Your First Retrospective

If you have gstack installed, running a retrospective is a single command. The /retro skill is part of the core skills catalog and requires no additional configuration.

# Run a standard weekly retrospective
/retro

# Compare this week vs. last week side by side
/retro compare

The default /retro command analyzes the current week's activity. It scans every commit in the time window, computes all metrics, and generates the full retrospective narrative. Output is written directly to your terminal in a structured, readable format.

The /retro compare Command

The /retro compare variant is where the gstack engineering retrospective becomes especially powerful. It loads the saved JSON snapshot from the previous week (stored in .context/retros/) and places it side by side with the current week's data. You get delta comparisons on every metric: commit count up or down, test ratio improving or declining, PR sizes growing or shrinking, shipping streaks extending or breaking.

This week-over-week comparison transforms the retrospective from a point-in-time snapshot into a trend analysis tool. You can see whether last week's growth feedback led to measurable change, whether shipping velocity is accelerating or decelerating, and whether the team's work patterns are sustainable over time.

# Example output structure from /retro compare
# -----------------------------------------------
# This Week vs Last Week
# -----------------------------------------------
# Commits:        47 (+12, +34%)
# LOC Changed:    2,841 (-523, -16%)
# Test Ratio:     0.31 (+0.08)
# Avg PR Size:    184 lines (-67 lines)
# Fix Ratio:      18% (-5%)
# Shipping Streak: 5 days (continuing)

JSON Snapshots and Trend Tracking

Every time you run /retro, the skill saves a JSON snapshot of all computed metrics to .context/retros/. This is not just for the compare command. Over time, these snapshots build a longitudinal dataset of your team's engineering patterns.

The snapshot includes every metric mentioned above, plus raw data like per-file change counts, session timestamps, and contributor-level breakdowns. Teams that commit the .context/ directory to their repository get a permanent record of engineering health metrics that can be referenced in planning sessions, performance reviews, or post-mortems.

This persistence layer is what separates the gstack engineering retrospective from ad-hoc Git analysis scripts. A one-time analysis tells you where you are. A series of snapshots tells you where you are heading.

Greptile Batting Average Tracking

For teams using the Greptile code review integration, the gstack engineering retrospective includes a unique metric: Greptile's batting average. This tracks the percentage of Greptile-generated review comments that led to actual code changes versus comments that were dismissed or ignored.

Over time, this batting average reveals whether your AI code review setup is well-calibrated. A high batting average means Greptile is catching real issues. A declining batting average might indicate that the review rules need tuning, or that the codebase has evolved past the current configuration. Either way, the retrospective surfaces the trend so you can act on it.

Biggest Ship of the Week

Every gstack engineering retrospective identifies the single biggest ship of the week across the entire team. This is determined by analyzing a combination of diff size, commit message content, and the number of files touched. A sprawling refactor that touches 40 files might be the biggest ship by volume, but a surgical three-file change that introduces a critical new feature could rank higher based on commit message analysis.

Calling out the biggest ship serves two purposes. First, it gives the team a shared sense of what the most impactful work was -- useful context for anyone who was heads-down on their own tasks. Second, it creates a lightweight recognition mechanism. Seeing your work highlighted as the biggest ship of the week is the kind of specific, earned recognition that actually motivates engineers.

Peak Hours and Work Pattern Analysis

The /retro skill detects each contributor's peak coding hours by building a histogram of commit timestamps. This analysis reveals when each person does their best work and can surface potential concerns about work-life balance.

A contributor whose peak hours shifted from 10am-2pm to 10pm-2am over the course of a month might be dealing with deadline pressure, scope creep, or personal circumstances that are affecting their schedule. The retrospective does not make judgments about this -- it surfaces the data so that engineering managers can have informed conversations.

Peak hours data also has practical applications for team coordination. If two contributors who frequently collaborate have non-overlapping peak hours, that friction is worth knowing about. The parallel AI coding architecture can help mitigate some of this by enabling asynchronous collaboration through isolated workspaces, but human coordination still matters.

How /retro Fits Into Your Workflow

The gstack engineering retrospective is designed to slot into existing engineering rhythms without adding ceremony. Here are the most common integration patterns:

Weekly Team Retros

Run /retro at the start of your weekly retrospective meeting. Instead of spending 15 minutes trying to remember what happened, start with the data already compiled. The team can jump straight into discussion about the patterns and trends the retrospective surfaces.

Sprint Reviews

Use /retro compare at the end of each sprint to see how the current sprint compared to the previous one. This gives product and engineering leadership a quantitative view of team velocity and health alongside the qualitative demo of shipped features.

1:1 Preparation

Engineering managers can run /retro before 1:1 meetings to prepare data-backed talking points. Instead of relying on memory or scanning Jira tickets, you walk into the conversation with specific observations about the contributor's recent work patterns, shipping velocity, and code quality metrics.

Self-Assessment

Individual contributors can run /retro on their own to get an honest assessment of their recent work. Because the skill gives the deepest treatment to the person running it, this becomes a powerful self-reflection tool. Am I writing enough tests? Are my PRs too large? Have I been shipping consistently or in bursts?

What Makes This Different From Git Analytics Tools

There is no shortage of Git analytics dashboards on the market. Tools like LinearB, Sleuth, Swarmia, and others produce charts and metrics from repository data. The gstack engineering retrospective differs in three fundamental ways:

• Written narrative, not dashboards -- Charts require interpretation. The /retro skill produces written analysis that connects metrics to meaning. You get paragraphs that explain what the numbers indicate, not just the numbers themselves.
• Runs locally in your terminal -- No SaaS subscription, no data leaving your machine, no waiting for a dashboard to load. The retrospective runs on your local Git history and produces output in seconds.
• Per-person calibration -- Because the skill knows who is running it, the output is calibrated to be most useful to that person. An IC gets detailed self-assessment. A manager gets team-wide patterns with per-contributor breakdowns. The same data, different lens.
• Integrated with the gstack ecosystem -- The retrospective feeds into and draws from other gstack skills. Greptile batting average, shipping workflow patterns, and code review data all contribute to a more complete picture than any standalone analytics tool can provide.

Privacy and Data Handling

The gstack engineering retrospective runs entirely on your local machine. It reads from your local Git repository and writes snapshots to the local .context/retros/ directory. No commit data, contributor names, or metrics are sent to any external service. The analysis happens in-process, and the output stays on your disk.

This local-first approach means the retrospective is safe to use on proprietary codebases, in regulated industries, and in organizations with strict data handling policies. The JSON snapshots in .context/retros/ are plain text files that you can inspect, edit, or delete at any time.

Getting Started

If you have gstack installed and configured, the /retro skill is ready to use. Navigate to any Git repository and run /retro to generate your first engineering retrospective. The skill works best with at least a week of commit history, but it will produce useful output from any non-empty repository.

For teams that want to establish a trend tracking baseline, run /retro once this week and again next week. The second run with /retro compare will show your first week-over-week comparison, and from there, each subsequent run builds on the historical data.

# Generate your first retrospective
/retro

# Next week, compare against the baseline
/retro compare

# JSON snapshots accumulate in .context/retros/
ls .context/retros/
# retro-2026-03-09.json
# retro-2026-03-16.json