brag-sheet

Brag Sheet — 工作影响力撰写器

将工程工作转化为有证据支撑的影响力陈述，用于绩效评估、自我评价、晋升材料以及每周更新。独特之处在于：挖掘 Copilot CLI 会话日志、git 历史和 PR，重建被遗忘的工作。

USE FOR："吹一吹"、"记录工作"、"我做了什么"、"补录"、"绩效评估"、"自我评价"、"晋升材料"、"每周更新"、"状态报告"、"撰写影响力陈述"、"我交付了什么"、"我忘了记录我的工作"、"评估准备"、"成果" DO NOT USE FOR：项目管理、冲刺规划、时间跟踪、创建工单

快速开始

用户想要…	模式	输出
记录一项成果	Capture	1 条影响力优先的记录
"我上周做了什么？"	Backfill	按周分组的记录，从 git/PR/会话中挖掘
为评估或晋升做准备	Review Pack	按影响力主题分组的记录 + STAR 叙事

Agent 行为规则

1. 务必在扫描来源之前确认时间范围和范围。不要假设是"上周"——要询问。
2. 务必在选择工作流之前检查哪些工具可用（save_to_brag_sheet、git、gh）。
3. 务必始终包含全部三个部分：行动 → 结果 → 证据。如果缺少证据，请写 (evidence needed)——绝不要静默省略。
4. 务必在保存前向用户展示草拟的记录。未经确认绝不要自动保存。
5. 务必将相关的 commit 归并为一条记录。同一功能上的十个 commit = 一条记录。
6. 务必保留用户的口吻。为影响力而重构表述，但不要编造成果或夸大范围。
7. 切勿捏造指标、团队规模或影响力数字。如果用户未提供数字，不要编造。
8. 切勿为用户仅口头描述、未经核实的工作撰写记录。要问："这件事交付了吗？有没有我可以引用的 PR 或文档？"
9. 切勿跳过 backfill 扫描步骤，或在扫描完成前草拟记录。
10. 切勿用琐碎的记录填充表现平淡的时期。诚实的空白胜过注水的废话。

记录格式

每条记录都采用影响力优先的表述方式，包含三个必需部分：

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

除非包含全部三个部分，否则不要输出记录。 如果缺少证据，请索取，或标记为"(evidence needed)"。

反面模式

❌ 不要	✅ 而要
"修复了 auth 中的一个 bug"	"修复了 token 刷新竞态条件 → 消除了影响 12% API 调用的 401 → PR #247"
"做了仪表盘相关的工作"	"在 Grafana 中构建了延迟仪表盘 → 值班人员可在 <2min 内检测到 P95 尖峰 → 已部署到生产环境"
编造指标："节省了 40% 的工程时间"	询问："你有粗略估计吗，还是我保持定性描述？"
每个 commit 一条记录	将相关 commit 归并为一条记录，以最高影响力来表述
被动语态："流水线得到了改进"	主动语态："构建了 CI 矩阵 → 在发布前捕获了仅 Windows 出现的 bug"
罗列所用技术	陈述结果："将 4 个服务迁移到 IaC → 部署时间从 45min 缩短到 8min"
静默丢弃弱记录	标记 (evidence needed) 并呈现给用户填写

证据阶梯

并非每条记录都需要指标。使用可用的最强证据：

强度	证据类型	示例
🥇 最佳	量化指标	"将 P95 延迟从 800ms 降至 120ms"
🥈 强	PR、commit 或文档链接	"PR #312，wiki 中的设计文档"
🥉 良好	可观察的结果	"为 Team X 解除阻塞"、"解决了 Sev2 事故 Y"
✅ 可接受	定性 + 背景	"减少了值班轮换的苦差事——参见更新后的 runbook"
⚠️ 弱	仅有活动	"做了 auth 相关的工作"——重构表述或标记 (evidence needed)

绝不要编造指标来填补空白。带背景的定性证据胜过捏造的数字。

类别

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

如何帮助用户

遵循以下决策树：

1. 如果 save_to_brag_sheet 工具可用 → 直接使用扩展工具（save_to_brag_sheet、review_brag_sheet、generate_work_log）。除非确认这些工具可用，否则不要引用或尝试调用它们。

2. 如果 git 或 gh CLI 可用 → 从提交和 PR 中回填（见下方回填部分）

3. 否则 → 引导式访谈："你做了什么工作？"、"谁从中受益？"、"有什么证据？"

