技能介绍

解决了什么问题

医疗行业的患者管理场景涉及大量敏感数据和受保护能力，这类工作流不能直接在本地完成。如果授权逻辑散落在各个脚本里，很容易出现凭证硬编码、鉴权失败静默降级、或者把 AppKey/AppSecret 拼进业务命令的问题。更麻烦的是，当云端拒绝访问时，模型可能误以为可以继续产出业务结果，导致在未授权状态下生成医疗相关输出。

这个技能把授权门禁和受保护内容获取拆成了明确的步骤，让调用方必须先拿到 AUTH_OK 才能继续，并且禁止在鉴权失败时伪造业务输出。

技能如何工作

核心逻辑集中在两个脚本：scripts/auth.py 和 scripts/protected.py。

授权检查：每次使用前必须先执行 auth.py --ensure。脚本会读取包内 _meta.json 的 slug 作为 skillCode，例如 BT_HZGL_20260521，而不是展示名称。如果输出 AUTH_OK，说明本地凭证缓存有效且远程校验通过。如果输出 AUTH_REQUIRED 或 CREDENTIALS_*，则需要通过 WorkBuddy 的 connect_cloud_service 工具获取当前登录用户 JWT，再用 auth.py --bind-jwt 完成绑定。

受保护内容获取：授权通过后必须调用 scripts/protected.py 拉取云端 protected instructions。只有该脚本成功返回后，才能严格按照返回内容继续执行。未拿到 protected instructions 时必须停止，不得凭本地提示或历史上下文继续生成。

鉴权失败处理：当 auth.py 或 protected.py 返回非成功状态时，禁止静默重试或降级。必须立即停止业务推理，按模板向用户输出中文报告，原样转述 stdout 信号和 stderr 关键行，并给出明确操作清单。错误码和错误消息可以展示，但密钥相关字段必须打码。

适用边界与注意点

鉴权门禁与业务输出互斥：AUTH_OK 未出现前，不得生成任何业务结果。这一点在 SKILL.md 中被标为特别警告。
重试上限为 1 次：CREDENTIALS_MISSING、CREDENTIALS_INVALID、HTTP 401/403 等鉴权类错误最多重新绑定一次。两次失败说明是服务端问题，应告知用户数据服务暂时不可用，停止重试。
不要手动处理密钥：不要在 SKILL.md 中解析 JWT、拼接 AppKey/AppSecret 或调用绑定接口。所有授权逻辑由 scripts/auth.py 统一处理。
区分错误类型：network error 和 authorization failed 需要不同的处理建议，不能把网络问题当成凭证错误。