求人オファー評価ツール

求人オファー評価ツール は何をしますか？

ユーザーは定期的にリクルーターメッセージを受け取っており、毎回同じトリアージを求めています：その役割は適しているか、実際の（手取り）条件は現在より良いか、何を質問すべきか、どのように返信すべきか。契約形態や国が異なる総支給額は誤解を招くため、このスキルの中核は、ユーザーから提供された事実に基づく正味手取り額の比較であり、ユーザーが覚えていることや推測したことに基づいてはいけません。

ステップ 0: コンテキストを読み込む

個人データはスキルの外部に保存されるため、スキルの更新、コピー、公開によってデータが公開されたり上書きされることはありません。データフォルダ <data_dir> を以下の順序で一度解決します：

1. $JOB_SEARCH_DIR（設定されている場合）。
2. 使用中のエージェントのユーザーレベル設定フォルダ内の job-search/：Claude Code の場合は ~/.claude/job-search/、Codex CLI の場合は ~/.codex/job-search/、Gemini CLI の場合は ~/.gemini/job-search/。他のエージェントの場合は、同等のユーザーレベルフォルダを使用します。

スキル内やプロジェクトリポジトリ内のフォルダは絶対に使用しないでください。<data_dir> が存在しない場合は、作成し、このスキルから templates/profile.md と templates/offers_log.md をコピーし、使用したパスをユーザーに伝えてください。

1. CV。 <data_dir>/profile.md から cv_path を読み取ります。?、欠落、またはファイルが見つからない場合は、ユーザーにCV（パスまたは貼り付けテキスト）を尋ね、パスをプロファイルに保存します。CVなしで適合性を評価しないでください。CVはスキルとシニアリティに関する唯一の情報源であり、経験をでっち上げないでください。
2. LinkedIn（オプション、ベストエフォート）。 LinkedInは通常、自動読み取りをログイン壁でブロックするため、プロファイルに linkedin URL がある場合は一度だけ試行し、ブロックされた場合は静かにスキップします。オファーがそれに依存する場合（例：リクルーターがプロフィールについて主張している、またはCVに役割に必要なものが欠けている場合）にのみ、ユーザーに貼り付けたプロファイルやPDFエクスポートを尋ねてください。CVが優先され、LinkedInはリクルーターが見たもののクロスチェックに過ぎません。
3. プロファイル。 <data_dir>/profile.md を読み取ります（ステップ1を参照）。
4. 過去のオファー。 <data_dir>/offers_log.md にざっと目を通します。同じ会社やリクルーターが再び登場する場合、または給与が以前のオファーと比較して有用である場合に言及します。

ステップ 1: 確認またはインタビュー（質問し、推測しない）

給与額や条件は変化し、間違った仮定は静かに比較を台無しにします。

• プロファイルに値があり、last_verified が存在する場合： 保存された詳細の簡潔なサマリーを表示し、ユーザーに確認するか、変更点を尋ねます。? とマークされたフィールドまたはユーザーが修正したフィールドについてのみ質問をします。last_verified が6ヶ月以上前の場合はその旨を伝え、フィールドをより注意深く確認します。
• プロファイルが空または欠落している場合（初回実行時）： 以下の完全なインタビューを実行し、回答を <data_dir>/profile.md に書き込み、last_verified を今日の日付に設定します。
• 変更後は、profile.md を更新し（既存のレイアウトを維持）、次回の実行が簡単な確認で済むようにします。

質問はグループ化された1つのメッセージとして送信し（エージェントに構造化質問ツールがある場合はそれを使用）、不足しているオファーの詳細も一緒に送信します。

1. 経済的ベースラインと契約構造

• 現在の総基本給与と年間目標ボーナス/変動給（およびその支払い信頼性）。
• 契約タイプ：スペインの無期/有期雇用、EOR、自営業/フリーランス、米国W2 vs 1099、その他。
• 支払い分割回数（12回または14回）。これにより年間純額ではなく月々のキャッシュフローが変わりますが、月々の数値を比較する際に重要です。

2. 居住地と税務コンテキスト

• 現在課税されている国と都市/地域、およびオファーで課税される国と都市/地域（税率はスペインの自治州、スイスのカントン、米国の州などによって異なります）。
• 特別な制度や控除（ベッカム法/駐在員制度、障害、扶養家族、住宅ローン、地域控除）。

3. 福利厚生と自己負担費用

• 現在の非金銭的福利厚生：民間医療保険、年金マッチング、食事券、交通費補助、ストック、トレーニング予算。それぞれおおよその年間EUR価値を記載。
• ユーザー自身が負担する仕事関連費用：補償されない通勤、機器、コワーキング。

4. 勤務形態と費用への影響

