How askScout turns a noisy git log into a 10-second digest

Why git log fails at AI-coding pace

git log works fine when you write a handful of clean commits a day with messages you wrote yourself. At AI-assisted pace, with auto-generated messages like fix and wip, the format stops being useful. The output doesn't scale to the volume.

The fix isn't a better git command. It's a layer on top of git that does what humans used to do at lower volume: read it and summarize it. askScout is that layer. Here's how it works. (For the bigger argument behind why this layer matters now, the hidden cost of vibe coding walks through the problem, and Introducing askScout sets the table.)

Step 1: Read commits and diffs

On the web app, askScout pulls commits and diffs through the GitHub REST API after you grant read-only access. On the CLI, it calls git directly in your local repo to pull the same data, with --week for the past 7 days. Either path fetches commits since your last run by default.

What gets read on the web app:

• Commit messages, timestamps, authors, file paths.
• The actual diff patches (the lines added and removed in each commit).
• Pull request titles and descriptions, plus the titles and bodies of any GitHub issues those PRs reference, so the digest can ground itself in the stated intent behind each change.
• For up to the 8 most-changed files, ~15 lines of surrounding source code around each changed hunk so refactors and sparse edits can be read in context.
• The repository's README and a single project manifest (one of package.json, pyproject.toml, Cargo.toml, go.mod, composer.json, or Gemfile), so the model can frame every diff against the actual project.

What doesn't get read: full source files outside the changed regions, environment variables, secrets, lock files, build artifacts, and untracked files. The CLI reads the same data minus the PR and issue context, because git itself doesn't store that.

Step 2: Compute structural signals

Before any LLM gets involved, askScout computes two things from the raw data: the Codebase Health card and the Pace Check.

Codebase Health is three measurements. Growth is the ratio of lines added to lines removed, classified from Lean up through Ballooning. Focus looks at the average files touched per commit, running from Tight to Scattered. Churn counts how many files were reworked three or more times in the window, on a Clean-to-High scale. All three come from arithmetic, not LLM judgment.

Pace Check compares today's commit count to the average of your last three runs. It only renders after you have at least 3 prior digests, so the baseline is real. The multiplier (e.g. 1.7x) is straight division.

Doing the math instead of asking the model makes these numbers exact and easy to audit.

Step 3: Feed real data into a tuned prompt

The LLM only writes the narrative parts: Vibe Check, the bullet sections, and Key Takeaways. Everything structural is already done. The prompt grounds the model in the actual commit messages and diffs, so it cannot invent work that did not happen.

The prompt has strict editorial constraints. Banned phrases like “great work” and “leveraged.” A required format for bullets: Title - body with 2-5 plain-language words in the title. No file paths or function names in summaries (the model translates everything to features and behaviors). No em dashes, no semicolons. The full constraint list is open source. See Why we made askScout open source for why we publish it.

The point of the constraints is voice. Without them, the LLM defaults to changelog English: passive and vague. The constraints force it into the voice of a sharp, warm friend who actually looked at the code.

Step 4: Render in plain English

The output gets rendered with emoji section headers (or bracketed plain text when stdout is piped or NO_COLOR is set). Bullets use the • character in rich mode and - in pipes. Stats lines use proper unicode separators.

That is everything. Read commits, compute signals, prompt the LLM with real data and tight constraints, render the output. The whole pipeline runs in well under a minute for typical repos, with most of that time spent waiting on the model. Install the CLI in your own repo via the CLI docs to watch it run end-to-end.

Before and after

Raw git log:

a1b2c3d wip
b4c5d6e fix
c7d8e9f update auth
d0e1f2a wip again
e3f4a5b add tests
f6a7b8c fix tests

askScout output for the same window:

🚀  Shipped  2

  •  Auth flow lands
     Users can sign in with email + password. Sessions persist
     across reloads, and the rate-limit banner finally renders
     correctly.

  •  Test harness for auth
     Six new integration tests cover sign-in, sign-out, and
     token refresh. CI is now blocking on auth regressions.


📍  Left Off  1

  •  Edge case in token refresh
     Refresh works on long-lived sessions but throws when the
     token has been revoked server-side. Next step is wiring up
     the 401 path to a clean re-auth.

Both views describe the same six commits. One is illegible at scale. The other you can read on your phone in a coffee line. (For how this fits next to the other options developers actually use, see the five real ways to track what you shipped.)