jd-loop-routing

star 0

當用戶要在 resume-tailor 前，從 JD 與 LinkedIn People 校準產生薄版 role-only contract / routing_brief.md 時使用。只判斷這份工作的 role loop、correct pool、wrong pool、must-prove、cannot-borrow、front-door nouns / high-risk nouns 與 role_ai_relevance；不讀 resume、不做候選人證據映射。

ringda By ringda schedule Updated 6/4/2026
play_arrow Run Skill in Manus View GitHub

name: jd-loop-routing description: 在 resume-tailor 前，從 JD 與 LinkedIn People calibration 產生薄版、role-only 的 routing_brief.md；定義 role_read、role loop、correct pool、resume_frontstage_direction、wrong pool、must-prove、cannot-borrow、front-door/high-risk nouns、transferable capability primitive + JD work-object map 與 role_ai_relevance，不讀 resume evidence。

JD Loop Routing

目的

這個 skill 是 resume-tailor 前的 Role Contract generator。它先回答：這份工作到底在找什麼人，再讓後續流程去看 Xin 的 resume。

它只回答 role-side 問題：

這份 JD 在這家公司裡是哪條工作線？
JD 開場第一眼是在找什麼樣的人、支援哪個 team、要改善什麼 business outcome？
HM 第一眼會把這個 role 放進哪個 pool？
resume-tailor 第一刀應該先落在哪個 role-native work object / action / output？
哪些相鄰 pool 是 trap？
任何候選人要被約，必須證明哪些可遷移的工作能力？
這些能力在本 JD 裡對應到哪些 task / stakeholder / problem / output？
哪些 JD / org nouns 真實存在，但沒有直接證據時不能當 prior ownership 寫？
AI / automation / analytics 對這份 role 是前門、支援、背景，還是風險？

不要讀 resume.md、SSOT resumes、experience anchors、projects 或舊的 tailor_analysis_*。Candidate evidence mapping 屬於 resume-tailor。

邊界

  • linkedin-people 提供 live org / title cluster / peer truth source / company context evidence，寫在 network_brief.md 與 people_calibration.json。
  • jd-loop-routing 把 jd.md + network_brief.md + people_calibration.json 收斂成薄版 routing_brief.md。
  • resume-tailor 讀 routing_brief.md 與 resume，才做 current resume pool、pool gap、usable evidence、section translation 與 writeback。

若 resume-tailor 冷讀後發現 role contract 本身錯了，不在 tailor_analysis 裡自行改一套；回到這個 skill 修 routing_brief.md。

何時使用

用在：

  • LinkedIn People 完成後，要產生或複核 routing_brief.md；
  • 使用者想知道「這份工作到底是哪條 role lane」；
  • resume-tailor 前需要確認 correct pool / wrong pool / cannot-borrow；
  • 視覺 artifact、connect note 或 hiring memo 前，需要先把 role loop 定清楚；
  • People blocked、沒有 LinkedIn surface，仍要用 jd.md 做 best-available fallback contract。

若使用者的問題已經是「這份 resume 現在會被讀成誰」「哪段經驗能接」「Summary 怎麼改」，改用 resume-tailor。

先讀什麼

最小正式 source：

  1. 80-applications/{folder}/jd.md
  2. 若有 LinkedIn People：
    • 80-applications/{folder}/network_brief.md
    • 80-applications/{folder}/people_calibration.json
  3. 只有要複核既有 contract 時，才讀：
    • 80-applications/{folder}/routing_brief.md

不要讀：

  • resume.md
  • tailor_analysis_*
  • shared/ssot-core/XinXuan_Resume.md
  • experience anchors 或 candidate source material

若 network_brief.md 內有舊版 resume implication / candidate-specific prose，只能當歷史雜訊；Role Contract 仍只吸收 JD / People 的 role-side 訊號。

People Gate

