I Fed an Agent My Git Log — and It Wrote Half My Brag Doc for Me

Day 8 — The Brag Doc That Writes Itself

Everyone starts a brag doc. Almost nobody still has one three months later, which is exactly when a promo committee asks for it. Here's the fix that actually stuck.

The June gap

Try this: open your brag doc in September and scroll back to June. For most people that section is empty. Not because June was quiet — usually the opposite. A migration shipped. Something broke in prod and got patched at 2am. You won an argument about a design that mattered. None of it got written down at the time, and by September your brain has nothing left to hand you. You know you did something. You just can't say what, or why anyone should care.

Why this always happens

Brag docs don't die because engineers stop caring about their careers. They die because the doc depends on memory, and memory is a leaky bucket — sharp today, fuzzy in a week, gone in a month. Nobody forgets to care about documenting their work. They forget to log it while the context is still warm and the reasoning still feels obvious. A week later the code is still sitting right there in the repo, but the 'why' behind it has already left the building.

• ▹Motivation was never the bottleneck — recall is. You don't need more discipline, you need a system that doesn't ask you to remember anything.
• ▹The evidence is already sitting in git log and your PR history. What's missing is someone, or something, turning it into prose on a schedule.
• ▹Same failure mode as standups without notes or 1:1s without an agenda doc — anything that leans on unaided human memory under time pressure rots fast.

The fix I didn't expect

I stopped trying to remember and pointed an agent at the raw record instead. Handed it my git log and PR descriptions for June and asked one blunt question: what did I actually do this month? It read commit messages, PR titles, and diffs, and spat out a rough but real list — not polished brag-doc prose, just a factual skeleton I could correct instead of writing from a blank page.

Prompt I used:
"Here's my git log and merged PR list for June (repo: payments-service).
Summarize what I shipped, grouped by week.
For each item: what changed, and which files/services it touched.
Don't editorialize on impact — just report what the commits/PRs show."

What the agent got wrong and right

On the mechanical layer, it was strong: features shipped, PRs merged, files touched, rough scope of each change. That's all sitting right there in git history, legible to anyone who bothers to look. Where it fell apart was the part that actually sells a brag doc — the judgment calls. It could tell me I'd rewritten the retry logic in the payments queue. It could not tell me I'd picked exponential backoff over a dead-letter queue because on-call was already stretched thin that sprint. That decision is the actual brag-worthy content, and commits almost never show what you rejected and why.

• ▹Agent strength: exhaustive, unbiased recall of what happened — no memory decay, no bias toward whatever you did last week.
• ▹Agent blindness: the counterfactual. The option you didn't take, and the reason you didn't. That lives in your head or a Slack thread, never in the diff.
• ▹Your job shrinks down to: read the draft, add one sentence of 'why', keep or toss.

The new ritual

Five minutes, every Friday, no exceptions. That's the entire loop:

• ▹Agent pulls the week's commits and merged PRs (git log + gh pr list, or whatever your review tool exposes) and drafts 3-6 bullet entries.
• ▹You skim it. Most entries get deleted — routine work, nothing to brag about — or kept as-is.
• ▹For the one or two entries that involved a real decision, you add the line the agent could never write: 'chose X over Y because Z.'
• ▹Paste the survivors into the running brag doc. Done. This isn't a writing exercise — it's an editing exercise.

What this buys you by Day 30

By the end of this series you'll have a document built out of evidence, not out of a stressful hour of memory reconstruction the week before your perf review. It's the same document you hand to a promo committee, to a new manager who doesn't know your history yet, or to future-you deciding whether to finally ask for the title change. What's different from a normal brag doc isn't the format. It's that every single entry has a receipt behind it.

One-line takeaway to carry into Day 9

If a habit depends on remembering, don't try to get more disciplined about it — automate the remembering, and save your discipline for the judgment calls only you can make.

Extend your knowledge

• ▹Try the exact prompt from this lesson on your own repo's last month of commits and see what the agent misses — that gap is exactly the judgment-call content worth adding by hand.
• ▹Julia Evans' writing on brag docs is a good primer on why the practice exists and what a good entry looks like, if you want the non-agent-assisted baseline first.
• ▹Set up a recurring Friday check using this series' automation tools (a scheduled agent run or the /loop skill) so the draft shows up without you having to remember to ask for it.
• ▹Compare a month of agent-drafted entries against your actual performance review self-assessment — see how much of what you'd normally forget shows up.