Job Change Profile

job-change-profile

転職支援スキル群で利用者データの単一の原本となる profile.json を作る、または更新するとき、このスキル1つで聞き取りから納品までの手順がそろう。構造化した想起手がかり（企業→在籍期間→役割→担当プロジェクト→成果の時系列枠）で聞き取り、実績の定量化・スキルの棚卸し・転職の軸の構造化を支援する。作成・機械的な検証・独立監査を経て profile.json を確定する。成果物は後続のサブスキル（企業研究・応募書類作成・面接対策・試験対策・自己分析）がすべて入力として読む。

profile.json の中核は、職務経歴・実績・スキルの内容と、それが求人要件へどう対応するかという点（relevance）である。根拠は references/profile-methods.md にある。ただし関連性（relevance）は応募先ごとに変わるため、profile.json には固定して保持しない。応募時に応募書類サブスキルが再構成する。本スキルは、応募先ごとの relevance を再構成できる粒度（職務単位の経歴・成果・定量値）の正確性・網羅性・最新性を保つことに責任を持つ。

目的と原則

1. 構造化した想起手がかりで聞き取る。 自由記述に委ねず、時系列（在籍期間）×プロジェクト単位の枠に沿って聞く。構造化面接は非構造化面接の約2倍の妥当性を持つ。時系列やテーマをまたいで暦の出来事を手がかりにする聞き方も、自伝的記憶の構造に沿って想起の完全性・一貫性を高める（references/elicitation-guide.md）。

2. 利用者の申告を事実として記録し、疑わない。 述べられた経歴・実績・数値は、そのまま事実として記録する。証拠書類の提示を求めず、「それは証明できるか」「本当にそうか」という形の問いを置かない。本人が自分から不確かだと述べた値だけ、その旨をメモへ残す（references/elicitation-guide.md）。聞き取り側に許される操作は、表現の具体化・数値化の支援・転職市場で通る表現への置き換えの3つに限り、いずれも本人の申告に事実を足さない。置き換えは本人へ示して了承を得た文だけを使う（references/answer-handling.md）。創作の抑止は、作成担当が聞き取りメモにある事実だけを使い、監査担当が成果物とメモを照合することで働く（原則6）。

3. 実績は定量化を推奨しつつ、無理に数値化しない。 定量化困難な業務には、代替表現の型を用意する（型の一覧の原本は references/quantification-guide.md）。ただしすべての実績へ機械的に数値を付けることは強制しない。数値は本人が述べたものに限り、聞き取り側から候補の値を提案しない。過剰な数値は書類全体の信頼を毀損する（references/quantification-guide.md）。

3-2. 回答の様式は利用者が決める。 選択式で聞いた問いに自由記述で答えても、複数の問いへ一度に答えても、経歴を一気に語っても、その答え方を直さず、受け取った内容を項目へ振り分けて未回答の項目だけを聞く。派遣・業務委託・出向・休業・起業などの定型でない経歴は、定型に合わせて書き換えず、そのまま記録する（references/answer-handling.md）。

4. スキルは専門スキルと転用可能スキルを分ける。 入口は technical / business / languages / certifications とする。補助分類として、厚労省ポータブルスキルの9要素（対課題5・対人4）を持つ。この2層で、専門スキルと転用可能スキルを分けて棚卸しする。汎用分類の一律適用に依存しない（references/profile-methods.md）。

5. 転職の軸は必須条件を少数に絞り、再評価を前提とする。 譲れない条件と望ましい条件の分離は維持する。そのうえで、必須条件（conditions[level=must] と work_character_preferences[desire=must] の合計）は3件程度までに絞る。優先順位と再評価時期はメタ情報として残す。選好は聞き取りの過程で構成され経時変化するため、軸を固定した結論として扱わない（references/profile-methods.md）。深掘り（建設的言い換え・根拠づけ）は job-change-self-analysis へ誘導する。

6. 事実を創作・補完しない。 profile.json に載せる経歴・実績・数値は、聞き取りメモに記録のある範囲に限る。実績値・期間・役職を推測で補完しない。経歴の詐称は懲戒・内定取消につながり、社会保険等の突合により高い確率で発覚する（references/profile-methods.md）。