若這筆需要 people-calibrated routing：

  • people_calibration_stage='calibrated' 且 people_resume_lift='routing_ready'：可產生正式 role contract。
  • people_resume_lift='review_required'：先判斷 People 判池是否要人工校準，或既有 routing_brief.md 是否要重做；不要自動覆蓋。
  • blocked / incomplete / failed：不要稱為正式 calibrated contract。只有用戶要求 best-available fallback 時，才用 jd.md 產生 fallback，並標明 people calibration incomplete。
    • incomplete 常見成因是 People 撈到相鄰 org / org context（例如同公司的 analytics org、leadership、TA），但沒撈到 exact-lane peer truth。這種情況的 fallback 不是「沒料硬撐」也不是「直接放棄」：JD 若本身清楚自包，就以 JD 為 role-loop 主真相，把相鄰 org 當佐證（證明 lane 真實、role 屬哪個 function），但不可升級成 peer truth / confirmed reporting line。把缺 named peer 寫進 known_unknowns，people_title_cluster 用 adjacent context 標清楚「佐證、非 peer」。
    • 反之，若 People 連相鄰 org 都沒有、只有追蹤者雜訊或全空，而 JD 又薄，就停在 blocker，不要為了交差硬產 contract。判準是「有沒有足以支撐第一刀的 role 真相」，不是「檔案有沒有產出」。

Role Contract 欄位

routing_brief.md 必須是薄版 role-only contract。每欄只寫決策，不寫長篇推理；語言要讓下游一眼看出這份 role 的正確人池、日常工作線、resume 前台第一刀、可遷移能力地圖與 claim ceiling。

role_read

用一句人話保留 JD opening / front-door ask：這份 role 第一眼想找什麼樣的人、支援哪個 team、要改善什麼 business outcome。這是 HM 開始看履歷前的入口濾鏡，不是 resume Summary。

role_read 是 JD front-door read；correct_pool 是 routing 決策，回答這份職缺該被哪個 HM / org pool 接住、後續 resume 前台語言往哪裡翻。兩者可以相互呼應，但不要寫成兩段重複或漂移的 pool 描述。

這裡不要描述 Xin 能做什麼，不要寫 candidate evidence，也不要把用詞升級成候選人的 claim。

role_loop

這份工作每天反覆處理的 loop。先講 workstream 與 day-to-day work，不要先抽成空泛的 workflow 詞或抽象能力。

用 bottom-layer capability 讀法描述：

input / object -> judgment or action -> stakeholder -> output / handoff / decision -> failure risk

這裡不要描述 Xin 能做什麼。

bottom_layer_capabilities

把 JD 要的能力展開成 resume-tailor 可以拿來對照的能力地圖。每一項先用不綁單一產業或 JD 情境的 capability primitive 命名，再說明這個能力在本 JD 裡對應到哪些 work object / friction / stakeholder / output。這不是抽 title、keyword、requirement，也不是把 JD 改寫成 communication、problem solving 這種 generic soft skill；它是在問：這份工作反覆需要哪種可遷移的工作判斷，而這種判斷在本 role 裡會碰到什麼具體工作物件。

好的條目應該有兩層：

{portable capability primitive}: 本 JD 的 inputs / work objects -> judgment or action -> stakeholder -> output / handoff / decision -> claim boundary

capability primitive 要能離開這份 JD 仍然成立，例如 ambiguous technical problem framing、structured signal interpretation、assumption and validation discipline、reviewable handoff synthesis、domain-tool ramp under supervision。不要把 primitive 命名成 transportation analysis、proposal operations、HubSpot workflow 這類已經綁住單一 JD 情境的詞；那些要放在後半段的 JD mapping。

沿用 role_loop 的同一套讀法，把工作拆成 3-6 個 role-side capabilities。每個能力都要讓後續 tailor 看得出：

  • 不綁 JD 的底層能力 primitive 是什麼；
  • 這個能力在本 role 裡實際處理什麼 work object / friction；
  • 要做什麼判斷、整理、分析或協調；
  • 服務誰，交出什麼 output / handoff / decision；
  • 後續 resume-tailor 要小心哪些 overclaim、wrong-pool risk 或不能借的 ownership。

這裡仍然不看 Xin，也不填 candidate evidence。它只回答：等等 tailor 要先拿哪些可遷移能力去問「Xin 哪段 true story 處理過相似 judgment / task / stakeholder / problem？」再把能對上的能力翻成本 JD 的 work object / output。不是拿來直接把 JD keyword 塞進 resume。

