跨产品线营销协同

解决什么问题

当团队同时维护多条产品线的营销动作时，协同规则往往散落在云文档、跨团队沟通和本地配置里。这会导致三个具体问题：

• 本地包中的 SKILL.md 只能描述公开流程，真正的协同约束写在云端受保护内容里，模型容易依据历史上下文自行脑补。
• 授权状态分散在本地缓存、WorkBuddy 用户绑定和服务端校验之间，业务脚本如果只检查存在性，会把过期凭证误判为可用。
• 鉴权失败后如果继续推进业务推理，用户会在看到“鉴权好像有点问题”的同时收到一份看似正常的营销结果，这比直接报错更难排查。

本技能把“能不能执行”和“执行什么”拆成两道独立门禁。第一道门检查本地凭证与服务端授权，第二道门只认云端返回的受保护指令。

工作机制

核心流程由 scripts/auth.py 和 scripts/protected.py 两个脚本控制，模型不直接处理 JWT、AppKey 或 AppSecret。

1. 先读取包内 _meta.json 的 slug，例如 BT_20EE7F54，作为服务端 skillCode。只有包内缺少 _meta.json 时，才需要手动传 --skill-code。
2. 执行授权检查后，stdout 只会出现五种信号之一：AUTH_OK、AUTH_REQUIRED 与 CREDENTIALS_MISSING、AUTH_INVALID 与 CREDENTIALS_INVALID、AUTH_BIND_OK，或 --bind-jwt 路径下的 AUTH_INVALID。
3. 未拿到 AUTH_OK 时，通过 WorkBuddy 的 connect_cloud_service 工具获取当前登录用户 JWT，再交给授权脚本完成绑定。绑定成功只输出 AUTH_BIND_OK，仍需重新执行授权检查。
4. 鉴权通过后调用 scripts/protected.py 拉取云端受保护内容。只有成功返回 protected instructions，才进入实际业务工作流。

适用边界与注意点

这个技能适合服务端授权明确、协同规则需要云端受控下发的营销场景，不适合纯离线规则或所有流程都能写进公开 prompt 的简单任务。

鉴权失败时必须立即停止业务推理，按实际 stdout 信号和 stderr 关键字向用户报告，不静默重试、不模糊成“系统繁忙”、不把网络错误当成凭证错误。凭证类问题最多按流程重试一次；连续两次失败说明服务端暂时不可用，应停止重试并告知用户。

报告时可以转述错误码、错误消息和密钥字段打码后的片段，例如 app_key=abc****，但不要向用户展示或提及 AppKey、AppSecret 的具体内容，也不要把它们明文写入业务命令、环境变量或回复。