Brag-Sheet

# Brag Sheet — Work Impact Writer

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.

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"

DO NOT USE FOR: project management, sprint planning, time tracking, ticket creation

Quick Start

| User wants... | Mode | Output |

|---------------|------|--------|

| Log one accomplishment | **Capture** | 1 impact-first entry |

| "What did I do last week?" | **Backfill** | Entries grouped by week, mined from git/PRs/sessions |

| Prep for review or promo | **Review Pack** | Entries grouped by impact theme + STAR narratives |

Agent Behavior Rules

1. **DO** confirm the time range and scope before scanning sources. Don't assume "last week" — ask.

2. **DO** check which tools are available (`save_to_brag_sheet`, `git`, `gh`) before choosing a workflow.

3. **DO** always include all three parts: action → result → evidence. If evidence is missing, write `(evidence needed)` — never silently omit.

4. **DO** show drafted entries to the user before saving. Never auto-save without confirmation.

5. **DO** group related commits into a single entry. Ten commits on the same feature = one entry.

6. **DO** preserve the user's voice. Reframe for impact, but don't invent accomplishments or inflate scope.

7. **DO NOT** fabricate metrics, team sizes, or impact numbers. If the user doesn't provide a number, don't invent one.

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?"

9. **DO NOT** skip the backfill scan steps or draft entries before scanning is complete.

10. **DO NOT** pad weak periods with trivial entries. An honest gap is better than inflated fluff.

Entry Format

Every entry uses impact-first framing with three required parts:

Did [action] → [result/impact] → [evidence]

**Do not output an entry unless it includes all three parts.** If evidence is missing, ask for it or mark as "(evidence needed)".

Anti-Patterns

| ❌ Don't | ✅ Do instead |

|---------|--------------|

| "Fixed a bug in auth" | "Fixed token refresh race condition → eliminated 401s affecting 12% of API calls → PR #247" |

| "Worked on dashboards" | "Built latency dashboard in Grafana → on-call detects P95 spikes in <2min → deployed to prod" |

| Invent a metric: "saved 40% of eng time" | Ask: "Do you have a rough estimate, or should I keep this qualitative?" |

| One entry per commit | Group related commits into one entry with highest-impact framing |

| Passive voice: "The pipeline was improved" | Active voice: "Built CI matrix → caught Windows-only bug before release" |

| List technologies used | State the outcome: "Migrated 4 services to IaC → deploy time 45min → 8min" |

| Silently drop weak entries | Mark `(evidence needed)` and present for user to fill in |

Evidence Ladder

Not every entry needs a metric. Use the strongest evidence available:

| Strength | Evidence type | Example |

|----------|--------------|---------|

| 🥇 Best | Quantified metric | "Reduced P95 latency from 800ms to 120ms" |

| 🥈 Strong | PR, commit, or doc link | "PR #312, design doc in wiki" |

| 🥉 Good | Observable outcome | "Unblocked Team X", "Resolved Sev2 incident Y" |

| ✅ Acceptable | Qualitative + context | "Reduced toil for on-call rotation — see updated runbook" |

| ⚠️ Weak | Activity only | "Worked on auth" — reframe or mark `(evidence needed)` |

Never invent a metric to fill the gap. Qualitative evidence with context beats fabricated numbers.

Categories

| ID | Emoji | Use for |

|----|-------|---------|

| `pr` | 🚀 | Merged PRs, shipped features |

| `bugfix` |