brag-sheet

Name: brag-sheet
Author: github

37kstars4.6kforks

How to install brag-sheet?

github/awesome-copilot/brag-sheet

$npx -y skills add github/awesome-copilot --skill brag-sheet

Installs into the current project.

Summary

Turn vague "what did I do?" into evidence-backed impact statements for performance reviews, self-reviews, promotion packets, and weekly updates. Uniquely mines Copilot CLI session logs to reconstruct forgotten work, plus git commits and GitHub PRs. Enforces a 3-part impact contra

Files · 1

View on GitHub

SKILL.md

1	# Brag Sheet — Work Impact Writer
2
3	Turn engineering work into evidence-backed impact statements for performance reviews, self-reviews, promotion packets, and weekly updates. Uniquely mines Copilot CLI session logs, git history, and PRs to reconstruct forgotten work.
4
5	USE FOR: "brag", "log work", "what did I do", "backfill", "performance review", "self-review", "promo packet", "weekly update", "status report", "write impact statement", "what did I ship", "I forgot to log my work", "review prep", "accomplishments"
6	DO NOT USE FOR: project management, sprint planning, time tracking, ticket creation
7
8	## Quick Start
9
10	\| User wants... \| Mode \| Output \|
11	\|---------------\|------\|--------\|
12	\| Log one accomplishment \| Capture \| 1 impact-first entry \|
13	\| "What did I do last week?" \| Backfill \| Entries grouped by week, mined from git/PRs/sessions \|
14	\| Prep for review or promo \| Review Pack \| Entries grouped by impact theme + STAR narratives \|
15
16	## Agent Behavior Rules
17
18	1. DO confirm the time range and scope before scanning sources. Don't assume "last week" — ask.
19	2. DO check which tools are available (`save_to_brag_sheet`, `git`, `gh`) before choosing a workflow.
20	3. DO always include all three parts: action → result → evidence. If evidence is missing, write `(evidence needed)` — never silently omit.
21	4. DO show drafted entries to the user before saving. Never auto-save without confirmation.
22	5. DO group related commits into a single entry. Ten commits on the same feature = one entry.
23	6. DO preserve the user's voice. Reframe for impact, but don't invent accomplishments or inflate scope.
24	7. DO NOT fabricate metrics, team sizes, or impact numbers. If the user doesn't provide a number, don't invent one.
25	8. DO NOT write entries for work the user only described verbally without verifying. Ask: "Did this ship? Is there a PR or doc I can reference?"
26	9. DO NOT skip the backfill scan steps or draft entries before scanning is complete.
27	10. DO NOT pad weak periods with trivial entries. An honest gap is better than inflated fluff.
28
29	## Entry Format
30
31	Every entry uses impact-first framing with three required parts:
32
33	```
34	Did [action] → [result/impact] → [evidence]
35	```
36
37	Do not output an entry unless it includes all three parts. If evidence is missing, ask for it or mark as "(evidence needed)".
38
39	### Anti-Patterns
40
41	\| ❌ Don't \| ✅ Do instead \|
42	\|---------\|--------------\|
43	\| "Fixed a bug in auth" \| "Fixed token refresh race condition → eliminated 401s affecting 12% of API calls → PR #247" \|
44	\| "Worked on dashboards" \| "Built latency dashboard in Grafana → on-call detects P95 spikes in <2min → deployed to prod" \|
45	\| Invent a metric: "saved 40% of eng time" \| Ask: "Do you have a rough estimate, or should I keep this qualitative?" \|
46	\| One entry per commit \| Group related commits into one entry with highest-impact framing \|
47	\| Passive voice: "The pipeline was improved" \| Active voice: "Built CI matrix → caught Windows-only bug before release" \|
48	\| List technologies used \| State the outcome: "Migrated 4 services to IaC → deploy time 45min → 8min" \|
49	\| Silently drop weak entries \| Mark `(evidence needed)` and present for user to fill in \|
50
51	## Evidence Ladder
52
53	Not every entry needs a metric. Use the strongest evidence available:
54
55	\| Strength \| Evidence type \| Example \|
56	\|----------\|--------------\|---------\|
57	\| 🥇 Best \| Quantified metric \| "Reduced P95 latency from 800ms to 120ms" \|
58	\| 🥈 Strong \| PR, commit, or doc link \| "PR #312, design doc in wiki" \|
59	\| 🥉 Good \| Observable outcome \| "Unblocked Team X", "Resolved Sev2 incident Y" \|
60	\| ✅ Acceptable \| Qualitative + context \| "Reduced toil for on-call rotation — see updated runbook" \|
61	\| ⚠️ Weak \| Activity only \| "Worked on auth" — reframe or mark `(evidence needed)` \|
62
63	Never invent a me

