brag-sheet

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Brag Sheet — Work Impact Writer

Brag Sheet — 工作影响陈述生成工具

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

将工程师的工作内容转化为有证据支持的影响陈述，适用于绩效评估、自我评估、晋升申请材料和每周更新。它独特地挖掘Copilot CLI会话日志、git历史记录和PRs来还原被遗忘的工作内容。

适用场景："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" 不适用场景：项目管理、迭代规划、时间跟踪、工单创建

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

用户需求...	模式	输出结果
记录一项工作成果	Capture（即时记录）	1条以影响为核心的条目
“我上周做了什么？”	Backfill（历史补全）	按周分组的条目，从git/PRs/会话日志中挖掘生成
准备评估或晋升材料	Review Pack（评估包）	按影响主题分组的条目 + STAR叙事结构

Agent Behavior Rules

Agent行为规则

DO confirm the time range and scope before scanning sources. Don't assume "last week" — ask.
DO check which tools are available (
```
save_to_brag_sheet
```
,
```
git
```
,
```
gh
```
) before choosing a workflow.
DO always include all three parts: action → result → evidence. If evidence is missing, write
```
(evidence needed)
```
— never silently omit.
DO show drafted entries to the user before saving. Never auto-save without confirmation.
DO group related commits into a single entry. Ten commits on the same feature = one entry.
DO preserve the user's voice. Reframe for impact, but don't invent accomplishments or inflate scope.
DO NOT fabricate metrics, team sizes, or impact numbers. If the user doesn't provide a number, don't invent one.
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?"
DO NOT skip the backfill scan steps or draft entries before scanning is complete.
DO NOT pad weak periods with trivial entries. An honest gap is better than inflated fluff.

必须在扫描数据源前确认时间范围和范围。不要默认“上周”——主动询问。
必须在选择工作流前检查可用工具（
```
save_to_brag_sheet
```
、
```
git
```
、
```
gh
```
）。
必须始终包含三个部分：行动→结果→证据。如果缺少证据，请标注
```
(evidence needed)
```
——绝不能悄悄省略。
必须在保存前向用户展示草稿条目。未经确认绝不自动保存。
必须将相关提交合并为单个条目。同一功能的10次提交=1条条目。
必须保留用户的表达风格。优化为影响导向，但不得编造成果或夸大范围。
禁止编造指标、团队规模或影响数据。如果用户未提供具体数值，不得自行杜撰。
禁止为用户仅口头描述的工作编写条目，需先验证：“这项工作已上线吗？有没有可参考的PR或文档？”
禁止跳过历史补全的扫描步骤，或在扫描完成前编写草稿条目。
禁止用无关紧要的条目填充成果薄弱的时间段。诚实的空白比虚假的内容更好。

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)".

每条条目均采用以影响为核心的框架，包含三个必填部分：

完成了[行动] → [结果/影响] → [证据]

