I Built an AI Tool to Write My Brag Document

The Review Cycle Problem

Every six months, the same ritual. You sit down, open a blank document, and try to reconstruct what you accomplished. You scan through PRs, skim commit histories, and squint at Jira tickets trying to jog your memory. Half of it is gone. The stuff you remember is whatever happened in the last few weeks, not the critical fix you shipped four months ago.

Some people keep running brag documents. They write down wins as they happen. That’s great advice, and I’ve tried it. The problem is discipline. When you’re deep in a sprint, the last thing on your mind is updating a side document about how impactful your current work is. So the document stays empty until review season, and you’re back to square one.

Let Your Git History Tell the Story

The data already exists. Every PR you merged, every issue you closed, every code review you did – it’s all sitting in GitHub. The problem isn’t missing information. It’s that the information is scattered across dozens of repositories and hundreds of individual items with no narrative thread connecting them.

Reflect pulls that data together. It fetches your merged pull requests and closed issues, filters by date range, and feeds it all to an LLM that generates a coherent summary of your contributions. The output is a set of markdown documents – a detailed contribution log, a technical summary, and a professional achievement document ready for review season.

You point it at your GitHub activity, tell it how far back to look, and it does the rest. No manual curation. No forgetting that critical infrastructure migration you led in Q2.

What the Data Doesn’t Capture

Here’s the thing I feel strongly about: your impact extends far beyond what shows up in GitHub. Mentoring a junior engineer through their first production incident. Pushing back on a bad architectural decision in a meeting. Writing the design doc that aligned three teams. Facilitating a retro that actually changed how the team works. None of that generates a pull request.

Tanya Reilly calls this glue work – the work that holds teams together but rarely shows up in metrics. Reflect can summarize your code contributions, but the full picture of your impact requires your own voice. Use the generated document as a starting point, not the final draft.

Build the Tool You Wish You Had

The best developer tools come from scratching your own itch. You hit a friction point, you realize the data to solve it already exists, and you write something to bridge the gap. That’s exactly how git ai-commit happened – the staged diff already had everything needed for a good commit message, so I let an LLM write it.

Reflect follows the same pattern. The raw material for your brag document is already in GitHub’s API. The LLM just needs to read it and synthesize a narrative. The hardest part wasn’t the AI – it was deciding what filters, date ranges, and output formats would actually be useful during review prep.

If you hit a recurring pain point in your workflow, build the tool. Open source it. Someone else has the same problem.

Your GitHub history is a goldmine that most people only dig through once or twice a year. Stop doing it by hand.

This article was originally posted on LinkedIn.