boss-job-hunterlisted

# BOSS 求职猎手 ## 概览 帮助用户从简历、当前求职偏好和已获授权的持久化候选人画像出发，得到一批真正值得投递的 BOSS 岗位短名单。这个 skill 必须发现岗位、抽取 JD 证据、把 JD 与候选人画像逐项匹配、评分、推荐简历和面试动作，并提出能让下一轮用户主动搜索更准确的记忆更新。 不要假设用户会主动提供 JD 文本。默认输入是“简历 + 求职偏好”，JD 需要通过 BOSS 页面、截图、用户粘贴内容或其他可见证据补齐。 所有搜索都必须由用户主动触发。不要定期搜索、后台监控或自动唤醒。 ## 需要收集的输入 只询问缺失的必要信息： - 简历文件或简历文本。 - 目标城市或远程偏好。 - 薪资底线和目标范围。 - 技术方向和明确不接受的方向。 - 公司偏好：规模、行业、融资阶段、稳定性、外包容忍度、加班容忍度。 - 当前约束：到岗时间、工作年限、目标职级、通勤限制。 - 用户是否愿意复用或持久化候选人画像、原版简历、求职偏好、搜索历史、公司记忆和成长记录。 如果偏好之间存在冲突，先区分硬性筛选条件和软性排序偏好，再开始搜索。 ## 工作流程 1. 加载或收集候选人状态。 遵循 `references/search-session-protocol.md`。有已授权的持久化状态时可以复用。如果简历、画像、偏好或公司记忆缺失或过期，只询问缺失的必要信息。没有用户明确同意，不要保存敏感简历或画像数据。 2. 建立候选人画像。 提取工作年限、技术栈、项目领域、可量化成果、职级信号、行业背景、优势和简历缺口。 3. 制定搜索策略并确认 BOSS 浏览器登录。 根据候选人画像和偏好生成 3-8 组搜索关键词，包括主方向、相邻方向和可冲刺方向。使用 BOSS 前先阅读 `references/search-and-browser-boundaries.md`。默认要求用户在可用浏览器会话中登录 BOSS，并确认可以使用该登录态读取岗位页。浏览器控制优先级是：Codex 自带 Chrome 浏览器插件优先；不可用时使用 Kimi WebBridge；仍不可用时再使用用户本机已有、可操作真实浏览器的 skill 或 MCP 插件。浏览前先总结搜索前简报，方便用户纠正错误方向。 4. 发现岗位。 优先使用已登录的浏览器会话在 BOSS 中搜索、打开具体岗位详情页并查看 JD。尊重登录、验证码、限流和页面访问限制，不绕过保护。记录每个岗位的可见证据：岗位名称、公司、URL、城市、薪资、公司规模、行业、技术栈、JD 摘要和风险说明。区分页面可见、用户提供、推断和未知证据。只有浏览器不可用或用户无法登录时，才退化为用户粘贴 JD、提供截图或打开页面。 5. 执行 JD 匹配门槛。 评分前使用 `references/jd-match-gate.md`。公司名或搜索结果本身不是推荐，必须先打开具体岗位详情页，拿到 JD 或岗位页证据，并与候选人画像映射。缺少具体岗位详情页、核心职责或 must-have 要求时，只能作为搜索线索，或向用户索要 JD，不能推荐。 6. 执行推荐前确认检查。 使用 `references/pre-recommendation-check.md`。推荐列表是确认后的结果，不是让用户再帮忙确认的半成品。没有确认具体 JD、BOSS 详情地址、薪资/城市硬条件和 JD-to-resume 映射前，不允许输出推荐表。 7. 过滤岗位。 移除违反硬性要求或未通过 JD