客製化履歷
將一個人的基礎履歷加上職缺描述，轉換成客製化履歷 (.md + .pdf)。然後報告這份履歷對職缺需求的覆蓋程度，以及缺少了什麼。
準確性是這項技能的重點。一份誇大經歷的客製化履歷可能讓使用者失去錄取機會，甚至入職後的工作。因此，這項技能會維護一份經驗事實記錄，絕不捏造任何資訊，並將差距視為需要報告的項目，而非隱藏起來。
履歷工作區
在使用者的履歷資料夾中工作，通常是當前目錄。其中包含：
| 檔案 | 用途 |
|---|---|
base-resume.md | 以此技能的 Markdown 格式儲存的主履歷。所有客製化版本都從此開始。 |
facts.md | 事實記錄：修正、基礎履歷中缺少的已確認事實、絕對不能宣稱的事項，以及偏好設定（頁數、紙張尺寸、聯絡方式行）。 |
<slug>-resume-<company>.md / .pdf | 每個職位申請對應一個客製化版本。<slug> 是使用者姓名的短橫線式。 |
| 其他任何檔案 | 使用者提供的輔助資料：LinkedIn 匯出檔、舊 PDF、GitHub 個人檔案、專案 README。 |
如果資料夾中有名稱不同的履歷，請使用它，並在 facts.md 中註明其名稱，而不是重新命名使用者的檔案。
首次執行：初始化
如果還沒有基礎履歷：
- 詢問使用者現有的履歷（PDF、DOCX、純文字，或 LinkedIn 匯出檔）。如果是 PDF，使用
pdftotext -layout提取。 - 將其轉換成
references/format.md中的格式，保留原有的措辭。此時不要進行客製化。 - 從
assets/facts-template.md建立facts.md，填入聯絡資訊行和使用者提及的任何偏好設定。 - 向使用者顯示基礎履歷，並請他們在進行客製化前先檢查。此處的錯誤會擴散到所有後續版本。
處理新職缺的工作流程
-
閱讀來源。 閱讀
base-resume.md、facts.md以及任何輔助來源。facts.md的內容在與基礎履歷不一致時具有優先權。 -
分析職缺。 將其要求分為三個等級：
- P1： 必要條件（決定性因素）
- P2： 強烈希望具備
- P3： 有加分
記錄職缺的用詞和重複出現的關鍵字。ATS 的關鍵字匹配是字面上的，因此在兩者都屬實的情況下，職缺的用詞優於同義詞。
-
比對證據。 針對每個要求，在來源中尋找實際證據。將其標記為強烈、部分或差距。
-
撰寫客製化版本 到
<slug>-resume-<company>.md。從基礎履歷的副本開始，然後：- 摘要： 重寫，使其開頭強調此職位最重視的部分。這是招募人員最先看到的內容。
- 技能： 重新排序並分組，使最相關的技能排在前面，並將行標籤重新命名為職缺的用語（例如「訊息佇列與串流」、「平台與交付」）。對於職缺中使用的關鍵縮寫詞，在每個詞旁邊寫一次全稱，例如「Terraform (基礎設施即程式碼, IaC)」、「Kubernetes (K8s)」。ATS 可能會搜尋任一形式。
- 條列項目： 在每個職位描述中重新排序和改寫，讓最相關的內容排在前面，並刪除對這個職缺不重要的項目。較舊的職位可以縮減為 1–3 個條列項目。
- 事實記錄： 套用
facts.md中的每一項。 - 開源 / 專案： 對於有公開作品的技術職位，在聯絡資訊行中加入 GitHub/作品集連結，並新增一個簡短的
## 開源貢獻或## 專案區段。選擇 2–3 個最相關的項目。 - 轉職： 如果此職位是職涯轉變（例如從工程師轉為開發者關係），請保持一般的時間順序版面。在摘要和技能之間新增一個簡短的亮點區段，收集真實、可轉移的證據。不要使用「功能性」履歷；招募人員和 ATS 系統通常不信任此類格式。
-
建置並驗證（見下文）。在回報前修正版面問題。
-
回報，使用下列格式。
誠實規則
這些規則的存在是因為誇大陳述的誘惑持續存在且難以察覺。每一條規則都是為了防止實際發生過的錯誤。
- 絕不捏造 技能、工具、指標、規模數字、職稱或責任。如果職缺要求某些來源中未顯示的內容，請將其省略並列為差距。使用者很可能確實有相關經驗。詢問只需一條訊息；而捏造的宣稱可能會在面試中被揭露。
- 改寫是可以的；強化則不行。 匹配職缺的詞彙是可行的。但提升宣稱的強度則不行，例如：
- 「參與過」變成「主導」
- 在沒有來源的情況下加入「在數分鐘內」、「大規模」、「在生產環境負載下」
- 將兩個獨立的陳述合併成一個更大的宣稱。例如，「主導團隊處理開源和企業專案；企業專案有 20 萬名使用者」絕對不能變成「主導一個開源團隊，其專案觸及 20 萬名使用者」。
- 不得加入來源中沒有的自我讚美， 例如「處理疑難雜症的工程師」或「能向任何聽眾解釋任何事物」。應以證據來展現。
- 謹慎歸因。 將事實與它來自的職位綁定。使用者確認但不屬於特定職位的事實（例如「我用過 Terraform」）應放在摘要或技能中，而不是放在推測的職位下方。
- 保留指標原貌。 百分比、數量和時間範圍必須與來源所述完全一致。
- 保留真實職稱。 在摘要中進行框架描述（例如「資深後端工程師」）是可以的。
- 在建置前，檢查每個新增或修改的條列項目 是否有來源依據。當某項內容是合理的推論但未明確說明時，要嘛刪除它，要嘛在回報中標明。
當使用者修正或確認某事項時
立即將其加入 facts.md，包含日期，如果知道的話，也包含所屬職位。然後搜尋所有其他客製化版本的履歷，找出相同的錯誤並一併修正。跳過使用者表示已寄出的版本，並在 facts.md 中列出這些版本，以便未來執行時略過它們。重新建置你修改過的 PDF，並告知使用者哪些檔案有變更。
建置與驗證
python3 "${CLAUDE_SKILL_DIR}/scripts/build_resume.py" <slug>-resume-<company>.md --check
- 功能： 將 PDF 寫入 Markdown 檔案旁邊，然後印出頁數以及 ATS 解析器會提取的文字。如果
facts.md中說使用者偏好 A4，請加上--paper a4參數。 - 如果
${CLAUDE_SKILL_DIR}未設定： 請使用此技能目錄的絕對路徑。 - 如果找不到瀏覽器： 請使用者安裝 Chrome 或 Chromium，或者設定
CHROME_BIN環境變數指向其路徑。
然後檢查三件事：
- 頁數。 使用
facts.md中的使用者偏好。否則，約 10 年以下經驗目標為 1 頁，10 年以上則為 2 頁。 - 視覺版面。 如果
pdftoppm可用，執行pdftoppm -r 60 -png <pdf> <tmpdir>/preview並查看每一頁的圖片。檢查是否有尷尬的分頁和換行不佳的文字行。 - 提取的文字。 每個技能行應該讀起來是一行包含其標籤，每個職位標題應該是一行包含其日期。如果不是，表示 Markdown 可能偏離了格式。
如果超出頁數目標，請依此順序刪減
- 較舊職位中最不相關的條列項目
- 過長的技能行（合併行，保持每行在一行內）
- 證照（合併到一行，刪除不相關的）
- 摘要長度
不要為了符合頁數而縮小字體或邊界。密集的頁面對人類來說閱讀體驗較差，對 ATS 也無益處。
版面規則
建置工具的版面是專為 ATS 解析而設計的，因此請勿修改。表格、多欄位和靠右對齊的日期（flex 或 float）看起來沒問題，但提取效果很差：標籤與值分離，日期與職稱分離。建置工具也會保持連字符號的單詞不換行，因為在換行處的連字符號會在提取時被省略（例如 "high-throughput" 會變成 "highthroughput"）。
回報格式
建置完成後，請回覆：
-
檔案：
.md和.pdf的路徑。 -
覆蓋率表格：
等級 要求 履歷中的證據（或 差距） -
重點說明： 簡短說明你強調了哪些內容以及刪減了哪些內容。
-
提問： 詢問可能填補 P1/P2 差距的經驗，或者你需要確認的推測陳述。請具體說明：「你是直接參與 X 專案，還是僅透過 Y 間接接觸？」
-
額外服務： 在不主動撰寫的前提下，提及你可以草擬求職信開場白、回答申請問題，或準備面試談話重點。
如果此職缺差距過大（存在多個 P1 差距），請坦白說明並建議最有幫助的作法。例如：一個作品集專案、對該公司程式庫的開源貢獻，或一封說明轉職原因的求職信。
申請問題與求職信
使用相同的事實記錄和誠實規則。以使用者的口吻（第一人稱）回答，簡潔有力，並明確指出你推測的具體細節，以便使用者修正。將求職信寫成 <slug>-cover-letter-<company>.md。build_resume.py 是為履歷設計的，因此若要產生 PDF 格式的求職信，請撰寫簡單的 HTML，並使用與腳本相同的無頭瀏覽器命令來列印。
參考檔案
references/format.md：建置工具解析的 Markdown 確切格式，附有完整範例。在撰寫或轉換履歷前請先閱讀。assets/facts-template.md：新facts.md的起點。assets/example-resume.md：一個用於測試建置工具的虛構範例履歷。