MartinezAgullo/job-offer-evaluator

工作邀请评估器

用户会定期收到招聘人员消息，并且每次都想进行同样的评估：这个职位是否合适？真实的（净）条件是否比现有的好？应该问什么问题？如何回复？不同合同类型和国家的毛收入容易产生误导，因此本技能的核心是基于用户提供的事实进行净到手收入对比，绝不基于记忆或假设。

第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. 简历。 从 <data_dir>/profile.md 读取 cv_path。如果其为 ?、缺失或文件未找到，请向用户索要简历（路径或粘贴的文本）并将路径存储在配置文件中；没有简历则不评估匹配度。简历是技能和资历的真实来源；不要编造经验。
2. LinkedIn（可选，尽力而为）。 LinkedIn 通常会在登录墙后阻止自动读取，因此如果有 LinkedIn 的 URL，尝试一次，如果被阻止则静默跳过。仅在邀请中的内容与之相关时才向用户索要粘贴的简历或 PDF 导出（例如招聘人员声称看到用户的简历，或者简历缺少职位所需的内容）。简历仍然是主要来源；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. 财务基线和合同结构

• 当前毛基本工资和年度目标奖金/浮动部分（以及发放的可靠性）。
• 合同类型：西班牙无限期/临时雇佣、EOR、自雇/自由职业、美国 W2 与 1099、其他。
• 支付期数（12或14）。这会改变月度现金流，但不影响年度净收入，但在比较月度数据时很重要。

2. 地点和税务上下文

• 当前纳税的国家和城市/地区，以及在邀请下将纳税的国家和地区（税率因西班牙自治区、瑞士州、美国州而异）。
• 任何特殊制度或扣除（Beckham/输入制度、残疾、抚养人、抵押贷款、地区扣除）。

3. 福利和自付费用

• 当前非现金福利：私人健康保险、养老金匹配、餐补、交通补贴、股票、培训预算，每项给出近似年欧元价值。
• 自己承担的工作相关费用：未补偿的通勤、设备、共享办公空间。

4. 工作方式及成本影响

• 当前工作模式（完全远程、每周几天的混合、在办公室）以及他们偏好的模式以及能容忍多少办公室时间。
• 如果是混合或办公室办公：每月通勤成本和每周通勤时间。

5. 决策阈值

• 使跳槽值得的最低净收入增幅，例如“+15% 有效净收入”（建议工作变更为 +15-20%，对于 B2B 或不稳定的邀请则更高），并让他们覆盖此值。询问硬性红线（必须到岗、仅限合同工、特定行业）。

每个邀请（不存储在配置文件中）：对于 B2B/按小时计费，实际可计费小时数和合同之间的预期间隙；对于非欧元薪酬，外汇汇率（第2步会获取）。

第2步：净到手收入对比

比较当前工作和邀请的净收入，而非毛收入。净收入是指扣除社保、所得税以及自由职业者的自雇成本（自雇费用、代理费、保险）后的金额。然后加上非现金福利的年价值，减去自付工作成本，得到有效净收入。

• 外汇： 对于非欧元邀请，运行 python3 scripts/fetch_fx.py USD（通过 frankfurter.dev 获取 ECB 汇率）并使用该汇率，注明日期。如果查询失败，请向用户询问汇率。
• 运行脚本： python3 scripts/net_compare.py（参见 --help）。当前工作在 --country 中纳税，邀请在 --offer-country 中纳税（默认相同）。它接收当前合同类型、毛收入（包括预期浮动部分）、福利、额外成本、地区调整和邀请详情，并输出净收入、有效净收入（欧元）、增量，以及如果使用 --threshold，则输出增幅是否达标。--irpf-shift（别名 --region-adjust）是当前国家的地区调整，--offer-region-adjust 是邀请国家的地区调整；说明您传递了什么。
  • 西班牙： 调整是 IRPF 百分点的偏移（低税率地区如马德里约为 -0.01 到 -0.015，高税率地区为 +0.01，如果不确定则为 0）。
  • 美国： 仅联邦税、单身申报人、标准扣除、不考虑 401(k)/HSA、不考虑 QBI 扣除。调整是用户的平均州所得税率（TX/FL/WA 为 0，其他州请询问）。对于 1099 工作，将自付健康保险包含在 --expenses 中；对于 W-2 邀请，将雇主的健康保险和 401(k) 匹配放入 --offer-benefits 中。
  • 货币： 邀请金额以邀请国家货币计价。--fx 将薪酬货币转换为该货币（在美国纳税、领取美元薪水：--fx 1；在西班牙纳税、领取美元薪水：--fx 0.89），--to-eur 将邀请国家货币转换为欧元（在美国纳税、领取美元薪水：--fx 1 --to-eur 0.89）。福利和额外成本始终为欧元。