correct_pool

這份職缺第一眼應被放進哪個 role pool。命名要具體到 resume-tailor 能知道前台語言該往哪裡翻。

resume_frontstage_direction

用 2-4 個短點把 role-only landing 顯式寫出來，讓下一手不用從多個欄位重新猜第一刀。這欄不是 Summary、不是候選人賣點、也不讀 Xin 的證據；它只回答本 role 的履歷前台語言應該先往哪裡落。

必須回答：

  • HM 第一眼應該把任何合格候選人讀成哪種 role-native person；
  • resume-tailor 第一刀應該先 foreground 哪個 work object / action / output；
  • 哪個看起來很亮但會導錯池的方向不能領頁。

好的寫法是「先落在 X，不要先落在 Y」。X 要能回到 role_loop 的日常工作物件、stakeholder 或 output；Y 要能回到 wrong_pool、cannot_borrow 或 high_risk_nouns。不要寫成「突出分析能力」「展現溝通能力」這種 generic resume 建議。

wrong_pool

看起來像、但其實會把 candidate 讀歪的 role pools。具體命名，不寫抽象 adjacent candidate，並說清楚為什麼這種讀法會傷害 routing。

must_prove

任何候選人要被約，履歷必須證明的 2-4 件事。要能回到 role_loop 的日常工作物件 / stakeholder / output；不要只寫 abstract skills，也不要映射到某段 candidate experience。

cannot_borrow

沒有直接經驗時不能借的 domain / platform / ownership / seniority / regulated responsibility / quota / pipeline / product / technical depth。這是 claim ceiling，不是 candidate critique。

front_door_nouns

JD / People 看到的 role vocabulary。這不是 candidate-safe claim 清單；只是這份 role 的前門語言。

high_risk_nouns

Role 裡真實存在，但候選人沒有直接證據時不能當 prior ownership 寫的詞。後續 tailor 可在 JD context 或降格翻譯時小心使用，但不能自動升級成 candidate claim。

people_title_cluster

LinkedIn People 看到的近職稱 / HM / peer / routing owner title cluster。TA / recruiter 只當 routing owner，不用來判 role lane。

known_unknowns

未確認但會影響 role read 的點，例如 direct HM、team placement、work mix、sponsorship screen、tool stack。

role_ai_relevance

只看 JD + company / people surface，判斷這份 role 會如何讀 AI / automation / analytics。不要把「JD 沒提 AI」寫成「AI 無關」；2026 的合理預設是 AI literacy 已是許多 entry / analyst / ops / coordination 角色的工作方法 baseline，只是未必是 front-door requirement。

這欄不是候選人的 AI 賣點，也不是新增 resume schema；它要給 resume-tailor 一個 role-side 翻譯方向：若 AI-assisted source-grounded workflow 可見，應該落到哪個 role-native work object、quality standard、review / validation point、handoff 或 decision output。目標不是找「平均 HM 看了不討厭」的中性說法，而是判斷這份 role 是否會因為工作更穩、更可驗證、更可交接而買單。

這欄要分清三件事：

  • front-door appetite：JD / People 是否明確買 AI adoption、automation、workflow design、AI-assisted analysis、business systems、enablement 或 ops tooling。
  • baseline work-method appetite：即使 JD 沒提 AI，這份 role 是否需要 source grounding、context setting、success criteria、validation checks、review / approval boundaries、exception handling、handoff clarity、documentation、decision quality、adoption support 或 reusable workflow。review / approval 只在風險、正式紀錄、對外動作或 regulated context 需要時當邊界，不要把它寫成 generic AI differentiator。
  • wrong-pool / overclaim risk：哪些 AI nouns 會把 candidate 誤讀成 AI product owner、automation architect、production AI engineer、prompt engineer，或把 support evidence 升級成平台 / architecture ownership。
  • translation target：如果 AI / workflow 只能作為方法出現，它要翻成哪個 role-native 工作品質，例如 campaign reporting quality、CRM record hygiene、account research relevance、client handoff reliability、implementation QA、source-grounded decision support，而不是停在 generic AI differentiator。

