Capture agent coding decisions for code review and team context
grepathy reads coding-agent session transcripts and writes the unapproved decisions it finds into a committed, git-tracked why file.
1.1.0Add to Favorites
Why it matters
Preserve the reasoning behind agent-written code by extracting decisions from coding-agent transcripts and committing them as reviewable markdown files in your repository, so reviewers, teammates, and future agents understand why code was written a certain way.
Outcomes
What it gets done
Extract design decisions and rationale from Claude Code session transcripts automatically
Generate branch-specific markdown files documenting agent-initiated changes and trade-offs
Inject relevant historical context to agents before they edit files with prior decisions
Flag agent decisions made without explicit approval for reviewer attention
Source
Get it from source
Spark does not host a copy of it.
Open sourceReports
Agent outcome reports
No reports yet
Overview
Grepathy
grepathy reads coding-agent session transcripts locally and commits the unapproved decisions it finds into a per-branch Markdown why file, injecting relevant entries back into future agents' context via a CLAUDE.md pointer and a PreToolUse hook. Use it to preserve agent decision reasoning that leaves no trace in the code before transcripts are deleted; it doesn't stop agents from removing important code or make them smarter in general.
What it does
grepathy makes agent-written code reviewable by reading coding-agent session transcripts locally, extracting the small decisions an agent made along the way, and writing them to a Markdown file (.ai/why/<branch>.md) that gets committed alongside the code. It exists because a coding agent routinely makes unapproved calls mid-task - transcripts that would explain them get deleted (Claude Code discards them after 30 days by default), so a reviewer later asking "why was this done this way" has no answer. Each extracted entry names its status (e.g. "agent-initiated - not requested in plan or prompts"), the files it touches, the agent's inferred reasoning, a stated risk, and what a reviewer should pay attention to - all greppable with a plain grep -rn "agent-initiated" .ai/why/.
It runs itself off hooks rather than being invoked directly: work normally with the agent, and on git push grepathy writes the why file and shows it for review before anything is pushed. It works strictly from the transcript after the fact - the team found that asking an agent to "log its decisions" mid-task simply doesn't work reliably. Future agents meet this context automatically through two triggers: a CLAUDE.md pointer auto-loaded every session, and a PreToolUse hook that injects the relevant why-pack entries right before an agent edits a file with a matching "Touches" glob.
When to use - and when NOT to
Use it to preserve reasoning before Claude Code's transcript retention window (30 days) deletes it, and specifically for knowledge that leaves no trace in the code itself - "we considered a CDN and rejected it," or an agent doing something on its own that nobody approved. The project's own published evaluation found agents given the why file got these right, while agents without it produced plausible-sounding wrong answers.
Don't expect it to stop an agent from refactoring away important code, or to make agents smarter in general - if an answer is readable from the code itself, agents already find it fine without grepathy; it only matters for what's written down nowhere else. For a fully private setup on a repo you don't want to commit anything to - a client's or an employer's - grepathy init --self-only keeps why-packs local, git-excluded, and never shared.
Inputs and outputs
Transcripts never leave your machine; only the Markdown summary is shared. The summarizer follows strict rules - it never quotes your messages, never describes confusion or back-and-forth, never includes business or money detail, and strips secrets - backed by two deterministic checks (a secret/finance scanner and a rule that every entry must point at real code) before you review the file yourself. Manual edits or deletions to an entry are respected permanently.
Integrations
npx grepathy init
Installs hooks and directories and offers to backfill still-alive old sessions; safe to re-run. Other commands: grepathy status/doctor (health checks), grepathy context <path> (entries applying to a file), grepathy sync (distill and commit immediately, still never pushes), and distill/repair/off/on/uninstall. Writing why-packs currently requires Claude Code; a Codex adapter is planned, and reading the resulting Markdown works with anything.
Who it's for
Teams shipping agent-written code who need PR reviewers, teammates, and future agents to be able to answer "why was this done this way" without digging through a deleted chat transcript.
grepathy is released under the MIT License.
Source README
Grepathy
Make agent-written code reviewable.
When a coding agent builds a feature, it makes a bunch of small decisions along the way that you never really approved. Later someone reviews the PR and asks "why was this done this way?" and you don't know. The answer is buried in a chat transcript on your laptop, and Claude Code deletes those after 30 days by default.
Grepathy reads your session transcripts locally, pulls out the decisions, and writes them to a markdown file that gets committed with your code. Now the repo can answer "why" on its own, for reviewers, teammates, and future agents.
npx grepathy init
What it looks like
Real example: on a contract project, my agent decided on its own to pre-create guest users in Clerk. It wasn't in any plan. The CTO saw it in the PR and asked me why. I had no idea, because I hadn't made that decision. With Grepathy, it would have been in the repo:
### Guest identities are pre-created in Clerk
Status: agent-initiated — not requested in plan or prompts
Touches: `lib/clerk/*`, `db/schema/guests.ts`
The agent inferred this approach to simplify downstream auth checks.
No explicit rationale was discussed.
Risk: guest users diverge from the normal signup path.
Reviewer attention: confirm whether guests should be modeled as normal users.
Run grep -rn "agent-initiated" .ai/why/ and you get a list of every decision the agent made without asking anyone.
How it works
You don't run Grepathy. It runs itself off hooks:
claude # work normally, let the agent commit as it goes
git push # Grepathy writes the why file and shows it to you for review
A few things worth knowing:
- It works from the transcript after the fact. It never asks the agent to "log its decisions" mid-task (we tried that first, agents just don't do it).
- Each branch gets one file:
.ai/why/<branch>.md. - Future agents actually see this stuff. A note in
CLAUDE.mdpoints them at the why files, and a hook injects the relevant entries right before an agent edits a file that has history. - It never blocks a push, never touches your staging area, and never pushes anything itself. It plays fine with multiple agents and worktrees.
How a future agent meets the why - two automatic triggers, both reading from the committed why-pack, so the agent never has to remember to go look:
flowchart TD
why[("the why-pack<br/>(.ai/why/, committed)")]
claude["CLAUDE.md pointer<br/>auto-loaded every session"]
hook["PreToolUse hook<br/>fires right before an edit"]
claude -->|"why / explain / review"| read["agent reads<br/>the why-pack"]
hook -->|"edited file matches a Touches: glob"| inject["matching entries injected<br/>into the agent's context"]
why -.-> read
why -.-> inject
read --> meets["✅ agent meets the reasoning<br/>before it changes the code"]
inject --> meets
No server, no accounts, no bot. It's a CLI, some hooks, and markdown files in git. Full detail in docs/how-it-works.md.
What it's good for (we actually tested this)
We ran a blind, pre-registered eval against an honest baseline and published the whole thing, including the parts where the tool lost: docs/REPORT.md.
Where it helps:
- Saving reasoning before it's deleted. Claude Code throws away transcripts after 30 days. Two of our own projects lost their entire history before we could even run the eval.
grepathy initoffers to backfill whatever is still alive. - Knowledge that isn't in the code. Things like "we considered a CDN and rejected it" or "the agent did this on its own, nobody approved it" leave no trace in the code. In our tests, agents with the why file got these right. Agents without it made up plausible-sounding wrong answers.
Where it doesn't help, honestly:
- It won't stop an agent from refactoring away important code. We tested that directly and it didn't.
- It doesn't make agents smarter in general. If the answer is readable from the code, agents find it fine on their own. Grepathy only matters for the stuff that's written down nowhere else.
Commands
| Command | Purpose |
|---|---|
grepathy init |
Install hooks and dirs. Safe to re-run. Offers to backfill old sessions. Add --self-only for a private, never-committed setup. |
grepathy status / doctor |
Health checks, what's distilled, what's stale. |
grepathy context <path> |
Show the entries that apply to a file. |
grepathy sync |
Distill and commit right now (still never pushes). |
grepathy distill / repair / off / on / uninstall |
The rest. --help for details. |
FAQ
How is this different from Beads and the task-tracker tools?
Those track what agents should do next. Grepathy records why things were already done. You could use both.
Why not just turn off transcript deletion?
You can, but then you have gigabytes of raw chat logs on one laptop that you'd never share with anyone. The why file is small, safe to share, and lives in the repo where your team and their agents can actually find it.
Does it work with tools other than Claude Code?
Anything can read the why files, since they're just markdown. Writing them currently requires Claude Code. A Codex adapter is next.
Where are the deep dives?
Architecture and git behavior · why-pack format · parallel agents · config
Development
npm install
npm run build # tsc -> dist/
npm test # compiles src + test, runs the node:test suite
Zero runtime dependencies; pure TypeScript. The test suite is hermetic - no Claude, API key, or network needed (the LLM is mocked, git runs in throwaway temp repos) - so npm test runs anywhere with Node >= 20 and git. It covers transcript parsing, why-pack merge and human-edit preservation, semantic dedupe, the privacy/secret/finance validator, per-session state and concurrency locking, branch attribution, and the scratch-index auto-commit. See CONTRIBUTING.md. The write-side adapter and read-side pointer/hook pattern are both per-tool seams designed to make a new tool (e.g. Codex) a small addition.
FAQ
Common questions
Discussion
Questions & comments · 0
Sign In Sign in to leave a comment.