职业履历
根据员工真实工作证据构建职业履历：
- 长版记录： 执行摘要、影响卡片、PR 季度图表、CV 要点、STAR 故事、季度时间线、项目卡片、技能、领导力、表彰、成长时刻，以及列出每条 PR、Jira 问题和 Confluence 页面的附录。
- 短版简报 用于筛选面试：简介、关键事实、可悬停的职业时间线、最大成就、引语和技术栈。
两者均以 私密 制品形式发布并导出为 PDF。
与用户进行多轮协作完成，不是一次性任务。预计需要数轮用户审查。
硬性规则
-
处处只读。 绝不发送 Slack 消息、添加表情反应、创建或更新 Jira 工单或 Confluence 页面，也绝不保存 Amplitude 图表。将此规则放入每个子代理提示中。
-
先捕获，后分析。 访问权限可能随时消失，例如裁员时。在总结之前将原始数据转储到磁盘，不要等待分析完成再捕获下一个来源。
-
不编造指标。 每个数字都需要来源。如果缺少数字，在笔记中写
[ASK <NAME>: …]并向用户提问；绝不猜测。 -
保密性。 完全遵循
references/confidentiality.md。简而言之：- 不出现客户名称或 ID；
- 不出现内部收入或 ARR 数字；
- 不出现薪酬、HR 或个人内容；
- 不出现凭证；
- 不出现内部 URL 作为内容。
原始转储保留在本地。
-
准确注明功劳。 对于团队功能，表述为“团队功能”。如果团队成员实现了某件事，要说明。由用户决定每条项目的呈现力度。
-
在审查轮次后编辑笔记之前，将其复制到
notes/backups/<file>.pre-<round>.md。
工作区
默认：~/career-record/。询问用户是否需要其他位置。
career.json # 身份信息 + 两个页面的前置内容（参见 examples/career.json）
raw/{github,jira,confluence,slack,cultureamp,amplitude}/ # 未处理的导出数据
notes/ # 每个来源的摘要 + 构建器的合成文件
notes/session-handoff.md # 运行状态；每次压缩后首先读取
output/ # achievements.html、overview.html、*-standalone.html、*.pdf
保持 notes/session-handoff.md 随着进展不断更新。记录：
- 阶段状态；
- 已确认的事实；
- 用户的决定和偏好；
- 制品 URL；
- 重建步骤。
保存一份指向它的简短项目记忆，以便后续会话可以继续。
阶段
0. 访谈（AskUserQuestion）
询问：
- 开始和结束日期；
- 团队或部落及其日期；
- 职级和晋升日期；
- 经理（仅用于上下文）；
- 履历用途（求职、晋升、存档）及受众；
- GitHub 组织和登录名；
- 他们记得的亮点，作为交叉检查的种子列表；
- 任何绝对不能提及的客户或主题。这些将被放入屏蔽列表。
- 重要 Slack 频道：
- 团队和部落频道；
- 任务、项目或小队频道；
- 值班或告警频道；
- 事件频道；
- 表彰频道，例如 #shoutouts；
- 流程或启动频道。
- 是否有任何私密频道或私信很重要，例如与经理、紧密协作者的讨论或私人团队频道。
明确告知用户 Slack 工具只能捕获公开频道。如果他们希望包含私密频道或私信，必须自行将那些消息复制到 raw/slack/ 中，格式为 .txt 或 .md 文件，每个频道或联系人一个文件。具体步骤在 references/sources.md 的 Slack 部分。
将答案写入 notes/phase0-background.md，包括频道列表以及用户将要粘贴的私密来源。创建 <scratchpad>/blocklist.txt，每行一个词条：客户名称、公司 ID 以及用户标记的任何其他内容。将其放在工作区之外。
1–5. 捕获
对每个来源遵循 references/sources.md：
- GitHub
- Jira
- Confluence
- Slack
- Culture Amp（手动 PDF）
- Amplitude（可选）
使用子代理并行运行独立来源。如果访问权限可能很快被撤销，优先捕获 Slack 和 Culture Amp。它们最难重建。
捕获后，为每个来源写一份摘要：notes/<source>-summary.md。
5b. 交叉引用
构建 notes/crossref.md，如果有助于构建 crossref.json：
- 将每条 PR 映射到其 Jira 键。
- 将每个 Jira 问题汇总到其史诗或任务。
- 将 Confluence 文档和 Slack 线程附加到这些集群。
处理超过 2 年的工作。 Slack 历史记录通常只回溯到今天约 2 年。Slack 包含了解释工作为何发生以及各部分如何关联的大部分“粘合剂”，因此对于任何更早的工作，从 GitHub 和 Jira 以及存在的 Confluence 重建故事：
-
寻找集群。 同一看板上关于同一或类似主题、创建或解决时间接近的多个工单，很可能是一个任务或项目。例如，针对某个功能区域的一系列 IM、QOL 或 IL 工单。其他信号：
- 共享的史诗或父项；
- 共享的标签或冲刺名称；
- 同几周内对相同库的 PR；
- 该时期的 Confluence 检查清单或设计文档。
-
在笔记中记录每个集群 作为可能的目标，标记为重建。列出：
- 工单和 PR；
- 日期范围；
- 你对目标的猜测；
- 证据。
例如：
**可能的目标（重建，前 Slack 时期）：** 可见性规则，2023 年 9 月，IM-762/763/764 + 3 个 PR。[ASK <NAME>: 目标名称、目标、你的角色？] -
除非确认，向用户确认上下文，例如史诗名称和描述已经说明了一切。询问：
- 目标的名称和目的；
- 还有谁参与；
- 你的角色；
- 成果；
- 出了什么问题。
按时间段分批提问，而不是逐个询问。
-
绝不编造粘合剂。 没有 Slack 或用户确认的情况下，只描述工单和 PR 显示的内容，而不是动机或影响。
-
2024 年之前的评价忽略。 Culture Amp 只能回溯到 2024 年。对于更早的时期，没有评分或评价者引述。不要留下看起来像那段时间没有表彰的空白：注明该来源不存在，并询问用户任何他们记得或保留的反馈。
每一条有作者署名的 PR 必须恰好落在一个集群中或属于“杂项/维护”。标记你按仓库、时间或标题分组的 PR 为 推断。没有 PR 的史诗是非代码工作，例如设计、协调或领导力，因此保留它们。向用户展示集群并根据他们的更正进行调整。
6. 综合
按照 references/notes-format.md 中的格式写出笔记文件：
notes/timeline.md：职业发展弧线加上每个季度一个部分。notes/project-cards.md：每个集群一张卡片，涵盖问题、角色、构建内容、影响/成果、技术和证据。notes/people-skills-recognition.md：要点数字、技能矩阵、领导力、表彰引述和成长时刻。notes/cv-and-stories.md：8–12 条 CV 要点和 5–8 个 STAR 故事。
每个说法都带有 (src: …) 引用。然后让用户审查卡片和指标。这一轮通常会重新排列优先级并纠正错误归功。
7. 输出
- 使用 `intent: