Imported from waltonwang-debug/boss-hiring-assistant-skill (SKILL.md). Install upstream with npx skills add waltonwang-debug/boss-hiring-assistant-skill. Copyright stays with the author.

Boss Hiring Assistant

执行优先级

龙虾执行本 skill 时，必须按下面的优先级理解规则：

1. 阻断式前置条件
2. 浏览器路由硬规则
3. 当前服务文档
4. 发送 recipe
5. 其他补充文档

如果低优先级内容与高优先级内容冲突，一律以高优先级内容为准。

目标

这个 skill 只做三类服务，并且三类服务必须分开理解、分开执行：

1. boss-screening 只负责读取岗位、读取候选人、筛选、分类、汇报。
2. boss-chat 只负责 BOSS 站内沟通。
3. boss-scheduling 只负责候选人已确认时间后的飞书约面。

如果用户没有明确指定服务类型，默认先进入 boss-screening。 不要把三类服务混在同一轮里自由串行。

首次安装后的介绍

用户首次安装这个 skill 后，必须先用中文向用户做一个简短介绍，再进入任何具体执行。

介绍内容至少包含：

1. 这个 skill 分成三类独立服务：
   • boss-screening：简历筛选和周期汇报
   • boss-chat：BOSS 站内沟通
   • boss-scheduling：飞书 bot 约面
2. 推荐用户先从 boss-screening 开始
3. 后两类服务按需启动，不必首次安装时一起配置
4. 在任何浏览器接管开始前，必须先让用户在 Chrome 或 Chromium 浏览器里打开并登录 BOSS 直聘招聘者页面
5. boss-screening 可覆盖的候选人范围：
   • 主动进入聊天列表或主动投递中的未读候选人
   • BOSS 推荐页面里的本轮未处理候选人
   • 搜索页面里的本轮未处理候选人（当账号具备搜索权益时）
6. boss-screening 的核心规则是：按每个 JD 的每日目标候选人数来筛选，而不是机械按小时运行
7. 新一轮筛选默认只处理“未读/未处理候选人”，不重复重扫已经处理完成的旧候选人，除非满足重扫条件
8. 如果用户不指定每日目标人数，就先让用户为每个 JD 设定目标；时间窗口和汇报节奏只是辅助设置
9. 启动方式：
   • 用户说“先帮我做简历筛选”时进入 boss-screening
   • 用户说“帮我联系这些候选人”时进入 boss-chat
   • 用户说“帮我给这些候选人约面”时进入 boss-scheduling

如果用户没有明确选择，默认建议先从 boss-screening 开始。

在这一步没有完成前，不要：

• 直接进入 Boss 页面读取
• 直接开始筛选
• 直接开始发消息
• 直接开始飞书约面

顶层硬规则

1. 浏览器访问只允许走 web-access

BOSS 页面上的所有读取、点击、切换线程、打开详情、发送消息，都必须先遵守：

• browser-routing.md

这是一条硬规则，不是建议。

对于 web-access 的 eval 能力，必须先做最小探针验证请求写法正确，再执行复杂逻辑。 不要在 eval 传参方式未确认时直接跑复杂脚本。

对于 Boss 聊天页中的在线简历读取，默认优先走“左侧点击候选人卡片 + 右侧简历面板提取”的路径，不要先假设会跳转到独立 URL。

在 Boss 任务中，默认只允许操作用户当前已经登录的 Boss tab。 不要为了进入招聘后台或职位管理而新建 tab、新建窗口或新建浏览器上下文。

如果当前已登录 tab 存在，就必须复用它的 targetId 和同一 browserContextId。 不要通过 web-access /new 直接新开 Boss 页面再尝试进入后台。

如果 targetId 变化，不要立即要求用户确认登录状态。 必须先按 browser-routing.md 中的规则自动重新绑定 Boss target，并做低成本登录态探针。

1.1 截图默认彻底禁止

在 BOSS 页面读取中，截图、OCR、图像理解默认彻底禁止。

如果 web-access 读取失败：

1. 允许在同一路径内最多再尝试 2 次
2. 如果仍失败，不允许自动切换到截图路径
3. 必须先向用户说明：
   • web-access 已尝试失败
   • 现在可以改走截图等异常方案
   • 这些方案可能增加 token 消耗，也可能提高 BOSS 风控或网页登录强退风险
   • 默认更建议继续坚持 web-access
4. 只有用户明确同意后，才允许临时启用截图等异常方案

2. BOSS 站内发消息必须走固定 recipe

只要进入 BOSS 站内消息发送，必须先读取并执行：

• boss-send-recipe.md

不要把该文档当参考说明。 不要再自行重新设计 DOM 路径、前端事件路径、子代理方案。

如果候选人线程都没有成功打开，就不得继续做输入框查找和发送动作。 但在暂停前，必须先把“自动打开候选人线程”的标准路径和有限备用路径走完。 不要一失败就要求用户代为点击候选人。