• 現在の勤務形態（100%リモート、週単位のハイブリッド、オフィス勤務）とユーザーが希望する形態（許容できるオフィス勤務の日数を含む）。
• ハイブリッドまたはオフィス勤務の場合：月間通勤費用と週間通勤時間。

5. 意思決定の閾値

• 転職を検討する価値のある最低限の純増加率（例：「+15% 実効純額」）。転職には +15～20%程度、B2Bや不安定なオファーにはより高い値を提案し、ユーザーに上書きさせます。絶対的な拒否条件（オンサイト勤務、請負のみ、特定のセクター）について質問します。

オファーごと（プロファイルには保存されません）：B2B/時給の場合、現実的な年間請求可能時間と契約間の予想ギャップ。非EUR支払いの場合、為替レート（ステップ2で取得）。

ステップ 2: 正味手取り額の比較

現在の仕事とオファーの総額ではなく、純額を比較します。純額とは、社会保障、所得税、およびフリーランサーの場合は自営業費用（自治体負担金、顧問料、保険）を差し引いた後の金額です。次に、非金銭的福利厚生の年間価値を加算し、自己負担の仕事費用を差し引いて実効純額を算出します。

• 為替レート（FX）： 非EURのオファーの場合、python3 scripts/fetch_fx.py USD を実行し（frankfurter.dev経由のECBレート）、そのレートと日付を引用します。ルックアップが失敗した場合は、ユーザーにレートを尋ねてください。
• スクリプトの実行： python3 scripts/net_compare.py（--help を参照）。現在の仕事は --country で、オファーは --offer-country（デフォルト：同じ）で課税されます。現在の契約タイプ、総額（予想変動給を含む）、福利厚生、追加費用、地域調整、オファーの詳細を受け取り、純額、実効純額（EUR）、差分を出力し、--threshold を指定すると、増加が基準をクリアするかどうかを出力します。--irpf-shift（別名 --region-adjust）は現在の国の地域調整、--offer-region-adjust はオファー国の地域調整です。何を渡したかを必ず伝えてください。
  • スペイン（ES）： 調整はIRPFのパーセンテージポイントシフトです（低税率のマドリッド地域では約 -0.01～-0.015、高税率地域では +0.01、不明な場合は0）。
  • アメリカ合衆国（US）： 連邦のみ、単一申告者、標準控除、401(k)/HSAなし、QBI控除なし。調整はユーザーの平均州所得税率です（TX/FL/WAは0、それ以外は州を尋ねてください）。1099業務の場合は自己負担の健康保険を --expenses に含めます。W-2オファーの場合は雇用主の健康保険と401(k)マッチを --offer-benefits に入れます。
  • 通貨： オファー金額はオファー国の通貨です。--fx は給与通貨をその通貨に変換し（米ドル給与でスペインで課税：--fx 0.89）、--to-eur はオファー国の通貨をEURに変換します（米ドル給与で米国で課税：--fx 1 --to-eur 0.89）。福利厚生と追加費用は常にEURです。
• 税務モジュール： 国のルールは scripts/tax/<cc>.py に、数値は data/tax_<cc>.json にあります。スペイン（ES）とアメリカ合衆国（US）が存在します。他の国（スイス、英国など）の場合は、現在の税率区分と社会保障ルール（現在年度の数値をウェブ検索）から正味額を手動で見積もり、主要なステップを示し、大まかな見積もりとラベル付けします。その国からのオファーが続く場合は、モジュールの構築を提案します（references/adding-a-country.md）。
• 陳腐化チェック： net_compare.py は税務データが古いか未検証の場合に WARNING を出力します。表示された場合は、ユーザーに伝え、以下の更新手順を提供してから数値を信頼するようにしてください。
• 常に使用した前提条件（為替レート、請求可能時間、経費、地域、課税年度）を明記してください。結果は見積もりであり、実際の意思決定には税理士や顧問が確認する必要があることを伝えてください。
• B2Bの場合、正味額は従業員が無料で得られるもの（有給休暇、有給病気休暇、失業保護、年金積立、雇用主拠出）を無視します。「同等の従業員総額」を示し、契約リスク（単一クライアント、通知条件、偽装自営業のリスク、独占禁止条項）にフラグを立てます。

ステップ 3: 適合性と条件

適合性（CV vs 役割）。 10点満点でスコアリングし、理由を1行で説明します。一致点（CVの証拠付き）、ギャップ（実際の不足 vs 単にリストにないもの）、そして現在の役割と比較した実際の日々の業務とシニアリティの可能性をリストアップします。リクルーターの役職名は、宣伝されているよりも狭い仕事を隠していることが多いため、その役割が実際に何であるかを述べてください。

条件（優先順位：正味給与 > リモート > キャリアパス）。references/benefits-checklist.md を福利厚生リストに使用し、各項目を「明記あり / 法定デフォルト / 不明」のいずれかでマークします：