除非包含全部三个部分，否则不得输出条目。 如果缺少证据，请询问用户或标注“(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

❌ 错误做法	✅ 正确做法
“修复了认证模块的一个bug”	“修复了令牌刷新竞态条件 → 消除了影响12% API调用的401错误 → PR #247”
“参与了仪表盘开发”	“在Grafana中构建延迟仪表盘 → 值班人员可在2分钟内检测到P95峰值 → 已部署至生产环境”
编造指标：“节省了40%的工程师时间”	询问：“您有大致估算值吗？还是保持定性描述？”
每次提交对应一条条目	将相关提交合并为一条条目，突出最高影响力的表述
被动语态：“流水线已优化”	主动语态：“构建CI矩阵 → 在发布前发现仅Windows环境存在的bug”
罗列使用的技术	说明成果：“将4个服务迁移至IaC → 部署时间从45分钟缩短至8分钟”
悄悄删除薄弱条目	标注 `(evidence needed)` 并展示给用户补充

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.

并非每条条目都需要量化指标。使用可用的最强证据：

强度	证据类型	示例
🥇 最优	量化指标	“将P95延迟从800ms降低至120ms”
🥈 强	PR、提交或文档链接	“PR #312，wiki中的设计文档”
🥉 良好	可观察的成果	“为团队X解除了阻塞”、“解决了Sev2事件Y”
✅ 可接受	定性描述+上下文	“减少了值班团队的重复工作——详见更新后的运行手册”
⚠️ 薄弱	仅描述活动	“参与了认证模块工作”——重新表述或标注 `(evidence needed)`

绝不编造指标填补空白。带上下文的定性证据优于虚假的数值。

分类

ID	Emoji	Use for
`pr`	🚀	Merged PRs, shipped features
`bugfix`	🐛	Bug fixes, incident patches
`infrastructure`	🏗️	Infra, deployments, migrations
`investigation`	🔍	Root cause analysis, debugging
`collaboration`	🤝	Reviews, mentoring, design discussions
`tooling`	🔧	Dev tools, scripts, automation
`oncall`	🚨	Incident response, on-call wins
`design`	📐	Design docs, architecture decisions
`documentation`	📝	Docs, runbooks, guides

ID	表情符号	适用场景
`pr`	🚀	已合并的PR、已上线的功能
`bugfix`	🐛	bug修复、事件补丁
`infrastructure`	🏗️	基础设施、部署、迁移
`investigation`	🔍	根因分析、调试
`collaboration`	🤝	代码评审、指导、设计讨论
`tooling`	🔧	开发工具、脚本、自动化
`oncall`	🚨	事件响应、值班成果
`design`	📐	设计文档、架构决策
`documentation`	📝	文档、运行手册、指南

How to Help the User

如何协助用户

Follow this decision tree:

If
save_to_brag_sheet
tool is available → use extension tools directly (
```
save_to_brag_sheet
```
,
```
review_brag_sheet
```
,
```
generate_work_log
```
). Do not reference or attempt to call these tools unless they are confirmed available.
If git or gh CLI is available → backfill from commits and PRs (see Backfill section below)
Otherwise → guided interview: "What did you work on?", "Who benefited?", "What's the evidence?"

For each entry, walk through: What (the deliverable) → Why (who benefits) → Evidence (PR, metric, link). Output formatted markdown the user can paste into a review doc.

遵循以下决策流程：

如果
save_to_brag_sheet
工具可用 → 直接使用扩展工具（
```
save_to_brag_sheet
```
、
```
review_brag_sheet
```
、
```
generate_work_log
```
）。仅在确认可用时才引用或调用这些工具。
如果git或gh CLI可用 → 从提交记录和PR中补全历史（见下方历史补全流程）
否则 → 引导式访谈：“您做了什么工作？”、“谁从中受益？”、“有什么证据？”

针对每条条目，依次确认：内容（交付成果）→ 价值（受益对象）→ 证据（PR、指标、链接）。输出可直接粘贴到评估文档中的格式化markdown内容。

Backfill Workflow

历史补全流程

When the user asks "what did I do last week" or "backfill my history":

Follow these steps in order. Do not draft entries until scanning is complete.

当用户询问“我上周做了什么”或“补全我的工作历史”时：

请按顺序执行以下步骤。扫描完成前不得编写草稿条目。

Step 1: Scan available sources

步骤1：扫描可用数据源

Check what's available, then mine each source:

bash

git --version 2>/dev/null         # for commit mining
gh --version 2>/dev/null          # for PR mining
ls ~/.copilot/session-state/ 2>/dev/null  # Copilot session logs

Git commits — recent commits by the user in the current repo:

bash

git log --author="$(git config user.email)" --since="2 weeks ago" \
  --pretty=format:'%h|%ad|%s' --date=short --no-merges

PR history — merged PRs across repos:

bash

gh pr list --author @me --state merged --limit 20 \
  --json number,title,repository,mergedAt

Copilot session history (unique to this skill):

Path:

~/.copilot/session-state/<session-id>/workspace.yaml

Read fields:
```
summary
```
,
```
cwd
```
,
```
repository
```
,
```
branch
```
Skip sessions without a
```
summary
```
field
Note: this directory may not exist on all machines

If none of these sources are available, fall back to the guided interview.

检查可用工具，然后挖掘每个数据源：

bash

git --version 2>/dev/null         # 用于提交记录挖掘
gh --version 2>/dev/null          # 用于PR挖掘
ls ~/.copilot/session-state/ 2>/dev/null  # Copilot会话日志

Git提交记录 — 当前仓库中用户的近期提交：

bash

git log --author="$(git config user.email)" --since="2 weeks ago" \
  --pretty=format:'%h|%ad|%s' --date=short --no-merges

PR历史 — 跨仓库的已合并PR：

bash

gh pr list --author @me --state merged --limit 20 \
  --json number,title,repository,mergedAt

Copilot会话历史（本工具独有）：

路径：

~/.copilot/session-state/<session-id>/workspace.yaml

读取字段：
```
summary
```
、
```
cwd
```
、
```
repository
```
、
```
branch
```
跳过无
```
summary
```
字段的会话
注意：并非所有机器上都存在此目录

如果这些数据源均不可用，则退回到引导式访谈。

Step 2: Group related work

步骤2：分组相关工作

Cluster related signals into one entry:

Same PR + its commits → 1 entry
Multiple commits on the same file/feature within 3 days → 1 entry
Copilot sessions referencing the same repo + branch → merge into PR entry if one exists

将相关信号聚类为单个条目：

同一PR及其提交记录 → 1条条目
3天内针对同一文件/功能的多次提交 → 1条条目
引用同一仓库+分支的Copilot会话 → 如果存在对应PR，则合并到PR条目中

Step 3: Draft entries

步骤3：编写草稿条目

Write impact-first entries for each group. Assign categories.

为每个分组编写以影响为核心的条目，并分配分类。

Step 4: Present and refine

步骤4：展示并优化

Show all drafted entries to the user. Adjust based on feedback.

向用户展示所有草稿条目，根据反馈调整内容。

Step 5: Output

步骤5：输出结果

Format as markdown grouped by week:

markdown

undefined

格式化为按周分组的markdown：

markdown

undefined

Week of 2025-04-14

2025-04-14当周

🚀 PRs & Features

🚀 PR与功能

Migrated auth service to managed identity → eliminated 3 secret rotation incidents/quarter → PR #312

将认证服务迁移至托管身份 → 每季度减少3次密钥轮换事件 → PR #312

🏗️ Infrastructure

🏗️ 基础设施

Built CI pipeline for copilot-brag-sheet → 107 tests across 3 OSes × 3 Node versions → shipped v1.0.0

undefined

为copilot-brag-sheet构建CI流水线 → 覆盖3种操作系统×3个Node版本的107项测试 → 已发布v1.0.0

undefined

Performance Review Prep

绩效评估准备

When the user is preparing for a performance review (Connect, annual review, etc.):

当用户准备绩效评估（如Connect、年度评估等）时：

Structure

流程

Gather — collect entries from the work log (or backfill using the workflow above)
Select — pick the top 3–5 highest-impact items
Rewrite each item with three parts:
- What I did — the specific action
- Why it mattered — who benefited, what changed
- Proof — PR number, metric delta, dashboard link, customer outcome
Organize by impact theme (not chronologically):
- Delivering results / operational excellence
- Customer / team impact
- Collaboration / mentoring / leadership
- Growth / learning
Ask for gaps — if evidence is missing, prompt the user: "What metric changed?", "Who was unblocked?", "What's the PR or incident ID?"

收集 — 从工作日志中提取条目（或通过上述流程补全历史）
筛选 — 选出3-5项最高影响力的工作
改写每项内容，包含三个部分：
- 我做了什么 — 具体行动
- 重要性 — 受益对象、带来的改变
- 证据 — PR编号、指标变化、仪表盘链接、客户反馈
组织 — 按影响主题排序（而非时间顺序）：
- 交付成果 / 运营卓越
- 客户 / 团队影响
- 协作 / 指导 / 领导力
- 成长 / 学习
补全缺口 — 如果缺少证据，提示用户：“指标有什么变化？”、“谁的工作被解除了阻塞？”、“PR或事件ID是什么？”

Strong vs weak entries

优质与劣质条目对比

✅ Strong	❌ Weak
Outcome-first, quantified	Activity list ("worked on X")
Tied to customer/team impact	No beneficiary mentioned
Includes evidence (PR, metric)	No measurable result
Shows ownership or leadership	Pure task completion

✅ 优质	❌ 劣质
以成果为核心，可量化	活动列表（“参与了X工作”）
关联客户/团队影响	未提及受益对象
包含证据（PR、指标）	无可衡量的成果
体现 ownership 或领导力	仅完成任务

Narrative format

叙事格式

For longer narrative sections, use STAR: Situation → Task → Action → Result.

For Microsoft employees using the Connect preset, frame entries around Core Priorities: delivering results, customer obsession, teamwork, and growth mindset.

对于较长的叙事部分，使用STAR结构：S情境 → T任务 → A行动 → R结果。

对于使用Connect模板的微软员工，请围绕核心优先级构建条目：交付成果、客户至上、团队协作、成长思维。

Output Contract

输出规范

Before finishing, ensure:

Every entry has action → result → evidence (mark
```
(evidence needed)
```
if missing)
No fabricated metrics — only user-provided or source-verified data
Entries shown to user before saving
Time range explicitly stated
Output is pasteable markdown with categories assigned

完成前请确保：

每条条目均包含行动→结果→证据（缺少时标注
```
(evidence needed)
```
）
无编造的指标 — 仅使用用户提供或数据源验证的数据
保存前已向用户展示条目
明确说明时间范围
输出为可粘贴的markdown格式，并已分配分类

Gotchas

注意事项

No recent commits in the current repo

当前仓库无近期提交

The user may work across multiple repos. Before concluding there's nothing to backfill:

Ask if they want to scan a different repo or branch
Check
```
gh pr list --author @me --state merged
```
for cross-repo PRs
Fall back to the guided interview — not all impactful work leaves git traces (design docs, incident response, mentoring)

用户可能跨多个仓库工作。在得出无内容可补全的结论前：

询问用户是否要扫描其他仓库或分支
检查
```
gh pr list --author @me --state merged
```
获取跨仓库PR
退回到引导式访谈 — 并非所有有影响力的工作都会留下git痕迹（如设计文档、事件响应、指导工作）

Review period doesn't match git history

评估周期与git历史不匹配

Performance reviews often cover 6–12 months. Explicitly set the date range:

bash

git log --author="$(git config user.name)" --since="2024-07-01" --until="2025-01-01" --oneline

PR history (

gh pr list --state merged

) is more reliable for long time ranges than commit logs.

绩效评估通常覆盖6-12个月。请明确设置日期范围：

bash

git log --author="$(git config user.name)" --since="2024-07-01" --until="2025-01-01" --oneline

PR历史（

gh pr list --state merged

）比提交记录更适合长周期的追溯。

User can't quantify impact

用户无法量化影响

Not every entry needs a number. See the Evidence Ladder above. Acceptable evidence includes PR links, "unblocked Team X", or qualitative outcomes with context. Never invent a metric to fill the gap.

并非每条条目都需要数值。参考上述证据等级。可接受的证据包括PR链接、“为团队X解除阻塞”或带上下文的定性成果。绝不编造指标填补空白。

Copilot session directory doesn't exist

Copilot会话目录不存在

~/.copilot/session-state/

only exists if the user has run Copilot CLI sessions. Don't error — silently skip and note: "No Copilot session history found; scanning git and PRs only."

~/.copilot/session-state/

仅在用户运行过Copilot CLI会话时存在。无需报错 — 静默跳过并提示：“未找到Copilot会话历史；仅扫描git和PRs。”

"brag" might mean something else

“brag”可能有其他含义

The user might say "brag about this feature to my team" (a launch announcement, not a work entry). Confirm intent if ambiguous.

用户可能说“向我的团队brag这个功能”（指发布公告，而非工作条目）。如果意图不明确，请确认。

Pair programming or co-authored commits

结对编程或共同提交的记录

If multiple authors appear on the same commits, ask: "Should I credit this as your work, shared work, or skip it?"

如果同一提交有多个作者，请询问：“我应该将此标注为您的独立工作、共同工作还是跳过？”

Automatic Session Tracking (Optional)

自动会话跟踪（可选）

For automatic background tracking of every Copilot CLI session (files edited, PRs created, git actions), install the copilot-brag-sheet extension. It adds

save_to_brag_sheet

review_brag_sheet

, and

generate_work_log

tools to every session.

如需自动后台跟踪所有Copilot CLI会话（编辑的文件、创建的PR、git操作），请安装copilot-brag-sheet扩展。它会为每个会话添加

save_to_brag_sheet

、

review_brag_sheet

和

generate_work_log

工具。

brag-sheet

Original

Translation

Brag Sheet — Work Impact Writer

Brag Sheet — 工作影响陈述生成工具

Quick Start

快速开始

Agent Behavior Rules

Agent行为规则

Entry Format

条目格式

Anti-Patterns

反模式示例

Evidence Ladder

证据等级

Categories

分类

How to Help the User

如何协助用户

Backfill Workflow

历史补全流程

Step 1: Scan available sources

步骤1：扫描可用数据源

Step 2: Group related work

步骤2：分组相关工作

Step 3: Draft entries

步骤3：编写草稿条目

Step 4: Present and refine

步骤4：展示并优化

Step 5: Output

步骤5：输出结果

Week of 2025-04-14

2025-04-14当周

🚀 PRs & Features

🚀 PR与功能

🏗️ Infrastructure

🏗️ 基础设施

Performance Review Prep

绩效评估准备

Structure

流程

Strong vs weak entries

优质与劣质条目对比

Narrative format

叙事格式

Output Contract

输出规范

Gotchas

注意事项

No recent commits in the current repo

当前仓库无近期提交

Review period doesn't match git history

评估周期与git历史不匹配

User can't quantify impact

用户无法量化影响

Copilot session directory doesn't exist

Copilot会话目录不存在

"brag" might mean something else

“brag”可能有其他含义

Pair programming or co-authored commits

结对编程或共同提交的记录

Automatic Session Tracking (Optional)

自动会话跟踪（可选）