7. 初回は骨格までを確定し、深掘りは必要になる工程の直前まで先送りする。 初回作成は既定では初回の範囲として、職歴の骨格・現職の役割・転職理由・主要な条件・作業特性8件までで profile.json を成立させる。実績の定量化・スキルの棚卸し・企業スコアの採点軸・条件の網羅は、下流の工程が要るようになった時点でセクション更新として行う。所要時間が延びるほど途中で離脱する割合が上がり、対話という形式そのものは入力を速くしないためである（references/elicitation-guide.md）。

8. 手元の書類を読めるなら読む。ただし要求しない。 職務経歴書・履歴書・レジュメがあれば、職歴の骨格はそこから取り込み、確認だけで済ませられる。ファイルの提出を条件にせず、無ければ従来どおり対話で聞く。ファイルから読んだ事実は本人の申告と同格であり、物証として扱わない（原則2）。

9. 個人情報を外部へ送信しない。 profile.json に含まれる個人情報は、検索クエリ・fetch・外部 API を含む一切の外部送信に用いない。対象の列挙と役割ごとの可否の原本は hub の {HUB_SKILL_DIR}/references/pii-boundary.md にある。本スキルは境界の内側にある profile.json・profile_interview_notes.md を作る側である。writer（job-change-profile-writer）と auditor（job-change-profile-auditor）は、いずれも Web 送信手段を持たない。このため、これらのパスを渡してよい。

範囲外

次は本スキルの範囲外とする。依頼された場合は、対応できない旨と、代わりの担当・行動を伝える。

• 強みの根拠づけ・キャリアの物語化・退職理由の建設的言い換え。 job-change-self-analysis が担う。本スキルは軸の構造（reasons の短文）までを扱い、深掘りは job-change-self-analysis へ誘導する。
• 応募書類の文面作成。 職務経歴書・履歴書・英文レジュメ・志望動機書の執筆は job-change-documents が担う。本スキルはその土台データ（profile.json）を作り、渡す。
• 企業別の要件対応づけ（アピールマッピング）。 応募先ごとに変わる relevance は、profile へ固定して保持しない。応募時に job-change-documents が profile.json の職務単位データから再構成する。
• 企業研究。 企業の理念・事業・評判の調査は job-change-company-research が担う。

パスの解決

利用者データの置き場所は設定ファイルの記述だけで決まる。既定の置き場所は無い。本文で {DATA_ROOT} と書いた箇所は、次のコマンドが返す data_root に読み替える。

hub（job-change-support）から振り分けられた場合は、hub が解決済みの {DATA_ROOT} を渡す。単独で起動された場合は、作業のどの段階よりも先に次を実行する。

python {HUB_SKILL_DIR}/scripts/jc_config.py --show

{SKILL_DIR} は本スキルの絶対パス、{HUB_SKILL_DIR} は同じ配置先にある job-change-support の絶対パスを指す。探索順序を含む設定ファイルの仕様は docs/configuration.md にある。

データ配置

利用者データは、非公開ディレクトリ {DATA_ROOT}/career-private/ に置く。本スキルが読み書きするパスは次のとおり。

• profile.json のフィールド仕様・記入基準・検証規則の原本は hub（job-change-support）の references/profile-format.md にある。本スキルはこれを編集しない。
• 記入例は hub の assets/profile_example.json（架空の人物）にある。本スキル側に複製を置かない。
• スキル本体フォルダー（skills/job-change-profile/）に利用者データを置かない。
• career-private/ が未作成の場合は、必要になった時点で本スキルが作る。

初回と深掘りの分担

初回作成は、既定では初回の範囲にとどめる。初回に確定させるのは次の5つに限る。

• 職歴の骨格（career_history[] の company・period・role。書類の取り込みがあれば確認だけで済む）
• 現職の役割（basic.current_role）
• 転職理由（job_change_axis.reasons を1件以上）
• 主要な条件（conditions[]。希望年収の下限と、勤務地・リモートの制約があれば足りる。件数は少なくてよい）
• 作業特性8件（work_character_preferences。選択式2回で埋まり、スキーマ上は省略できない）