• 給与と福利厚生（健康保険、退職金マッチング、有給休暇、病気休暇、育児休暇）、特にスペイン国外の役割では法定デフォルトが異なるため注意。
• ユーザーの希望する勤務形態に対する実際の勤務形態、タイムゾーンの重複、出張。
• キャリアパス：成長の道筋、所有権、会社とクライアントの評判、その仕事がプロファイルの target_roles_and_topics に向かって構築されているか、それとも遠ざかっているか、契約の安定性。

リクルーター側のシグナル。 references/recruiter-signals.md を使用してメッセージ自体を読み取り（隠されたエンドクライアント、テンプレート化されたアプローチ、「最大」給与、契約形態と役割の不一致、範囲と肩書きの不一致）、見つかったフラグと良い兆候をリストアップします。オプションで、会社とエンドクライアントの評判をウェブ検索します。

ステップ 4: 評決、質問、返信

• 評決：追跡、まず質問、または辞退。決定した2～3の理由を、ユーザーの閾値と絶対拒否条件に対して明示的にチェックします。
• リクルーターへの質問：決定を覆す可能性のある2～3の質問のみ（通常は実際の給与構造と有給休暇条件、実際の範囲とチーム、契約期間と終了条件）。汎用的な埋め草は不要です。
• 返信文面：決定が明確になったとき、またはユーザーがそれを述べたときに、リクルーターの言語で、短く、ユーザーの口調で作成します。辞退：感謝の意を述べ、オプションで理由を1行。詳細を尋ねる：条件付きの関心と質問。現在の給与は明かさず、代わりに希望給与範囲を提示します（有用な場合）。まだ未決定の場合は、両方の文面を簡潔に提供します。1段落は1行（ハードラップなし）で、ダッシュは控えめに使用します。

ステップ 5: オファーを記録する

評決後、<data_dir>/offers_log.md に1行を追加します（日付、会社とエンドクライアント、役割、契約、提示された給与、実効純額差分、適合性、評決、結果/コメント）。ユーザーが記録すると言っていない場合は、書き込む前に確認します。後で、ユーザーが何が起こったか（返信した、辞退した、面接）を伝えたら、その行の結果を更新します。

年間税務データ更新

各 data/tax_<cc>.json には、その国の所得税スケール、社会保障または給与税率と上限、控除（スペインの場合は自治体負担金テーブルも）が含まれ、tax_year、verified_on、verified_by が設定されています。数値は毎年1月に古くなるため、スクリプトが警告したとき、暦年が tax_year を超えたとき、またはユーザーが要求したときに更新します。手順：

1. ファイルの sources にリストされている公式ソースを検索します。スペイン：IRPFスケールと個人最低額についてはAEAT、RETA負担金テーブル、最大拠出ベース、MEIを含む従業員負担率についてはSeguridad Social。米国：課税区分と標準控除についてはIRSのインフレ調整 Rev. Proc.、社会保障賃金ベースについてはSSA。追加メディケア税と自営業税ルールを再読します（初版は一般知識から取得）。
2. 変更されたすべての値について、ソースリンク付きの変更前/変更後の差分をユーザーに表示します。静かに上書きしないでください。間違った税額は将来のすべての比較を静かに破壊するため、ユーザーが最初に確認する必要があります。
3. ユーザーの承認後、JSONを編集し、tax_year、verified_on を今日の日付に設定し、verified_by を実際に読んだソースに設定します（実際に公式ページで確認した場合のみ、「NOT checked」という表現を削除します）。
4. サンプル比較を再実行して、何も壊れていないことを確認します。

スケジュールされたリマインダーはオプションです。ユーザーが1月に実際のリマインダーを希望する場合は、エージェントまたはOSが提供するスケジューリングメカニズム（cron、スケジュールされたエージェントタスク、カレンダーイベント）を使用して、この更新を実行するセッションを開くように設定することを提案します。

出力形式

エッセイではなく、スキャンしやすい形式にします。以下のセクションをこの順序で正確に使用します：

1. TL;DR（2行）：評決、適合性スコア、実効純額差分 vs 閾値。
2. 正味額比較：行「総額」「社会保障/負担金」「所得税」「正味額」「福利厚生」「自己負担費用」「実効純額」、列「現在」「オファー」「差分」の表。その下に前提条件リスト。
3. 適合性：スコア、一致点、ギャップ、実際の範囲の可能性。
4. 条件：リモート、福利厚生、キャリアパス、リスクに関する短い表。
5. リクルーターシグナル（それぞれ短い1行）とリクルーターへの質問：2～3の番号付き項目。
6. 返信文面。
7. 仮定または未検証：箇条書き。

表や箇条書きで十分な場面で散文段落を生成しないでください。