A brag document is a running list of what you accomplished, kept while you still remember the details. Julia Evans popularized the idea for engineers, and it's the single most useful thing you can bring to a performance review. This template is built for how engineers work now, including work done with coding agents.
The template
Copy this into your notes app. It's plain Markdown, so it pastes cleanly into Notion, Obsidian, or Google Docs with Markdown turned on.
# Brag document: [Your name], [Period, e.g. Q3 2026]
## Goals for this period
- [What you and your manager agreed mattered most]
## Shipped
### [Project or feature name]
- **What:** [One or two sentences on what you built]
- **Why it mattered:** [The problem it solved, for whom]
- **Impact:** [A real number if you have one: users, revenue, latency, incidents, time saved]
- **Evidence:** [PR links, dashboards, the doc or thread where it was discussed]
## Decisions and judgment
- [A tradeoff you made and why. "Chose X over Y because Z" is the strongest line in a review]
## Work that didn't ship (but mattered)
- [Investigations, prototypes you killed, approaches you ruled out, and what they taught the team]
## Helping others
- [Reviews, mentoring, docs, onboarding, unblocking someone]
## Incidents and fixes
- [What broke, what you did, what changed so it won't happen again]
## What I learned
- [Skills, tools, domains]
## Next period
- [What you want to take on, and what support you need]How to fill it so it holds up
- Write the why, not just the what. "Built the webhook retry queue" is a task. "Built a retry queue after we lost 212 payment events to a 30 second timeout" is an accomplishment.
- Only use numbers you can defend. Leave
[add impact: ...]as a gap until you have the real figure. A vague claim is weak; an invented number is worse. - Keep the decisions section full. Senior engineers are judged on judgment. Your coding sessions are full of it: every "let's try X instead" is a decision with a reason.
- Include work that didn't ship. Ruling out three approaches in a week is real work, and it's invisible in git.
- Update it weekly. Ten minutes on Friday beats three hours of archaeology the week before reviews.
Filling it from your Claude Code sessions
If you build with Claude Code, you already have a detailed record of what you did and why: every prompt you typed is in ~/.claude/history.jsonl, and full transcripts are in ~/.claude/projects. How to write a brag doc from your Claude Code work walks through turning a quarter of sessions into this template, with a prompt that refuses to invent numbers.
Shabash does it for you: pick a period and the projects to include, and it drafts your brag doc in this shape, with every line linked to the session or commit behind it and gaps left for your own numbers and words.