Step 2（職務ごとの深掘り）・Step 3（スキル棚卸し）・企業スコアの採点軸・条件の網羅と優先順位付け・現年収の実額は深掘り項目とし、初回は既定で飛ばす。利用者がその場で続けたいと述べた場合は、そのまま続けてよい。

飛ばした項目は「セクション更新」モードで深掘りし、それを要する工程の直前に置く。

初回の範囲だけを埋めた profile.json は validate_profile.py を PASS する。定量的な metric が1件もない・skills が空・targets が空・level=must の条件に priority が付いていない、の4件の WARN は、初回の範囲では想定内である。Step 5 の差し戻しの理由にしない（優先順位付けも深掘り項目である）。

パイプライン

受付から納品まで Step 0〜6 を順に進める。{SKILL_DIR} は本スキルの絶対パス、{HUB_SKILL_DIR} は hub（job-change-support）の絶対パスに読み替える。{PROFILE} は profile.json、{NOTES} は profile_interview_notes.md の絶対パスを指す。

聞き取りは本体セッションが AskUserQuestion で行う（サブエージェントは利用者と対話できない）。選択式を中心に、1回の AskUserQuestion につき最大4問・各質問は最大4択とする。1つの問いで複数の答えを受けたい場合は multiSelect: true を使い、問いを分けて回数を増やさない。自由記述で聞くのは、企業名・在籍期間・実績値など、選択式にできない項目だけである。質問は references/question-bank.md のあらかじめ定めた構造化質問を使い、反すうを招く自由回答の質問を置かない。利用者へ発する質問文と選択肢のラベルは敬体で書く。選択肢を事前に列挙できる質問については、references/question-bank.md に確定した文言があり、それをそのまま使う（言い回しをその場で作らない）。

選択式は聞き取り側の問いの形であり、利用者の答え方を縛らない。利用者が自由記述や一括の回答で答えた場合は、受け取った内容を項目へ振り分けて {NOTES} へ書き、答えの無かった項目だけを次に聞く。同じ項目を選択式で聞き直さない。回答の様式ごとの対応と、申告を疑わない問いの型の原本は references/answer-handling.md にある。

Step 0 前提確認

• profile.json の有無を確認する。あれば hub の validate_profile.py で検証し、現状を把握する。
• モードを AskUserQuestion で確認する。選択肢は「初回作成」「セクション更新（basic / 職歴 / スキル / 軸 / 志望 / 年収のどれか）」「全面点検」。
• 更新モードでは、既存の profile.json を読み、対象セクションのみを聞き取り対象にする。
• 「初回作成」を選んだ場合は、上記「初回と深掘りの分担」の範囲で進める。深掘りまで一度に済ませたいと利用者が述べた場合だけ、Step 2 以降をその場で続ける。

Step 1 職歴の骨格（時系列）

既存書類の取り込み

聞き取りを始める前に、職務経歴書・履歴書・レジュメなどのファイル（Word・PDF・テキスト・Markdown）が手元にあるかを1問で聞く。文言は references/question-bank.md にある。提出を求めない。 無いと答えた場合は、そのまま下記の対話へ進む。あると答えた場合だけパスを受け取って読む。

PDF・テキスト・Markdown は Read で読む。.docx は Read が扱わないため、Bash で Python の標準ライブラリを使って本文を読み出す。docx は ZIP であり、本文は word/document.xml にある。段落の終端 </w:p> を改行へ置き換えてからタグを除いて、段落の区切りを保つ。タグを除いたあとに html.unescape を通すのは、XML では &・<・> がエンティティで書かれるためである。戻さないままだと、「A&B株式会社」が A&B株式会社 のまま profile.json へ書き込まれる。

python -c "import zipfile,re,html,sys; xml=zipfile.ZipFile(sys.argv[1]).read('word/document.xml').decode('utf-8'); xml=re.sub(r'</w:p>','\n',xml); print(html.unescape(re.sub(r'<[^>]+>','',xml)))" {書類のパス}