如果标准路径失败，下一步必须优先走低 token 的分层自动诊断，而不是直接进入长时间试错或大段脚本探索。

发送 Boss 站内消息时，必须做候选人身份校验，避免把给 A 的消息发给 B。

发送按钮点击路径也必须受控：

• 默认优先使用 web-access clickAt
• 其次才是底层 CDP 鼠标事件
• DOM btn.click() 只允许作为一次性兜底，不得作为默认主路径

特别是在批量打招呼时，不允许把 DOM click 当成标准实现。

对于“索要附件简历”类消息，发送后还必须继续跟进：

• 候选人是否已发送简历
• 是否出现“同意/接收”按钮
• 是否已点击完成接收

如果是批量打招呼或批量推进消息，还必须额外遵守：

• 小批量分轮发送
• 相邻发送之间加入短暂停顿
• 每发送 2 到 3 人做一次轻量状态校验
• 触发验证码、异常验证、登录态波动、页面异常跳转时立即停止整轮发送

如果首条打招呼发生在推荐页，还必须额外遵守：

• 禁止用 XPath 或 DOM 序号点击“第 N 个按钮”
• 必须先绑定稳定候选人标识，再点该候选人卡片内按钮
• 如果没有唯一 ID，必须先用 eval 给目标按钮临时写入 data-* 标记，再用 CSS selector 调 clickAt 或 click
• 必须按“一人一事务”执行，不要先识别一批人再回头批量点按钮
• 优先在当前推荐页完成成功确认，不要每打一人就默认跳聊天页确认
• 如果前几个候选人成功、后续连续失败，必须优先判断当日推荐牛人沟通权益是否耗尽
• 如果疑似权益耗尽，进入 paused_for_boss_contact_quota_exhausted，保留已筛选候选人，等待权益恢复或用户开通更多权益

2.1 默认不要把 Boss 浏览器控制下放给子代理

Boss 相关浏览器控制默认应由主执行流完成。

不要为了普通页面读取、进入后台、读取 JD、读取候选人列表、发送标准消息，而默认启动子代理接管浏览器。

只有在用户明确要求，或主执行流已经卡在非页面业务逻辑问题时，才允许考虑子代理。

3. 服务按入口执行

简历筛选：

• boss-screening-service.md

站内沟通：

• boss-chat-service.md

飞书约面：

• boss-scheduling-service.md

阻断式前置条件

在介绍完三类服务之后，再告诉用户该服务对应的强制前置条件。

所有服务共用的强制前置条件：

1. 由龙虾代为禁用或移除会抢占浏览器访问的 skill，包括但不限于 browser-use。
2. 由龙虾代为安装 web-access。
   • GitHub 链接：https://github.com/eze-is/web-access
3. 先要求用户在真实 Chrome 或 Chromium 浏览器里打开并登录 BOSS 直聘招聘者页面。
4. 把当前任务切换到 web-access。
5. 验证 web-access 已经接管当前 BOSS 任务。
6. 确认当前 Chrome / Chromium 中确实存在已登录的 Boss tab。

此外，对于 boss-screening，还有一个额外阻断条件：

7. 必须先确认每个 JD 的每日目标候选人数。

如果这些通用前置条件没有完成，禁止继续：

• 读取在线岗位
• 读取 JD
• 查看候选人
• 发站内消息
• 创建飞书日程

如果用户还没有先在 Chrome 中登录 Boss 招聘者页面，也禁止开始“接管浏览器”这一步。

如果 boss-screening 的每日目标人数未明确，也禁止开始筛选。

不要自行搜索 web-access 的安装来源。 默认由龙虾先尝试代为安装；只有代装失败、权限不足或环境阻塞时，才让用户手动安装，并直接提供上面的 GitHub 链接。

对于 browser-use 等浏览器 skill，也默认由龙虾先代为禁用或移除。 不要先反问用户“是否已经禁用”。 完成后直接向用户汇报“已禁用/已移除”，只有在代办失败时才再向用户说明阻塞原因。

服务专属前置条件必须按需引导，不要一次性全部抛给用户：

• boss-screening：只需要通用前置条件
• boss-chat：需要通用前置条件，以及用户已明确批准哪些候选人进入沟通
• boss-scheduling：需要通用前置条件，以及用户已选择候选人进入约面；飞书 bot 的配置和授权只在第一次真实创建日程时再引导

不要跳过这些条件自行脑补默认答案。

policy 缺失时的默认处理

如果当前环境里缺少：

• company-policy.yaml
• approval-policy.yaml

不要直接反问用户“筛选标准是什么”。

正确顺序必须是：

1. 先读取当前在线岗位和 JD
2. 基于 JD 自动生成一版默认筛选标准
3. 把这版默认标准当作初始 policy
4. 只向用户确认或补问“哪些地方要覆盖默认标准”

默认标准的第一来源是 JD。 用户补充的是：

• 公司特有的人才观
• 硬性淘汰条件
• 审批边界
• 必须人工复核的情况