• 税务模块： 国家规则位于 scripts/tax/<cc>.py，其数据在 data/tax_<cc>.json 中；西班牙和美国已存在。对于其他国家（瑞士、英国等），根据当前税率档次和社保规则手动估算净收入（搜索当前年度的数据），展示主要步骤，并标记为粗略估算。如果来自该国家的邀请持续出现，建议构建一个模块（references/adding-a-country.md）。
• 过时检查： net_compare.py 在税务数据过期或未经验证时打印 WARNING。当您看到此信息时，告知用户并提供下面的刷新步骤，然后再依赖这些数字。
• 始终说明所使用的假设： 汇率、可计费小时数、费用、地区、纳税年度。说明结果是估算值，实际决策需由会计师/税务顾问确认。
• 对于 B2B： 净收入仍然忽略了员工免费获得的东西：带薪假期、带薪病假、失业保障、养老金积累、雇主缴款。给出“等效员工毛收入”，并标记合同风险（单一客户、通知条款、虚假自雇风险、排他性）。

第3步：匹配度和条件

匹配度（简历 vs 职位）。 满分10分，并附一行理由。列出匹配项（附简历证据）、差距（真实的与仅未列出的）、以及相较于他们当前职位的实际日常工作内容和资历要求。招聘人员的工作职称往往隐藏着比宣传的更窄的工作范围，因此说明该职位可能是什么样子。

条件（优先级：净收入 > 远程 > 发展轨迹）。使用 references/benefits-checklist.md 获取福利清单，并将每个项目标记为已说明 / 法定默认 / 未知：

• 薪酬和福利（健康、退休匹配、带薪休假、病假、育儿假），特别是对于西班牙以外、法定默认值不同的职位。
• 工作模式与其陈述偏好对比，加上时区重叠和差旅。
• 职业发展轨迹：成长路径、自主权、公司和客户声誉、工作是否朝着配置文件中 target_roles_and_topics 的方向发展或偏离、参与稳定性。

招聘方信号。 使用 references/recruiter-signals.md 阅读消息本身（隐藏的最终客户、模板式外联、“高达”薪资、合同形式与角色、范围与职称），列出发现的标志和好迹象。可选地搜索公司和最终客户的声誉。

第4步：裁决、问题、回复

• 裁决：追求、先询问或拒绝，附上决定原因的2-3点，并明确对照其阈值和红线进行核查。
• 给招聘人员的问题：仅2-3个答案足以改变决策的问题（通常是实际薪酬结构和带薪休假条款、实际范围和团队、合同期限和终止条款）。不要问通用填充问题。
• 回复草稿，一旦决策明确或用户陈述，以招聘人员的语言撰写，简短，使用用户的语气。拒绝：感谢对方，可加一行理由。要求详细信息：有条件的兴趣加上问题；不要透露当前薪资（如果需要，提供期望范围）。如果仍未决定，简要提供两个草稿。一段落为一行（不硬换行），尽量减少破折号的使用。

第5步：记录邀请

裁决后，向 <data_dir>/offers_log.md 追加一行（日期、公司和最终客户、职位、合同、提供的薪酬、有效净收入增量、匹配度、裁决、结果/评论）。如果用户未表示要记录，则在写入前先询问。当用户之后告知您结果（已回复、已拒绝、已面试）时，更新该行的“结果”。

年度税务数据刷新

每个 data/tax_<cc>.json 包含该国家/地区的所得税率、社保或工资税率及上限、扣除项（西班牙还包含自雇费用表），并带有 tax_year、verified_on 和 verified_by。每年一月数据会过期，因此在脚本警告时、日历年份超过 tax_year 时或用户要求时刷新。流程：

1. 搜索文件中 sources 列出的官方来源。西班牙：AEAT 获取 IRPF 税率表和个人最低限额，社会保障获取 RETA 费用表、最大缴费基数和员工费率（含 MEI）。美国：IRS 通胀调整 Rev. Proc. 获取税率档次和标准扣除，SSA 获取社会保障工资基数；重新审阅附加医疗保险税和自雇税规则（第一个版本来自一般知识）。
2. 向用户展示每个更改值的 before/after 对比，并附上来源链接。不要静默覆盖：错误的税务数字会悄悄破坏所有未来的比较，因此需要先由用户确认。
3. 用户批准后，编辑 JSON，将 tax_year、verified_on 设置为今天，verified_by 设置为实际读取的来源（仅在您确实对照官方页面验证后，才删除“未检查”措辞）。
4. 重新运行一个示例比较，检查是否出错。

可选的定时提醒：如果用户想在1月收到真正的提醒，主动提供使用智能体或操作系统提供的任何调度机制（cron、预定的智能体任务、日历事件）来安排一个会话，用于运行此刷新。

输出格式

保持可扫描性，不要写成文章。严格使用以下部分，按此顺序：

1. TL;DR（2行）：裁决、匹配分数、有效净收入增量 vs 阈值。
2. 净收入对比：一个表格，包含毛收入、社保/费用、所得税、净收入、福利、自付费用、有效净收入行，以及当前 / 邀请 / 增量列；下方列出假设列表。
3. 匹配度：分数、匹配项、差距、可能的实际范围。
4. 条件：关于远程、福利、发展轨迹、风险的简短表格。
5. 招聘方信号（每行简短）和给招聘人员的问题：2-3个编号项。
6. 回复草稿。
7. 假设或未验证项：项目符号列表。

不要写使用表格或项目符号就能表达的散文段落。