表組みのセルも段落として出るため、表で書かれた職務経歴書でも企業名・在籍期間・役職は読み出せる。ただし行と列の対応は失われるので、表が主体の書類では読み取った並びを利用者に確かめる。.doc（旧形式）は ZIP 形式を持たないため、この方法では読めない。PDF かテキストでの用意を勧め、それが難しければ対話で聞く。スキャン画像だけの PDF は Read で文字が読めないことがある。LinkedIn のプロフィールを PDF に保存する機能は英語の文字だけに対応しており、日本語のプロフィールでは本文が欠ける。読めない箇所を推測で埋めず、その項目だけを対話で聞く。SES 業界のスキルシートは、担当工程が記号で書かれていることが多い。記号の意味を本人に確かめてから responsibilities へ転記する。

読めたら、企業名・在籍期間・役職・担当業務を抽出して {NOTES} へ転記し、抽出した一覧を利用者へ示して「違うところだけ教えてください」と聞く（違うところだけを申告してもらう。全項目への同意を求めない）。訂正のあった項目だけをメモへ 訂正: の行で足す。

業務内容・実績の記述のような長文は、企業名・在籍期間・役職に比べて抽出の精度が落ちる。長文はメモへ転記する時点で （要確認） を付け、利用者の確認が済んだ時点で外す。

ファイルから読んだ事実は、対話で述べられた申告と同格に扱う（原則8）。物証として扱わず、他の項目の裏取りに使わない。

骨格の確定

古い順または新しい順に、企業×在籍期間×役割の一覧をまず確定する。書類から取り込んだ場合は、その一覧が骨格であり、訂正の申告を受けた時点で確定とする。取り込んだ項目を対話で聞き直さない。転職・異動・昇進などの転機を時系列の手がかりにする。根拠は references/elicitation-guide.md にある。在籍中の職は period を 〜現在 と書く。

骨格が出そろったら、同じ時期に複数の職に就いていた期間があったかを1問で確かめる（兼務・出向・副業・自営）。あった場合は、その職も career_history の1件として企業・期間・役割を聞き、どの立場での在籍かを role に書き分ける（例「業務委託（副業）」）。在籍期間が重なることは不整合ではない。

派遣・SES・客先常駐・業務委託・出向のように雇用主と就業先が分かれる職は、雇用主を company に、就業先を assignment に書く。雇用形態は本人の言葉のまま employment_type に書く。休業・起業・公務員・海外勤務などの定型でない経歴の記録のしかたは references/answer-handling.md の表に従い、定型に合わせて書き換えない。

並行の在籍を含めて骨格が確定したら、どの職歴の在籍期間にも含まれない期間（6か月以上）を機械的に検出し、その場で説明と期間中の活動を聞き、career_gaps に記録する。判定は全職歴の在籍期間の和集合に対して行う。隣どうしの職歴だけを見ると、本業と重なる副業がある場合に存在しない空白を検出する。

Step 2 職務ごとの深掘り（プロジェクト単位）

この Step は深掘り項目に当たる（初回では飛ばし、応募書類の作成の直前にセクション更新として行う）。

職歴1件ずつ、担当業務（responsibilities）→主要プロジェクト→実績（achievements）の順で聞く。実績については「何を・どの規模で・どう変えたか」を聞く。定量化は references/quantification-guide.md の型で支援する。数値が出ない実績は無理に数値化せず、工夫や評価された点を具体化して metric を null にする。利用者が述べた数値は、その出所を問わずそのまま記録する。幅や概算で述べた数値は、幅や概算のまま記録する。

口語や曖昧な言い方（「手伝った」「作った」「いろいろやった」）は、references/answer-handling.md の置き換え表に従って書類で通る言い方の案を示し、本人が了承した文だけを {NOTES} へ 言い換え（本人了承）: の行で残す。役割の表現は本人の申告した関与の範囲を超えて上げない。

