boss-hiring-assistant
星标16
分支4
更新时间2026年4月15日 09:45
面向 BOSS 直聘招聘流程的中文 skill。默认先做简历筛选，也支持站内沟通和飞书约面。
安装
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
SKILL.md
readonly来源
下载
相关职业SOC
基于 SOC 职业分类
菜单
面向 BOSS 直聘招聘流程的中文 skill。默认先做简历筛选，也支持站内沟通和飞书约面。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | boss-hiring-assistant |
| description | 面向 BOSS 直聘招聘流程的中文 skill。默认先做简历筛选，也支持站内沟通和飞书约面。 |
龙虾执行本 skill 时，必须按下面的优先级理解规则：
如果低优先级内容与高优先级内容冲突，一律以高优先级内容为准。
这个 skill 只做三类服务，并且三类服务必须分开理解、分开执行：
boss-screening
只负责读取岗位、读取候选人、筛选、分类、汇报。boss-chat
只负责 BOSS 站内沟通。boss-scheduling
只负责候选人已确认时间后的飞书约面。如果用户没有明确指定服务类型，默认先进入 boss-screening。
不要把三类服务混在同一轮里自由串行。
用户首次安装这个 skill 后，必须先用中文向用户做一个简短介绍，再进入任何具体执行。
介绍内容至少包含：
boss-screening：简历筛选和周期汇报boss-chat：BOSS 站内沟通boss-scheduling：飞书 bot 约面boss-screening 开始boss-screening 可覆盖的候选人范围：
boss-screening 的核心规则是：按每个 JD 的每日目标候选人数来筛选，而不是机械按小时运行boss-screeningboss-chatboss-scheduling如果用户没有明确选择，默认建议先从 boss-screening 开始。
在这一步没有完成前，不要：
BOSS 页面上的所有读取、点击、切换线程、打开详情、发送消息，都必须先遵守：
这是一条硬规则，不是建议。
对于 web-access 的 eval 能力，必须先做最小探针验证请求写法正确，再执行复杂逻辑。
不要在 eval 传参方式未确认时直接跑复杂脚本。
对于 Boss 聊天页中的在线简历读取，默认优先走“左侧点击候选人卡片 + 右侧简历面板提取”的路径，不要先假设会跳转到独立 URL。
在 Boss 任务中，默认只允许操作用户当前已经登录的 Boss tab。 不要为了进入招聘后台或职位管理而新建 tab、新建窗口或新建浏览器上下文。
如果当前已登录 tab 存在，就必须复用它的 targetId 和同一 browserContextId。
不要通过 web-access /new 直接新开 Boss 页面再尝试进入后台。
如果 targetId 变化，不要立即要求用户确认登录状态。
必须先按 browser-routing.md 中的规则自动重新绑定 Boss target，并做低成本登录态探针。
在 BOSS 页面读取中，截图、OCR、图像理解默认彻底禁止。
如果 web-access 读取失败：
2 次web-access 已尝试失败web-access只要进入 BOSS 站内消息发送，必须先读取并执行：
不要把该文档当参考说明。 不要再自行重新设计 DOM 路径、前端事件路径、子代理方案。
如果候选人线程都没有成功打开，就不得继续做输入框查找和发送动作。 但在暂停前，必须先把“自动打开候选人线程”的标准路径和有限备用路径走完。 不要一失败就要求用户代为点击候选人。
如果标准路径失败，下一步必须优先走低 token 的分层自动诊断，而不是直接进入长时间试错或大段脚本探索。
发送 Boss 站内消息时，必须做候选人身份校验，避免把给 A 的消息发给 B。
发送按钮点击路径也必须受控：
web-access clickAtbtn.click() 只允许作为一次性兜底，不得作为默认主路径特别是在批量打招呼时，不允许把 DOM click 当成标准实现。
对于“索要附件简历”类消息，发送后还必须继续跟进：
如果是批量打招呼或批量推进消息，还必须额外遵守：
如果首条打招呼发生在推荐页，还必须额外遵守：
data-* 标记，再用 CSS selector 调 clickAt 或 clickpaused_for_boss_contact_quota_exhausted，保留已筛选候选人，等待权益恢复或用户开通更多权益Boss 相关浏览器控制默认应由主执行流完成。
不要为了普通页面读取、进入后台、读取 JD、读取候选人列表、发送标准消息，而默认启动子代理接管浏览器。
只有在用户明确要求，或主执行流已经卡在非页面业务逻辑问题时，才允许考虑子代理。
简历筛选：
站内沟通：
飞书约面：
在介绍完三类服务之后，再告诉用户该服务对应的强制前置条件。
所有服务共用的强制前置条件：
browser-use。web-access。
https://github.com/eze-is/web-accessweb-access。web-access 已经接管当前 BOSS 任务。此外，对于 boss-screening，还有一个额外阻断条件：
如果这些通用前置条件没有完成，禁止继续：
如果用户还没有先在 Chrome 中登录 Boss 招聘者页面，也禁止开始“接管浏览器”这一步。
如果 boss-screening 的每日目标人数未明确，也禁止开始筛选。
不要自行搜索 web-access 的安装来源。
默认由龙虾先尝试代为安装；只有代装失败、权限不足或环境阻塞时，才让用户手动安装，并直接提供上面的 GitHub 链接。
对于 browser-use 等浏览器 skill，也默认由龙虾先代为禁用或移除。
不要先反问用户“是否已经禁用”。
完成后直接向用户汇报“已禁用/已移除”，只有在代办失败时才再向用户说明阻塞原因。
服务专属前置条件必须按需引导，不要一次性全部抛给用户：
boss-screening：只需要通用前置条件boss-chat：需要通用前置条件，以及用户已明确批准哪些候选人进入沟通boss-scheduling：需要通用前置条件，以及用户已选择候选人进入约面；飞书 bot 的配置和授权只在第一次真实创建日程时再引导不要跳过这些条件自行脑补默认答案。
如果当前环境里缺少：
company-policy.yamlapproval-policy.yaml不要直接反问用户“筛选标准是什么”。
正确顺序必须是：
默认标准的第一来源是 JD。 用户补充的是：
boss-screening 的核心不是“每小时扫一次”，而是：
龙虾应当围绕这个目标去筛选全渠道候选人，包括：
首次进入 boss-screening 时，必须优先确认：
如果用户没有给出目标人数，龙虾必须主动追问，而不是直接按固定时间节奏开始跑。
如果用户只给了时间节奏、没有给每日目标人数，仍然视为信息不完整，必须继续确认每日目标人数。
新一轮筛选默认主对象不是“当前可见候选人”，而是“当前仍未处理的未读候选人”。
默认应优先覆盖：
默认不进入新一轮扫描范围：
只有在这些条件下才允许重扫旧候选人：
对于不同来源，判断依据也不同：
inbound_chat：以页面未读信号为主，任务记忆为辅recommended_feed：以任务记忆为主，页面信号为辅search_results：以任务记忆为主，页面信号为辅对于 recommended_feed，还要额外注意：
时间相关规则现在是辅助规则，不是主规则。
可配置项包括：
如果用户没有指定这些辅助规则，可采用默认值：
09:00-17:0060 分钟汇报一次但无论是否采用默认时间规则，筛选服务都必须围绕“每日目标候选人数”推进。
每次汇报至少要包含：
每次汇报都要分别向用户确认：
如果用户尚未确认推进动作，不要自行把候选人推进到 boss-chat 或 boss-scheduling。
飞书只允许走 bot 路径。
用户负责：
App ID 和 App Secret龙虾负责：
App ID / App Secret龙虾不得：
第一次真的要创建飞书日程时，才去确认 bot 是否已配置、授权是否已完成。
所有强约束动作失败后，都必须进入“可恢复暂停态”，而不是继续长时间试错。
暂停时必须告诉用户：
不得把“继续试试看”当成默认策略。