Community影像github.com

thesinmaster/job-application-coach

針對單一職位申請,提供從職位匹配度檢查、客製化履歷與求職信、求職平台檔案調整、招募聯繫、面試準備到薪資與後續追蹤的完整支援。

job-application-coach 是什麼?

此技能專為管理單一職位申請流程而設計,涵蓋從初步評估到面試準備及後續追蹤的完整週期。它會先進行詳細的職缺與公司研究,並生成一份全面的適配報告,協助使用者決定是否值得申請。接著,系統會引導使用者產出兩份版本的履歷(一份保留原有佈局,一份使用 ATS 友善模板)與一封客製化求職信,並確保所有內容皆根據使用者真實的經歷撰寫,絕不虛構。此技能還能同步調整使用者在 LinkedIn 等所有求職平台上的個人檔案,確保一致性,並執行最終的文件檢查(如隱藏文字、中繼資料)以確保專業性。最後,它會提供招募者聯繫訊息、面試常見問題準備以及申請後的跟進策略。此工具支援任何職業、資歷與國家,並且適用於 Claude、Cursor 及 Codex 等 AI 代理平台。

相容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/thesinmaster/job-application-coach/tree/HEAD

Installed? Explore more 影像 skills: steipete/songsee, affaan-m/frontend-design, mattpocock/improve-codebase-architecture · View all 6 →

在你喜歡的 AI 中提問

開啟一個已預先載入此 Agent Skill 的新對話。

說明文件

求職顧問

引導求職者逐步完成單一職位申請,從「這份工作值得申請嗎」到「我該如何回應這封拒絕信」。適用於任何職業、資歷與國家。

嚴格規則

這些規則適用於每個階段,也是此技能存在的原因。

  1. 切勿添加求職者不具備的經歷。 除非求職者已確認,否則不得將任何經驗、技能、工具、認證、職稱或語言能力寫入履歷、求職信、個人檔案文字或面試答案中。當職位要求某項求職者沒有的技能時,請以最接近的真實經驗作為橋樑,並使用職位說明的用語來表達,或誠實地指出差距(請見第三階段)。
  2. 每個數字都來自求職者。 請主動詢問。如果求職者不知道具體數字,則在描述工作內容時不使用數字。切勿自行估算百分比、節省金額或團隊人數。
  3. 詢問「是建立還是維運?」 針對每個重要職位,了解求職者從無到有建立了什麼、接手並改進了什麼,以及僅負責維運了什麼。這個差異會改變一行描述的方式,且通常是履歷中最有力的素材。
  4. 聽起來要像求職者本人。 用詞應樸實,並提供具體且可驗證的細節。不要保證文字能「通過 AI 檢測」:此類工具並不可靠。目標是寫出求職者在面試中能自然說出、聽起來不像借用他人說詞的文字。
  5. 保持所有內容一致。 職稱、日期和經歷聲明在履歷、求職信、每個求職平台(專業社群網站、求職網站、公司徵才入口)以及其他所有正在進行的申請中必須保持一致。如果招募人員看到同一份工作的兩個不同版本,他將對兩者都不信任。
  6. 語言。 用使用者的語言與其交談。除非使用者另有要求,否則使用職位說明所使用的語言來撰寫文件。
  7. 隱私。 求職者的個人資料僅在此對話中使用。除非使用者要求,否則不得將其儲存於記憶體或任何外部場所。
  8. 非法律或稅務建議。 關於薪資結構、承包商身份或稅務問題,提供相關重要資訊,並建議其諮詢當地會計師或律師以做出決定。
  9. 使用者決定。 在每個決策點,提供建議與理由,然後讓使用者選擇。

工作流程

各個階段可以獨立進入(例如:「只要寫求職信」)。當某個階段需要來自較早階段的資訊但缺少時,應先詢問該特定資訊。

第零階段 - 初始資料收集(每位求職者執行一次)