1つの職の中で複数の案件を並行して担当していた場合は、実績1件ごとに案件の呼び名（project）と、その案件の期間（period）も聞き、どの案件のいつの成果かを区別できるようにする。担当した案件が1つだけの職では、この2つを聞かない。

Step 3 スキル棚卸し

同じく深掘り項目であり、応募書類の作成の直前に Step 2 とまとめて行う。Step 2 の発話を材料にするためである。

technical / business / languages / certifications を、Step 2 の発話から逆引きで確認する（候補を選択肢として提示し、選ばせる）。そのうえで、厚労省ポータブルスキルの9要素（対課題5・対人4）を選択式で確認し、skills.portable に入れる（category は「対課題」か「対人」）。要件との対応づけは応募時に応募書類サブスキルが行う旨を伝える。詳細は references/profile-methods.md のスキル分類の節にある。

未経験の職種への転換を望む利用者では、Step 2 の発話から作った候補が志望職種と重ならない。この場合は、志望職種（targets.roles）で一般に求められるスキルの候補も併せて示し、保有しているものだけを選ばせる。候補を示すことは保有を仮定することではない。選ばれなかった候補は書かない。

Step 4 転職の軸・志望対象・年収

この Step で初回の範囲として聞くのは、reasons（1件以上必須）→ 主要な条件（conditions。希望年収の下限と、勤務地・リモートの制約があれば足りる）→ 作業特性の希望（work_character_preferences の8件）までである。企業スコアの採点軸・条件の網羅と優先順位付け・targets・現年収の実額は深掘り項目であり、初回は飛ばす。現年収のように立ち入った問いを初回へ置かないためでもある（references/elicitation-guide.md）。

そのまま深掘りまで進める場合は、reasons → 条件（conditions）→ 作業特性の希望（work_character_preferences）→ 企業スコアの採点軸（company_score_axes）→ targets → salary の順で聞く。軸の建設的言い換え・根拠づけは job-change-self-analysis へ誘導する。根拠は references/profile-methods.md の must/want の節による。

条件の構造化

条件は、軸・演算子・しきい値の形に構造化して job_change_axis.conditions[] へ入れる（自由文のまま置かない）。フィールド仕様は hub の references/profile-format.md、軸の語彙は hub の references/screening-axes.md を読む。

条件1件ごとに、次を AskUserQuestion で確定する（1回の質問で複数の条件をまとめて扱ってよい）。

1. 譲れない条件か、あれば望ましい条件か（level）。
2. 8軸のどれに当たるか、または軸に当てはまらない質的条件か（axis）。
3. 軸に当たる場合は、比較のしかたとしきい値（operator・value・unit）。例: 残業なら「1か月あたりの上限時間」、年間休日なら「年間の下限日数」、年収なら「下限額」。
4. どこで確認できるか（verification）。値域の原本は hub の references/profile-format.md にあり、選択肢との対応は references/question-bank.md の「確認手段」の文言にある。

軸に当てはまらない質的条件（例「モダンな技術スタックが整備されていること」）は、axis を null、operator を qualitative、value を null にする。verification は research または interview とする。この種の条件は求人検索の分類には用いられず、企業研究と面接での確認へ回る旨を利用者へ伝える。

作業特性の希望

8つの作業特性それぞれについて、希望度（must / important / neutral / not_required）を確認する。特性の定義は hub の references/screening-axes.md にある。2回の AskUserQuestion（4特性ずつ）で埋まる。

「どちらでもよい」「不要である」も明示的に選ばせる。desire=must を選んだ特性には、本人の言葉での条件文（statement）を1文で聞く。

clear_completion・solo_completable・short_feedback の3特性は求人票からは判定できない。これらに must や important を選んだ場合は、面接での確認事項になる旨をその場で伝える。

必須条件の件数

conditions[level=must] と work_character_preferences[desire=must] の合計が4件以上になったら、優先順位を付けて絞る対話を挟む。順位と再評価時期を job_change_axis.priority_note へ残す。

企業スコアの採点軸

採点軸も深掘り項目であり、適合性評価の直前にセクション更新として扱う。初回で飛ばした場合は company_score_axes をフィールドごと書かない（空配列にしない）。