People who liked this also viewed

6 picks

Type

brag-sheet

37kstars4.6kforks

View on GitHub

How to install brag-sheet?

github/awesome-copilot/brag-sheet

$npx -y skills add github/awesome-copilot --skill brag-sheet

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Brag Sheet — Work Impact Writer
2
3	Turn engineering work into evidence-backed impact statements for performance reviews, self-reviews, promotion packets, and weekly updates. Uniquely mines Copilot CLI session logs, git history, and PRs to reconstruct forgotten work.
4
5	USE FOR: "brag", "log work", "what did I do", "backfill", "performance review", "self-review", "promo packet", "weekly update", "status report", "write impact statement", "what did I ship", "I forgot to log my work", "review prep", "accomplishments"
6	DO NOT USE FOR: project management, sprint planning, time tracking, ticket creation
7
8	## Quick Start
9
10	\| User wants... \| Mode \| Output \|
11	\|---------------\|------\|--------\|
12	\| Log one accomplishment \| Capture \| 1 impact-first entry \|
13	\| "What did I do last week?" \| Backfill \| Entries grouped by week, mined from git/PRs/sessions \|
14	\| Prep for review or promo \| Review Pack \| Entries grouped by impact theme + STAR narratives \|
15
16	## Agent Behavior Rules
17
18	1. DO confirm the time range and scope before scanning sources. Don't assume "last week" — ask.
19	2. DO check which tools are available (`save_to_brag_sheet`, `git`, `gh`) before choosing a workflow.
20	3. DO always include all three parts: action → result → evidence. If evidence is missing, write `(evidence needed)` — never silently omit.
21	4. DO show drafted entries to the user before saving. Never auto-save without confirmation.
22	5. DO group related commits into a single entry. Ten commits on the same feature = one entry.
23	6. DO preserve the user's voice. Reframe for impact, but don't invent accomplishments or inflate scope.
24	7. DO NOT fabricate metrics, team sizes, or impact numbers. If the user doesn't provide a number, don't invent one.
25	8. DO NOT write entries for work the user only described verbally without verifying. Ask: "Did this ship? Is there a PR or doc I can reference?"
26	9. DO NOT skip the backfill scan steps or draft entries before scanning is complete.
27	10. DO NOT pad weak periods with trivial entries. An honest gap is better than inflated fluff.
28
29	## Entry Format
30
31	Every entry uses impact-first framing with three required parts:
32
33	```
34	Did [action] → [result/impact] → [evidence]
35	```
36
37	Do not output an entry unless it includes all three parts. If evidence is missing, ask for it or mark as "(evidence needed)".
38
39	### Anti-Patterns
40
41	\| ❌ Don't \| ✅ Do instead \|
42	\|---------\|--------------\|
43	\| "Fixed a bug in auth" \| "Fixed token refresh race condition → eliminated 401s affecting 12% of API calls → PR #247" \|
44	\| "Worked on dashboards" \| "Built latency dashboard in Grafana → on-call detects P95 spikes in <2min → deployed to prod" \|
45	\| Invent a metric: "saved 40% of eng time" \| Ask: "Do you have a rough estimate, or should I keep this qualitative?" \|
46	\| One entry per commit \| Group related commits into one entry with highest-impact framing \|
47	\| Passive voice: "The pipeline was improved" \| Active voice: "Built CI matrix → caught Windows-only bug before release" \|
48	\| List technologies used \| State the outcome: "Migrated 4 services to IaC → deploy time 45min → 8min" \|
49	\| Silently drop weak entries \| Mark `(evidence needed)` and present for user to fill in \|
50
51	## Evidence Ladder
52
53	Not every entry needs a metric. Use the strongest evidence available:
54
55	\| Strength \| Evidence type \| Example \|
56	\|----------\|--------------\|---------\|
57	\| 🥇 Best \| Quantified metric \| "Reduced P95 latency from 800ms to 120ms" \|
58	\| 🥈 Strong \| PR, commit, or doc link \| "PR #312, design doc in wiki" \|
59	\| 🥉 Good \| Observable outcome \| "Unblocked Team X", "Resolved Sev2 incident Y" \|
60	\| ✅ Acceptable \| Qualitative + context \| "Reduced toil for on-call rotation — see updated runbook" \|
61	\| ⚠️ Weak \| Activity only \| "Worked on auth" — reframe or mark `(evidence needed)` \|
62
63	Never invent a me

People who liked this also viewed

6 picks

Type