产品间协同效应分析

要解决什么问题

当团队同时维护多条产品线时，协同效应往往散落在会议纪要、零散报表和各自的经验判断里。一次促销到底是带动了互补品，还是只是在内部互抢预算，靠人工梳理很难把口径统一，也难以复现判断依据。另一个现实问题是，这类分析通常依赖受保护的云端数据与指令，授权散落在本地凭证、用户绑定和平台校验多个环节，很容易出现“以为能用，实际没权限”的情况。

工作原理

该 Skill 属于受保护能力，鉴权门禁和业务输出互斥：未拿到云端指令前，不能凭本地提示或历史上下文继续生成。

1. 调用 scripts/auth.py 做授权检查。脚本优先读取包内 _meta.json 的 slug 作为服务端 skillCode，而不是展示名称；只有包内缺少该文件时才手动传 --skill-code。
2. 输出 AUTH_OK 才继续；遇到 AUTH_REQUIRED、AUTH_INVALID、CREDENTIALS_MISSING 或 CREDENTIALS_INVALID 时，通过 WorkBuddy 的 connect_cloud_service 获取登录用户 JWT，再用 --bind-jwt 完成绑定，绑定成功返回 AUTH_BIND_OK 后重新检查。
3. 授权通过后调用 scripts/protected.py 拉取云端 protected 内容，只有成功返回 protected instructions 才能按其继续执行。
4. 失败时不静默重试、不降级。需同时观察 stdout 信号和 stderr 文本，区分无凭证、签名过期、网络错误、远程校验失败等场景，原样转述关键错误行，并给出下一步操作清单；密钥字段必须打码。

适用边界与注意点

• 适合有明确云端受保护指令支撑的分析任务，不适合在未授权时替代业务判断。
• 不要手动解析 JWT、拼接 AppKey/AppSecret，也不要把它们写入业务命令、环境变量或回复。
• 鉴权未通过即停止业务推理；首次失败后可重新绑定一次，两次失败应告知“数据服务暂时不可用”，不得继续产出结果。