企業を0〜100点で採点する軸と重みを決め、company_score_axes[] へ入れる。定量候補軸9個・点数への換算・重みの配分の規則は job-change-company-research の references/company-score-rubric.md にある。フィールド仕様は hub の references/profile-format.md を読む。次の順で決める。

1. 定量候補軸9個（処遇水準・年間休日総数・月平均の残業時間・有給休暇の取得率・離職率・男性の育児休業取得率・売上高の成長率・営業利益率・自己資本比率）を提示し、重視するものを選ばせる。1回の AskUserQuestion で3問に分け、各問が3軸を multiSelect: true で受ける（1問あたりの選択肢は最大4件のため、9軸を1問へは入れられない）。処遇水準（compensation_level）は既定で選択済みとし、外すかどうかだけ確認する。
2. 数値にならない事柄で重視したいものがあれば、定性軸として作る。ラベル（呼び名）・定義（何をもってそう言うか）・判定条件（何が確認できたら何点か。3段階程度）を利用者と決める。判定条件まで決められない事柄は採点に入れず、面接での確認事項へ回す旨をその場で伝える。
3. 選んだ軸への重みの配分（合計100）と、定量軸で使う基準を1回の AskUserQuestion でまとめて聞く。第1問は重みの配分で、選んだ軸の数に応じた配分案を選択肢に置き、当てはまるものが無ければ自由記述で受ける。第2問は、統計に基づく既定の基準をそのまま使うか、自分の基準を使うかである。重みが0になる軸は置かず、採点に入れない軸は外す。
4. 自分の基準を使うと答えた軸は、100点となる水準（full）と0点となる水準（zero）を自由記述で聞き、thresholds へ入れる。数値の聞き取りであり、AskUserQuestion は使わない。処遇水準（compensation_level）は既定の基準を持たないため、必ず聞く。現年収を zero、希望年収（またはそれを上回る水準）を full に置く聞き方を既定とし、本人が別の置き方を望めばそれに従う。
5. 配分した重みで架空2社を採点し、点数の高い側と「実際にどちらを選ぶか」への答えが一致するかを検算する。軸名どうしの抽象的な比較ではなく、企業像の比較で聞く（例: 「A社は年収が現職より120万円高いが残業が月30時間、B社は年収が現職と同水準で残業が月5時間。どちらを選ぶか」）。

検算が食い違った場合は、配分を見直すか、配分と実際の選択の両方を記録して利用者へ提示する。どちらが本当の判断かをスキルの側で決めない。軸を1つも選ばない場合は、企業スコアが出ない旨をその場で伝える。

採点軸と必須条件の食い違い

選んだ採点軸と重みが、conditions[level=must] や work_character_preferences の希望度と食い違うことがある。例: 残業の上限を必須条件にしているのに monthly_overtime を軸に選んでいない。compensation_level に最大の重みを置いたのに年収の条件が want のままである。

どちらが本当かをスキルの側で決めない。食い違う組み合わせをそのまま利用者へ提示し、どう扱うか（軸や重みを見直す・必須条件を見直す・両方このままにする）を本人に選ばせる。聞き取りメモには、提示した食い違いと、利用者が選んだ扱いの両方を残す。

1.x からの移行

既存の profile.json が schema_version 1.0 または 1.1 の場合、must_conditions / want_conditions の自由文が残っている。機械的に軸へ割り付けない。 自由文からしきい値を推測することは事実の創作に当たる。

移行モードでは、既存の自由文を1件ずつ提示し、上記「条件の構造化」の4項目を対話で確定する。全件を移し終えたら must_conditions / want_conditions を空配列にし、続けて作業特性8件と企業スコアの採点軸を確認する。最後に schema_version を 2.0 へ、updated_at を当日へ書き換える。

利用者が移行を望まない場合は 1.x のまま残す。その場合、求人検索の8軸判定と適合性評価の作業特性の次元が使えない旨を1回だけ伝える。

Step 5 作成→機械的な検証→独立監査

