職業歷程記錄是做什麼的？

根據一個人的實際工作證據建立職業記錄：

詳細記錄： 執行摘要、影響力方塊、每季度 PR 圖表、履歷重點、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；
重建步驟。

儲存指向它的簡短專案記憶，以便後續 session 可以繼續。

階段

0. 訪談 (AskUserQuestion)

詢問：

開始和結束日期；
團隊或部落，含日期；
職級和晉升日期；
主管（僅供參考）；
記錄的目的（求職、晉升、歸檔）和閱聽人；
GitHub 組織和登入名稱；
他們記得的亮點，作為交叉核對的種子清單；
任何絕對不能提及的客戶或主題。這些進入封鎖清單。
重要的 Slack 頻道：
- 團隊和部落頻道；
- 任務、專案或小組頻道；
- 待命或警報頻道；
- 事件頻道；
- 表揚頻道，例如 #shoutouts；
- 流程或啟動頻道。
是否有任何私人頻道或 DM 很重要，例如與主管、密切合作者的對話串，或私人小組頻道。

清楚告訴他們 Slack 工具只能擷取公開頻道。如果他們希望包含私人頻道或 DM，他們必須自行將這些訊息複製到 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 問題向上彙總到其 Epic 或任務。
將 Confluence 文件和 Slack 討論串附加到這些群組。

處理超過 2 年的工作。 Slack 歷史記錄通常只能回溯到今天起約 2 年。Slack 包含了大部分解釋工作原因以及各部分如何關聯的「黏合劑」，因此對於更舊的內容，需要從 GitHub 和 Jira（以及存在的 Confluence）重建故事：

尋找群組。 同一看板上關於相同或類似主題、建立或解決時間相近的多個工單，很可能是一個任務或專案。範例包括關於一個功能區域的一系列 IM、QOL 或 IL 工單。進一步的訊號：
- 共享的 Epic 或父項；
- 共享的標籤或 Sprint 名稱；
- 在同一幾週內對相同儲存庫的 PR；
- 該時期的 Confluence 檢查清單或設計文件。
將每個群組記錄在筆記中 作為一個可能的任務，並標記為重建。列出：
- 工單和 PR；
- 日期範圍；
- 您猜測的目標；
- 支援的證據。
例如：**可能的任務（已重建，Slack 前）：** 可見性規則，2023 年 9 月，IM-762/763/764 + 3 個 PR。 [ASK <NAME>: 任務名稱、目標、您的角色？]
除非您確定（例如 Epic 名稱和描述已清楚說明），否則請與當事人確認背景。 詢問關於：
- 任務的名稱和目的；
- 還有誰參與其中；
- 他們在其中的角色；
- 成果；
- 任何出錯的地方。
按期間批次提出這些問題，而不是一次問一個。
絕不發明黏合劑。 如果沒有 Slack 或當事人的確認，請描述工單和 PR 顯示的內容，而不是動機或影響。
2024 年之前無審閱。 Culture Amp 只能追溯到 2024 年。對於更早的內容，沒有評分或審閱者引述。不要留下一個看起來像當事人在該時期沒有獲得表揚的空白：註明該來源不存在，並詢問當事人他們記得的或保留的任何回饋。

每個原創的 PR 必須歸入恰好一個群組或「其他/維護」中。將您按儲存庫、時間或標題分組的 PR 標記為推斷。沒有 PR 的 Epic 是非程式碼工作，例如設計、協調或領導，因此保留它們。向當事人展示這些群組並套用他們的修正。

6. 合成

以 references/notes-format.md 中的格式撰寫筆記檔案：

notes/timeline.md：職業歷程加上每季一個章節。
notes/project-cards.md：每個群組一張卡片，涵蓋問題、角色、他們建立的內容、影響/成果、技術和證據。
notes/people-skills-recognition.md：重點數字、技能矩陣、領導力、表揚引述和成長時刻。
notes/cv-and-stories.md：8-12 條履歷重點和 5-8 個 STAR 故事。

每個主張都帶有 (src: …) 參考。然後讓當事人審閱卡片和指標。這一輪通常會重新排序優先事項並捕捉到錯誤歸功。

7. 輸出

使用 intent: "other" 執行 Artifact 快速入門，這涵蓋了頁面設計指南。
根據 examples/career.json 填寫 career.json：
- 姓名、日期和副標題；
- 摘要段落；
- 影響力方塊。像 PR、儲存庫、審閱、Jira 問題和 Confluence 頁面的計數會自動產生；僅新增額外的。
- 圖表頻段，例如晉升；
- 遮罩模式；
- overview 區塊：車道、里程碑（row 0/1 和 anchor start/middle/end 防止標籤碰撞）、成就、引述、事實和技術堆疊。
長條種類為 role、promoted、lead、work、oncall 和 alt。

建置：

python3 <skill>/scripts/build.py <workspace>
python3 <skill>/scripts/build_overview.py <workspace>
<skill>/scripts/check_blocklist.sh <scratchpad>/blocklist.txt <workspace>/output/achievements.html <workspace>/output/overview.html   # 必須為 0

檢查版面：
- scripts/export_pdf.sh 寫入 *-standalone.html。
- scripts/screenshot.sh 渲染它；檢視 PNG 以檢查標籤碰撞或內容溢出。
- 特別檢查時間軸里程碑。
使用 Artifact 工具將每個頁面發布為私有成品，然後傳遞相同的 file_path 以供稍後重新發布。給當事人兩個連結。
使用 scripts/export_pdf.sh <workspace>/output/achievements.html 和 scripts/export_pdf.sh <workspace>/output/overview.html 匯出 PDF。詳細的 PDF 主要是附錄，通常有 50-100 頁。
要求當事人抽查大約 10 個主張與證據比對。

調整迴圈

當事人會要求重新排序強調重點、新增或替換引述，或新增缺少的早期工作。

編輯筆記或 career.json。
重建。
執行封鎖清單檢查。
重新發布到相同的 URL。
重新匯出 PDF。
將每個決定記錄在交接檔案中。

早期年份通常記錄不足：Slack 歷史記錄只能回溯大約 2 年，Culture Amp 僅涵蓋 2024 年以後。特別針對該時期搜尋 Jira、Confluence 和 GitHub。

先前執行的經驗教訓

工具提示： SVG <title> 懸停在成品內部不起作用。概覽使用由 data-tip="Label|detail" 驅動的 JS 工具提示，建置已處理此問題。
長 STAR 故事： 保持重點簡短且嵌套，而不是長段落。
人們的偏好：
- 將整個小組或任務功能化，而不是單一工單；
- 根據職級來框架信任訊號，例如「在還是初階工程師時」；
- 包括招聘面試、演講和流程領導，而不僅僅是程式碼。
錯誤和復原 在誠實講述時是寶貴的「成長」素材。不要隱藏它們，但讓當事人決定是否將其變成 STAR 故事。

職業歷程記錄