BuildGist

How do I explain a Claude Code session to a teammate or a non-technical person?

Kayvan Zahiri ·

Tell them what you asked for, what someone using the product can do now that they could not before, what isn't done yet, and what still needs checking. Take those from the diff and the test results, not from the chat. A teammate who reads code also gets the files and the place to look first. Someone who doesn't read code gets no file names, just what changed for people and what could go wrong.

BuildGist is a Mac app for Claude Code, Cursor and Codex. Download for Mac.

If they ask what a session is

Claude Code's documentation calls a session "a saved conversation tied to a project directory" (checked November 3, 2026). In plain words: you asked for something in a chat, and Claude Code read files in the project, ran commands and changed files to do it. Closing the chat undoes nothing. The changes stay in the folder until someone keeps or reverts them, and claude --resume reopens the conversation later.

Get the facts before you explain

  1. Reread your own request. Everything else is measured against it.
  2. Run git status and git diff --stat for the files and the size of each change. Committed work is covered in what did Claude Code change?
  3. Note which tests ran and whether they passed. If none ran, say so.
  4. Find anything it did past the request, and anything it left undone.

Claude Code's own summary is a fine start. It is what the agent believes it did, so check it against the diff first.

For a teammate who reads code

They want enough to review the work without rereading the chat. The six-line template in how to understand code your AI coding agent wrote fits a pull request or a chat message. Two more things help a reviewer:

For a pull request, see turn a session into a PR description.

For someone who doesn't read code

A manager or a client wants to know what changed for the people who use the product, whether it is finished, and what could go wrong. Four lines usually do it:

Now you can: (what a user can do that they could not before)
Not done yet: (what was left for later, and whether that was planned)
Checked: (what was tested, in plain words)
Before we rely on it: (the one thing still to confirm, said as what could happen)

A few habits keep it plain:

One session, explained twice

On BuildGist's public sample run, a developer asked Claude Code to add share links to a notes app, write tests and run them, and to leave link expiry for later. BuildGist recorded 3 files changed (+46 −2) and 7 tests passing.

For a teammate:

Asked for: share links for notes, with tests; expiry later
Files changed: app.py, test_app.py, README.md (+46 −2)
Now a user can: open a note's share link and read that note
Past the request: a README line listing the new endpoints
Check before merging: how the share token is made (that line is masked in the excerpt)
Open questions: should deleting a note clear its share token?

For a manager:

Now you can: share a note by sending a link. Anyone with the link can read it.
Not done yet: links don't expire. That was planned as the next step.
Checked: seven automatic checks passed, four of them new, for share links.
Before we rely on it: confirm the secret part of each link is hard to guess,
or someone could read notes they were never given.

Same session, same facts. Only the words change.

Where BuildGist fits

After each meaningful run of Claude Code, Cursor or Codex, BuildGist writes the explanation and puts it in your Inbox: what changed, what it means and any concerns, under BuildGist's own record of the request, the files and the tests. Each explanation has three reading levels: Simple, Developer and Senior. Simple leaves out code names and file paths, so it is a good first draft of the message for someone who doesn't read code. The sample run opens at Simple. BuildGist doesn't send explanations to anyone, so copy the lines you need. Explanations are written by AI, so check important behavior against the code and tests.

Questions

Should I send them the whole transcript?

Not first. A transcript is long and full of steps that were tried and dropped. Send the short version, and the /export transcript if they ask.

Can Claude Code write the summary for me?

Yes. Before you close the session, ask: "In plain English, for someone who doesn't read code, what can a user do now, what isn't done, and what should we check?" Then compare the answer with git diff --stat and the test results before you send it.

Does this work for Cursor and Codex sessions?

Yes. The facts come from Git and the tests, which are the same whichever agent made the change. BuildGist explains runs from all three in one Inbox.

Sources

What you need

Codex needs you to approve BuildGist once, in Codex. BuildGist shows the steps. Setup is in Getting started.

To explain a run, your computer sends BuildGist what that run needs, and BuildGist passes it to Anthropic. BuildGist does not keep this material. It does not send your whole repository, files the run did not change, or files named like secrets, such as .env files and keys. It keeps the explanation and short cited excerpts of changed code, at most 12 lines each. Secret masking is best-effort. Privacy has the full list.

Every account gets 7 days of BuildGist Pro free, with no card. The 7 days start at your first explanation or Continue handoff. Nobody is charged when the trial ends. After that, BuildGist Pro is $12 per month, plus any applicable tax shown at checkout. See pricing.

Try BuildGist Download for Mac

No Mac handy? Try it in your browser: paste a session or a git diff and see the explanation.

Apple silicon, macOS 12 or later. United States, 18 or older.

Related

Questions: kayvanandre@gmail.com.