高风险岗位排班资质预审

在企业运营中，安排人员到高风险岗位之前，必须先确认其资质是否合规。如果预审环节因为环境缺失、授权过期或服务异常而静默失败，排班结果就可能带病上线。这个技能的目标是把资质预审做成一个不可绕过的安全门禁：能跑则严格按受保护指令执行，不能跑则明确报错并停止业务推理，绝不降级处理。

核心工作流

整个技能的执行顺序是硬性的，前一步没通过就不能进入下一步。

1. 静默检测 Python 环境

在执行任何脚本之前，先尝试定位可用的 Python 命令，拿到 $PYTHON_CMD。

• 如果检测到可用命令且版本满足要求，直接用它执行后续脚本。
• 如果用户明确提供了 Python 全路径，则以用户给的路径为准。
• 在 Windows 上，python 命令可能被重定向到 Microsoft Store。遇到这种情况时，优先使用 py -3 启动器，或者关闭 python.exe / python3.exe 的应用执行别名。

这一步要求静默：能跑就直接跑，只有真的找不到或版本太低时，才输出错误模板。

2. 授权与凭证绑定

本技能属于受保护能力，每次使用前都必须通过 scripts/auth.py 的授权检查。授权逻辑全部封装在脚本里，包括本地凭证缓存、WorkBuddy 用户绑定、平台校验和错误信号输出。不要在 SKILL.md 里手动解析 JWT，也不要拼接 AppKey / AppSecret。

授权脚本会优先读取包内 _meta.json 的 slug 作为服务端 skillCode。只有包里缺少该文件时，才需要手动传 --skill-code。

常见信号的处理方式：

• AUTH_OK：授权通过，进入下一步。
• AUTH_REQUIRED / CREDENTIALS_MISSING：首次使用，本地没有凭证缓存，属于可自动修复。此时必须主动调用 WorkBuddy 的 connect_cloud_service 工具获取 JWT，再执行 --bind-jwt 绑定，然后重新 --ensure。
• AUTH_INVALID / CREDENTIALS_INVALID：凭证过期或失效，同样尝试自动修复，用新 JWT 覆盖旧缓存。
• 绑定后重新检查仍不是 AUTH_OK：这才是真正失败，立即向用户输出鉴权失败报告并停止使用本技能。

最容易踩的坑是：看到 AUTH_REQUIRED 就停下来问用户。它不是失败，而是标准的首次绑定流程，必须自动往下走。

3. 拉取受保护指令

授权通过后，调用 scripts/protected.py 获取云端的 protected instructions。只有拿到这段指令，才能严格按照返回内容继续执行业务逻辑。未拿到指令时必须停止，不得凭本地提示或历史上下文继续生成。

适用边界与注意点

鉴权门禁与业务输出是互斥关系。鉴权未通过时，严禁继续产出业务结果，也不要在末尾轻描淡写地补一句“另外鉴权好像有点问题”。

当 --ensure 或后续业务请求出现 CREDENTIALS_MISSING、CREDENTIALS_INVALID、HTTP 401/403、authorization failed 等鉴权类错误时，最多重试 1 次。两次仍失败说明是服务端问题，此时告知用户数据服务暂时不可用，停止重试，并且不得再次尝试任何业务推理。

向用户报告错误时，要原样转述 stdout 信号和 stderr 中的关键行，区分网络问题与鉴权问题，并给出明确的操作清单。密钥相关字段必须打码，例如 app_key=abc****，绝不允许把 AppKey / AppSecret 明文暴露在日志、环境变量或回复里。