brag-doc

An engineering brag doc that writes itself. Spend a couple of minutes a day logging what you shipped; when review season arrives, generate a promotion case or self-review draft from what you already wrote — in your employer's format or a portable one.

It's built as self-contained Claude Code skills that live in .claude/skills/, so the tooling travels with the journal: clone it anywhere, open Claude Code, and it just works. Inspired by "The Promotion Doc That Writes Itself".

Why

By the time your review comes around, you've forgotten half of what you shipped — and the half you remember is hard to turn into a convincing case. brag-doc fixes both ends: a low-effort daily habit captures the evidence while it's fresh, and a synthesis step turns months of entries into a strong first draft. You end up with a durable, queryable record of your impact instead of scrambling once a year.

Requirements

• Claude Code — both workflows are Claude Code skills. That's the only dependency; the output is plain Markdown you can paste anywhere.

How it works

1. Log your wins — daily, ~2 minutes. In Claude Code, from this repo:

/daily-eval

or just say "let's log today's wins." It asks a few quick questions and appends to entries/YYYY/MM/YYYY-MM-DD.md. Entries are append-only, so log as many times a day as you like; backfill a past day with /daily-eval 2026-07-01. See .claude/skills/daily-eval/examples/example-entry.md for what a day looks like.

2. Build review material — when you need it.

/review-builder company last-quarter   # your employer's format (see step 3)
/review-builder generic last-quarter    # portable, works anywhere

Drafts land in reviews/ (gitignored). The Markdown is the deliverable — paste it straight into Google Docs, Notion, or your HR tool. The draft is grounded in your entries — always read it over before submitting; it's advocacy material about you, and only as complete as what you've logged.

3. Point the company track at your employer — once. The company track mirrors your employer's real review form. This repo ships a fictional example at .claude/skills/review-builder/references/example-format.md — swap in your company's actual questions. If HR gives you a template PDF, drop it in sources/ (dated, e.g. sources/2026_perf_review_template_questions.pdf) and ask Claude: "update the company format from the template in sources/." Claude reads the PDF directly and rewrites the format doc to match. The generic track is employer-agnostic and never needs this.

The entries/ and sources/ shipped here are fictional sample data (a made-up company, "Globex," and made-up people) so you can see the workflow end to end. Delete them and start your own.

Keep the habit

Set a Slack reminder:

/remind me to log today's wins at 4pm every weekday

Layout

entries/    daily journal entries (source of truth; empty to start)
sources/    raw inputs: past reviews, manager feedback (sample here is fictional)
reviews/    generated drafts (gitignored)
.claude/skills/daily-eval/       capture skill
.claude/skills/review-builder/   synthesis skill

Privacy — read this before you use it for real

This repo is a public template, so everything in it is fictional. But once you start logging, your entries/ and sources/ will hold real names, manager feedback, and candid notes. Treat that as private:

• Do your real journaling in a private repo (fork this, or clone and re-point the remote to a private one). Don't push real entries to a public repo.
• Or, if you must keep your working copy public, uncomment the entries/ and sources/ lines in .gitignore so they never get committed (you lose version history of the journal, which is a real tradeoff — a private repo is the better option).
• Commits use whatever git identity you configure. Consider a GitHub noreply email so no personal address ends up in history.