agentleFS
agentkitcoagentkitco/agentkit-dev-skills/skills/brag-doc-from-git/SKILL.md

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.

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
  1. Distinctive:

    Ask for the time window (default: the last 6 months) and the repositories.

    line 16
  2. Distinctive:

    Do not read private repositories the user did not name.

    line 24
  3. Very specific:

    Result: only if a number, quote or outcome was provided.

    line 35
  4. Distinctive:

    Never invent metrics, percentages, customer names, titles or scope.

    line 45
  5. Distinctive:

    Do not inflate: "contributed to" stays "contributed to".

    line 46
  6. Distinctive:

    Keep the user's credit honest: if a PR was a team effort, say what part was theirs.

    line 47
  7. Distinctive:

    Keep private or confidential details out unless the user says the document is internal.

    line 48

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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 200

For 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.