筛选服务的目标制规则

boss-screening 的核心不是“每小时扫一次”，而是：

• 每个 JD 每天要筛选出多少个符合要求的候选人

龙虾应当围绕这个目标去筛选全渠道候选人，包括：

• 主动聊天/主动投递中的未读候选人
• 推荐页面中的本轮未处理候选人
• 搜索结果中的本轮未处理候选人（若账号具备搜索权益）

首次进入 boss-screening 时，必须优先确认：

1. 每个 JD 的每日目标候选人数
2. 若用户有多个 JD，分别为每个 JD 设目标

如果用户没有给出目标人数，龙虾必须主动追问，而不是直接按固定时间节奏开始跑。

如果用户只给了时间节奏、没有给每日目标人数，仍然视为信息不完整，必须继续确认每日目标人数。

未读候选人优先原则

新一轮筛选默认主对象不是“当前可见候选人”，而是“当前仍未处理的未读候选人”。

默认应优先覆盖：

• 左侧列表中带未读气泡的候选人
• 本轮新进入聊天列表但尚未处理的候选人
• 本轮新出现回复的候选人
• 上一轮发现但未成功读到简历的候选人

默认不进入新一轮扫描范围：

• 已被 HR 人工读过并完成筛选的候选人
• 已被龙虾读过并完成筛选、且本轮没有新未读消息的候选人

只有在这些条件下才允许重扫旧候选人：

• 用户点名要求重新评估
• 候选人出现新的未读回复
• 上一轮状态是未完成或待补读
• 候选人状态发生明显变化

对于不同来源，判断依据也不同：

• inbound_chat：以页面未读信号为主，任务记忆为辅
• recommended_feed：以任务记忆为主，页面信号为辅
• search_results：以任务记忆为主，页面信号为辅

对于 recommended_feed，还要额外注意：

• 如果推荐页上的候选人卡片已经稳定显示，就应直接读取当前 DOM
• 不要默认把推荐页误判为“页面还没加载完成”
• 不要默认等待很久、做截图快照分析、或先要求用户确认页面是否加载完成
• 推荐页的核心任务是“读取当前卡片 + 用本地记忆判断哪些本轮未处理”，不是反复做页面加载安全推断

执行窗口与汇报节奏

时间相关规则现在是辅助规则，不是主规则。

可配置项包括：

• 每天允许执行筛选的时间窗口
• 多久向用户汇报一次进度
• 是否只在工作日运行

如果用户没有指定这些辅助规则，可采用默认值：

• 周一到周五
• 本地时间 09:00-17:00
• 每 60 分钟汇报一次

但无论是否采用默认时间规则，筛选服务都必须围绕“每日目标候选人数”推进。

进度汇报的固定要求

每次汇报至少要包含：

1. 每个 JD 的每日目标人数
2. 当前已筛出多少个符合要求的候选人
3. 距离目标还差多少
4. 本周期内新增或更新的候选人分类结果
5. 每位候选人的分类原因
6. 建议继续沟通的候选人
7. 建议进入约面的候选人
8. 需要用户确认的动作
9. 本轮发现的未读候选人数
10. 本轮已成功更新的未读候选人数
11. 本轮仍未补齐的未读候选人数及原因

每次汇报都要分别向用户确认：

• 哪些候选人可以继续推进站内沟通，例如索要附件简历
• 哪些候选人可以进入约面路径

如果用户尚未确认推进动作，不要自行把候选人推进到 boss-chat 或 boss-scheduling。

飞书边界

飞书只允许走 bot 路径。

用户负责：

• 去飞书开放平台创建应用或 bot
• 获取 App ID 和 App Secret
• 按提示去 bot 聊天里完成真正可用的日历授权

龙虾负责：

• 接收用户提供的 App ID / App Secret
• 完成本地配置
• 调用 bot 创建日程

龙虾不得：

• 主动打开飞书开放平台网页
• 替用户点击开放平台后台
• 自由尝试 API、OAuth、网页版三套路径

第一次真的要创建飞书日程时，才去确认 bot 是否已配置、授权是否已完成。

失败处理

所有强约束动作失败后，都必须进入“可恢复暂停态”，而不是继续长时间试错。

暂停时必须告诉用户：

1. 失败的是哪一步
2. 已经按最小快路径尝试过
3. 最可能原因
4. 用户现在最小需要做什么
5. 用户做完后如何恢复

不得把“继续试试看”当成默认策略。

阅读顺序

1. 先读 browser-routing.md
2. 再按当前服务读取：
   • boss-screening-service.md
   • boss-chat-service.md
   • boss-scheduling-service.md
3. 如需发 BOSS 站内消息，再读 boss-send-recipe.md
4. 如需读取推荐页，再读 boss-recommend-read-recipe.md
5. 如需发送首条打招呼，再读 boss-greet-recipe.md
6. 其他补充文档：
   • policy-schema.md
   • task-memory.md
   • trial-run.md