輸出時用人話說明 AI 應該如何可見：foreground、baseline/support、tool-name bounded、backstage only，或 avoid。avoid 只能用在 AI wording 會真實傷害 role routing、違反雇主使用限制、或誤導 ownership 時；不能只因為 JD 沒寫 AI 就選 avoid。這不是對 Xin AI evidence 的判斷；resume-tailor 之後才決定她的 AI / workflow proof 怎麼放。

寫法

建議格式：

# Role Contract - {Company} {Title}

> Date: YYYY-MM-DD
> Mode: role-only `jd-loop-routing`
> Runtime Job ID: `{jobId}`
> People gate: `{stage} / {resume_lift}` 或 `people_calibration_incomplete`

## role_read
...

## role_loop
...

## bottom_layer_capabilities
- ...

## correct_pool
...

## resume_frontstage_direction
- ...

## wrong_pool
...

## must_prove
- ...

## cannot_borrow
- ...

## front_door_nouns
- ...

## high_risk_nouns
- ...

## people_title_cluster
- ...

## known_unknowns
- ...

## role_ai_relevance
...

## [user] Prompt Log
- ...

工作順序

  1. 先抽 role_read：保留 JD opening / front-door ask，用一句人話說出 candidate archetype、supported team 與 business outcome。
  2. 再抽 role_loop：這份工作是在跑作業線、case flow、customer journey，還是 analysis / control loop？起點、轉換段、輸出與 failure risk 是什麼？
  3. 展開 bottom_layer_capabilities：先抽不綁 JD 情境的 capability primitive，再接本 role 的 task / stakeholder / problem / output mapping。這一步是給 resume-tailor 的能力對照地圖，不是候選人映射。
  4. 再定 correct_pool / wrong_pool：這份 role 應該被哪個 HM / org pool 接住？哪些相鄰 pool 會讓 resume-tailor 寫錯？
  5. 寫 resume_frontstage_direction：把第一刀 landing 顯式壓成 role-only 前台方向，說清楚先落在哪個 work object / action / output，不能被哪個亮眼但錯池的方向帶走。
  6. 寫 must_prove / cannot_borrow：must-prove 對回 day-to-day work；cannot-borrow 定 claim ceiling。
  7. 分開 front_door_nouns / high_risk_nouns：前者是 role vocabulary，後者是 resume-tailor 後續要小心的 domain / ownership risk。
  8. 補 people_title_cluster / known_unknowns / role_ai_relevance：People 只校準 role lane；不要因為旁支 automation / AI / product title 就覆蓋主池。

Folder Mode Writeback

若上下文已有明確 80-applications/{folder}：

  • 寫到 80-applications/{folder}/routing_brief.md。
  • 若能查到 jobId，同回合走 runtime milestone writer：
const now = new Date().toISOString()
await markMilestone(jobId, {
  fields: {
    ps_status: 'created',
    ps_created_at: now,
    ps_path: `80-applications/${folder}/routing_brief.md`,
  },
})

ps_status 在現有 schema 仍讀成「JD 後、tailor 前的 strategy / routing 里程碑」；不為了改名臨時動 DB schema。

Conversation Harvesting

若用戶補了會改變 role contract 的方向，記到 routing_brief.md 末尾的 ## [user] Prompt Log。

只記：

  • 改了 role_read / JD opening / front-door archetype 的讀法；
  • 改了 correct pool / wrong pool 的判準；
  • 新增 resume frontstage direction、bottom-layer capability、must-prove、cannot-borrow、high-risk nouns 或 role_ai_relevance 邊界；
  • People / org calibration。

不要記純確認、短命聊天、或 candidate-specific resume wording。

不做什麼

  • 不讀或改 resume.md。
  • 不讀 candidate evidence。
  • 不做 lead proof / support proof 分工。
  • 不決定 Summary、experience label、bullet wording。
  • 不 export resume。
  • 不替代 resume-tailor audits。
Install via CLI
npx skills add https://github.com/ringda/xin-job-hunting --skill jd-loop-routing
Repository Details
star Stars 0
call_split Forks 0
navigation Branch main
article Path SKILL.md
More from Creator
ringda
ringda Explore all skills →