詢問:

  • 目前的履歷(偏好 Word 格式;接受 PDF)。
  • 職涯故事:針對每個職位,詳細說明其工作內容,超越履歷上的描述。使用 references/intake.md 中的問題清單。這裡是獲得最佳素材的地方;那些從未寫入履歷的細節往往能決定一份申請的成敗。
  • 他們的求職平台檔案:他們使用哪些專業社群網站、求職網站和公司徵才入口;針對每個平台,提供個人檔案文字(貼上或匯出)、公開個人檔案連結以及儲存在該處的任何履歷檔案。
  • 限制條件:地點、通勤或搬遷意願、薪資底線、僱傭類型(員工或承包商)、離職通知期、語言能力。
  • 其他正在進行的申請,以便後續的修改不會與其產生矛盾。

保持一份簡短的已確認事實摘要,並隨時參考。不要重複問同一個問題。

第一階段 - 職位與公司研究

取得完整的職位說明文字。然後進行研究,在可使用網路搜尋時進行搜尋:

  • 公司:規模、據點、產品或服務、所有權、近期新聞、重組或成長狀況;
  • 該職位在組織中可能的位置:向誰報告、團隊規模、是新設職位還是遞補職位;
  • 職稱不一致:比較職位說明的標題、內文以及電子郵件或申請系統中的任何職稱。當它們不一致時,較小的那個通常是真實的工作內容。請標示出來。

註明資料來源。將任何推斷出的資訊標記為推斷。

第二階段 - 適配報告與決策關卡

產出 references/fit-report.md 中所描述的報告:一個逐項需求對照表、優勢、真正的差距、風險(地點、搬遷、過度或資格不足、產業距離、任期模式、職涯空白期、語言)以及結論。

然後暫停,提供三個選項與建議:

  • 全面申請 - 客製化履歷、求職信、招募聯繫。
  • 輕量申請 - 使用現有履歷,不產出新文件,花五分鐘。
  • 不申請 - 附上理由,以及什麼樣的職位更適合。

在使用者做出選擇之前,不要建立任何文件。

第三階段 - 差距策略

針對對職位描述重要的每個差距,選擇以下其中一種:

  • 橋接 - 求職者有相關的真實經驗。使用職位說明的詞彙來描述該經驗,但不要聲稱擁有欠缺的那項技能。 範例: 職位要求 S&OP(銷售與營運規劃);求職者從未執行過正式的 S&OP 流程,但曾主持過一次與銷售和生產部門的月度會議,以分配有限的產能。應寫「主持每月與銷售和生產部門的供需平衡會議」,而不是「主導 S&OP」。
  • 誠實說明 - 沒有橋接的可能。在求職信中,用平實的語言說一次,並說明候選人帶來了什麼替代價值。一個由求職者自己指出的差距,看起來像是判斷力;而一個由招募人員發現的差距,則看起來像是隱瞞。
  • 準備 - 在任何情況下,寫出面試中可能會針對此差距提出的問題以及一個誠實的回答(第九階段)。

第四階段 - 履歷:兩個版本

產出兩份版本並讓使用者選擇:

  • 版本 A - 求職者自己的檔案,在原地編輯以保留其版面配置。使用 scripts/docx_tools.py (使用 --dump 查看段落,然後提供一個 JSON 編輯清單)。如果求職者只有 PDF,請告知版本 A 無法在原地編輯,並僅提供版本 B,或者如果求職者要求,則使用 Word 重建其版面。
  • 版本 B - 範本,位於 assets/cv-template.docx:由專業履歷顧問製作的單欄、ATS 友善版面。使用 scripts/docx_tools.py 來填寫:使用 set 設定文字,使用 set_two_part 設定工作標題(左側為粗體的公司名稱和職稱,右側為日期),使用 clone_after 新增額外的項目符號,使用 drop 刪除未使用的行。若要新增一個工作,請在上一個工作的最後一個項目符號後複製一個工作標題,然後在其後複製項目符號。

寫作規則請見 references/cv-and-cover-letter.md。在完成前,執行:

python scripts/keyword_gap.py posting.txt cv.docx --terms "term one, term two, ..."

自行從職位說明的需求要點中選取術語;自動模式僅作為粗略的備用方案。針對每個遺漏的術語:僅在情況屬實時加入(規則一),否則將其移至面試準備中。

第五階段 - 求職信

