brag-doc-from-git
Skill0 starsChanged 14 days agoMITView on GitHub
Build an evidence-based brag doc or self-review draft from your merged PRs and commits, leaving visible gaps where results are unknown. Use for review season, promotion cases or resumes.
In this repository12 other files it gives its agents.
- agents-md-auditSkill
- dependency-upgradeSkill
- explain-codebaseSkill
- pr-descriptionSkill
- prove-it-ranSkill
- repro-first-debuggingSkill
- review-my-diffSkill
- safe-refactorSkill
- security-quick-reviewSkill
- session-handoffSkill
- write-agents-mdSkill
- write-subagentSkill
The file
We split this skill into the rules it gives an agent
7 rules. About 0 are common, 6 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈6
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Ask for the time window (default: the last 6 months) and the repositories.
- Distinctive: line 24
Do not read private repositories the user did not name.
- Very specific: line 35
Result: only if a number, quote or outcome was provided.
- Distinctive: line 45
Never invent metrics, percentages, customer names, titles or scope.
- Distinctive: line 46
Do not inflate: "contributed to" stays "contributed to".
- Distinctive: line 47
Keep the user's credit honest: if a PR was a team effort, say what part was theirs.
- Distinctive: line 48
Keep private or confidential details out unless the user says the document is internal.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Brag document from git history
Goal: turn what you actually shipped into a draft you can edit, without inventing impact. A brag document lists work and results; this skill collects the work and marks every missing result as a gap for you to fill.
Step 1: collect the evidence
Ask for the time window (default: the last 6 months) and the repositories. Then, with the GitHub CLI signed in:
gh search prs --author @me --merged --merged-at ">=YYYY-MM-DD" --json title,url,closedAt,repository --limit 200For code not on GitHub, use git log --author="<name or email>" --since="YYYY-MM-DD" --no-merges --pretty="%h %ad %s" --date=short in each repository. Also ask the user to paste anything git cannot show: incidents handled, mentoring, reviews done, talks, docs, on-call, design decisions, kind words from colleagues.
Do not read private repositories the user did not name. Do not guess names, teams or numbers.
Step 2: group, do not summarize yet
Group the items into themes (for example: reliability, new features, performance, tooling, mentoring, cross-team work). List each item under its theme with date and link. Merge duplicates (a feature PR plus its follow-up fixes).
Step 3: draft each theme
For every theme write:
- What I did: one or two sentences in plain verbs, using only what the titles, diffs and user notes support.
- Result: only if a number, quote or outcome was provided. Otherwise write
[GAP: what changed for users or the team? any metric before/after?]. - Evidence: links.
- Scope signal (if supported): led it, did it alone, worked across teams, was on call, reviewed others.
Step 4: finish with gaps and questions
End with a list of every [GAP], ranked by how much it would strengthen the case, and the three questions whose answers would add the most. Offer to turn the final version into a self-review, a promotion packet outline or resume bullets.
Rules
- Never invent metrics, percentages, customer names, titles or scope. A visible gap is better than a made-up number.
- Do not inflate: "contributed to" stays "contributed to". Match verbs to the evidence.
- Keep the user's credit honest: if a PR was a team effort, say what part was theirs.
- Keep private or confidential details out unless the user says the document is internal.
- Output Markdown the user can paste into their notes.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