聞き取りの結果は、その途中で本体セッションが {NOTES}（profile_interview_notes.md）へ逐次追記し集約しておく（中断再開に対応）。job-change-profile-writer エージェント（model: opus）を起動する。渡すのは {NOTES}・既存 {PROFILE}（更新時）・hub の references/profile-format.md・出力先 {PROFILE} である。作成担当はメモにある事実だけから profile.json を作成・更新する。戻り値を受け、本体セッションが hub の validate_profile.py を実行して ERROR 0 を確認する。続いて job-change-profile-auditor エージェント（model: opus、作成担当の判断理由を渡さない新規コンテキスト）を起動して監査する。verdict が BLOCK、または severity = must_fix の finding があれば Step 5 の作成へ差し戻す（最大2回。以降は利用者判断）。

この Step は初回の範囲でも従来どおり通す。初回の範囲だけを埋めた構成では、飛ばした深掘り項目に対応する WARN が出るが、飛ばした深掘り項目が空のままなのだから想定内であり、差し戻しの理由にしない。利用者へは、欠落としてではなく「深掘りがこれからである」ものとして伝える。

Step 6 更新運用の案内と納品

更新運用（実績が出るたびに追記し、少なくとも四半期に一度は見直す。応募書類へ書き起こすときは直近7〜10年を優先する）を案内する。あわせて updated_at を当日の日付へ書き換える。profile.json は下流のサブスキルの入力であって単体の読み物ではないため、整形したファイルは作らない。代わりに、何が書かれたか（職務要約・職歴の件数と在籍期間・スキル・転職の軸と必須条件・企業スコアの採点軸・年収）を利用者へ要約して示す。最後に、profile.json を入力に使える下流の作業を案内する。job-change-self-analysis の自己分析、job-change-company-research の企業研究、job-change-documents の応募書類作成である。また、初回の範囲で納品した場合は、飛ばした深掘り項目と、それを要する工程（上記「初回と深掘りの分担」の表）を1度だけ添える。その場で深掘りを促さない。最終メッセージは結論から述べる。中身の無い節・同じ内容の繰り返し・定型の前置きを置かない。

合否ゲートと差し戻し

パイプラインには1つの検証・監査ゲートがある。

差し戻し時は、監査の findings（target・evidence・fix）をそのまま作成担当へ渡し、反映後に Step 5 の機械的な検証から再度通す。2回の差し戻しで解消しない指摘は、未決事項として利用者へ判断を委ねてから納品する。例: 聞き取りメモに記録の無い数値が profile.json にある、という指摘は、聞き直すか削るかを利用者に選ばせる。機械的な検証の ERROR は、差し戻しの上限にかかわらず解消してから納品する。未解決が監査の finding だけである場合に限り、未決事項として明記したうえで納品してよい。

役割の実行（ハーネス別）

本スキルのパイプラインは、専門の役割へ作業を委ねる形で書いてある。役割の内容は references/roles/ に置き、これを原本とする。

ハーネス別の実行手順、起動する数の判断、作成と監査を分ける理由の原本は hub の {HUB_SKILL_DIR}/references/role-execution.md にある。

エージェントのモデル方針

機械的検査は hub の validate_profile.py が担う。model は各エージェントの frontmatter に固定済みであり、起動時に上書きしない。

スクリプトのCLI使用例

profile.json の検証には hub（job-change-support）の validate_profile.py を用いる（本スキルは検証スクリプトを持たない。二重管理しない）。終了コードは PASS で 0、FAIL で 1、WARN のみは PASS 扱いである。{HUB_SKILL_DIR} は hub の絶対パス、末尾のパスは検証対象の profile.json のパスに読み替える。

python {HUB_SKILL_DIR}/scripts/validate_profile.py {DATA_ROOT}/career-private/profile.json
python {HUB_SKILL_DIR}/scripts/validate_profile.py {DATA_ROOT}/career-private/profile.json --json

--json は結果を JSON 形式（status・error_count・warning_count・errors・warnings）で出力する。profile.json のフィールド仕様・検証規則の原本は hub の references/profile-format.md にある。記入例は hub の assets/profile_example.json を見る。

references 一覧