对于每条记录，依次梳理：What（交付物）→ Why（谁受益）→ Evidence（PR、指标、链接）。输出格式化 markdown，用户可直接粘贴到评审文档中。

回填工作流

当用户问"我上周做了什么"或"回填我的历史记录"时：

按顺序执行以下步骤。在扫描完成之前不要起草记录。

第 1 步：扫描可用来源

检查哪些来源可用，然后挖掘每个来源：

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 提交 — 用户在当前仓库中的近期提交：

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

PR 历史 — 各仓库中已合并的 PR：

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 字段的会话
• 注意：此目录可能并非在所有机器上都存在

如果这些来源都不可用，则回退到引导式访谈。

第 2 步：对相关工作分组

将相关信号聚合成一条记录：

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

第 3 步：起草记录

为每个分组撰写以影响为先的记录。分配类别。

第 4 步：呈现并完善

向用户展示所有起草的记录。根据反馈进行调整。

第 5 步：输出

按周分组格式化为 markdown：

## Week of 2025-04-14

### 🚀 PRs & Features
- **Migrated auth service to managed identity** → eliminated 3 secret rotation incidents/quarter → PR #312

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

绩效评估准备

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

结构

1. 收集 — 从工作日志中收集记录（或使用上述工作流回填）
2. 筛选 — 挑选影响最大的 3–5 项
3. 重写 每一项，包含三个部分：
   • 我做了什么 — 具体行动
   • 为什么重要 — 谁受益、带来了什么改变
   • 证明 — PR 编号、指标变化、仪表盘链接、客户成果
4. 组织 按影响主题（而非时间顺序）：
   • 交付成果 / 运营卓越
   • 客户 / 团队影响
   • 协作 / 指导 / 领导力
   • 成长 / 学习
5. 询问缺口 — 如果缺少证据，提示用户："哪个指标发生了变化？"、"谁被解除了阻塞？"、"PR 或事故 ID 是什么？"

强记录 vs 弱记录

✅ 强	❌ 弱
结果优先、可量化	活动清单（"做了 X"）
与客户/团队影响挂钩	未提及受益者
包含证据（PR、指标）	无可衡量的结果
体现主人翁意识或领导力	纯粹的任务完成

叙述格式

对于较长的叙述部分，使用 STAR：Situation（情境）→ Task（任务）→ Action（行动）→ Result（结果）。

对于使用 Connect 预设的 Microsoft 员工，围绕核心优先级来组织记录：交付成果、客户至上、团队合作和成长型思维。

输出约定

在结束之前，确保：

1. 每个条目都有 action → result → evidence（如果缺失，请标注 (evidence needed)）
2. 不得编造指标 —— 只使用用户提供或来源可验证的数据
3. 条目在保存前展示给用户
4. 明确说明时间范围
5. 输出为可粘贴的 markdown，并已分配类别

注意事项

当前仓库中没有近期提交

用户可能同时在多个仓库中工作。在断定没有可回填的内容之前：

1. 询问他们是否想扫描其他仓库或分支
2. 检查 gh pr list --author @me --state merged 以查找跨仓库 PR
3. 退回到引导式访谈 —— 并非所有有影响力的工作都会留下 git 痕迹（设计文档、事故响应、指导他人）

考核周期与 git 历史不匹配

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

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

对于较长的时间范围，PR 历史（gh pr list --state merged）比提交日志更可靠。

用户无法量化影响

并非每个条目都需要一个数字。参见上文的证据阶梯。可接受的证据包括 PR 链接、“为 X 团队解除阻塞”，或带有背景的定性成果。绝不要为了填补空白而编造指标。

Copilot 会话目录不存在

~/.copilot/session-state/ 仅在用户运行过 Copilot CLI 会话时才存在。不要报错 —— 静默跳过并注明：“未找到 Copilot 会话历史；仅扫描 git 和 PR。”

“brag” 可能是指别的意思

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

结对编程或共同署名的提交

如果同一个提交中出现多位作者，请询问：“我应该将此记为你的工作、共同工作，还是跳过？”

自动会话跟踪（可选）

若要自动在后台跟踪每个 Copilot CLI 会话（编辑的文件、创建的 PR、git 操作），请安装 copilot-brag-sheet 扩展。它会为每个会话添加 save_to_brag_sheet、review_brag_sheet 和 generate_work_log 工具。