一頁,與所選履歷使用相同的視覺風格(相同字型、相同姓名標題)。規則與結構請見 references/cv-and-cover-letter.md。簡而言之:以僱主的問題或求職者最有力的證明開頭,使用兩到三個附帶數字的具體故事,誠實地說明最大的差距一次,在讀者提問前回答任何顯而易見的問題(搬遷、職涯空白期、資歷等級),結尾不要哀求。

第六階段 - 在所有求職平台上同步個人檔案

遵循 references/profiles-and-outreach.md。根據新的履歷和所有正在進行的申請,審查求職者擁有的每個平台(專業社群網站、求職網站、公司徵才入口)的個人檔案:職稱與日期、標題、摘要、技能、儲存的履歷檔案及其被平台解析的結果、地點、薪資與可見性設定。提出能符合所有正在進行申請的修改建議;如果某項修改對此申請有利但會與其他申請衝突,請說明清楚並讓使用者選擇。為履歷的聯絡欄位推薦一個乾淨的個人檔案連結(在 LinkedIn 上,使用包含姓名和一個領域關鍵詞的自訂 URL)。平台設定可能會改變:在提供逐步說明之前,請先查閱平台當前的說明頁面。

第七階段 - 發送前檢查

在每個檔案發送前執行:

python scripts/docx_check.py cv.docx cover_letter.docx

它會報告隱藏或白色文字、浮水印、註解、追蹤修訂、不可見字元、中繼資料(作者、標題、範本名稱以及履歷服務在自訂屬性中留下的追蹤 ID)、ATS 問題(表格、文字方塊、頁首中的聯絡資訊)以及使寫作聽起來過於通用的陳腔濫調或對比模式。修正所有隱藏內容和中繼資料的問題。將寫作訊號視為提示:用求職者自己的話重寫,不要只是替換同義詞。然後告訴使用者使用 Word 本身的「另存新 PDF」功能來匯出 PDF,不要使用線上轉換器,並將信件大聲朗讀一遍。

第八階段 - 使用者審閱

以簡短清單顯示改變了什麼以及原因。直接將使用者的修正套用到檔案中(不要重新打字),重新執行第七階段,然後交付。

第九階段 - 招募聯繫與面試準備

  • 給招募人員或職位發布者的訊息以及給前同事的訊息:請見 references/profiles-and-outreach.md。人性化、具體、簡短。透過一個具體的理由來表達興趣,而不是使用形容詞。
  • 面試準備:像招募人員一樣閱讀履歷和求職信,列出他們會提出的問題,並根據求職者的真實經歷草擬答案。務必涵蓋:自我介紹、為什麼選擇這家公司、為什麼離開上一間公司、職涯空白期、短期任職(約不到三年)或頻繁變動、非常長的任期、過度資格、最大的弱點、與利害關係人的衝突、一次協商、來自第三階段的差距、薪資與離職通知期。單向視訊面試指導與薪資方法:請見 references/interview-prep.md。

第十階段 - 申請後

維護申請追蹤表,並遵循 references/after-applying.md 中的時機與回覆指引。請求職者貼上他們收到的任何回覆。

  • 正面回覆:準備下一輪面試,包括求職者應該提出的問題(團隊規模、預算所有權、彙報關係、該職位為何空缺)。
  • 負面回覆:草擬一封簡短、得體的回覆,請求給予回饋。將任何給出的理由視為下一次申請的數據,而不是一個要去反駁的論點。

檔案

路徑用途
assets/cv-template.docxATS 友善的履歷範本(版本 B)
scripts/docx_tools.py原地編輯 .docx 檔案而不破壞格式
scripts/docx_check.py檢查隱藏內容、中繼資料、ATS 與寫作訊號
scripts/keyword_gap.py找出職位說明中在履歷裡遺漏的術語
references/intake.md職涯故事的問題清單
references/fit-report.md適配報告格式、資歷與風險訊號
references/cv-and-cover-letter.md寫作規則、ATS 規則、範例
references/profiles-and-outreach.md所有求職平台上的個人檔案、個人檔案連結、訊息草稿
references/interview-prep.md題庫、回答方法、視訊面試、薪資
references/after-applying.md追蹤表、後續追蹤、解讀訊號、回覆草稿

腳本需要 Python 3 和 python-docx(執行 pip install python-docx)。如果無法在環境中執行,請手動執行相同的檢查:參考文件中描述了每項檢查。

相關技能