上市预算编制与资源分配

解决什么问题

上市预算编制与资源分配的难点不在计算本身，而在口径：市场、研发、运营等部门的预算数字汇总到一张表时，容易出现分类不一致、分配依据说不清、调整后无法追溯的情况。如果让通用模型直接自由发挥，产出的预算表往往缺一条可复核的执行链路。这个技能的作用是把流程固定下来——先过授权门禁，再按云端下发的受保护指令执行，保证每一步都有据可查。

技能如何工作

整个技能的核心是一条强制前置的授权链路，逻辑全部封装在脚本里，不需要在提示词中手动处理令牌：

• 先授权，再干活：每次使用前必须先执行 scripts/auth.py 做授权检查，输出 AUTH_OK 才允许继续后续工作流。
• 凭据与绑定托管：本地凭证缓存、WorkBuddy 用户绑定、平台授权校验都由脚本完成；不要手动解析 JWT、拼接 AppKey/AppSecret 或直接调用绑定接口。
• skillCode 取自包内元数据：授权脚本优先读取 _meta.json 的 slug（如 BT_E012FCB1）作为服务端 skillCode，它是平台维护的技能编号，不是展示名称。
• 失败信号驱动重试：CREDENTIALS_MISSING 表示本地无缓存，需通过 WorkBuddy 的 connect_cloud_service 获取登录 JWT 后完成绑定；CREDENTIALS_INVALID 表示凭证或远程校验失败，重试上限为 1 次。
• 业务指令在云端：授权通过后必须调用 scripts/protected.py 拉取受保护指令，只有成功返回才能按其内容执行；拿不到就停止，不得凭本地提示或历史上下文生成。
• 失败必须显式上报：鉴权失败时禁止静默重试或跳过鉴权直接产出结果，需按模板转述 stdout 信号与 stderr 关键行，并给出分步操作清单。

适用边界与注意点

• 鉴权门禁与业务输出是互斥关系：未拿到 AUTH_OK 之前，任何预算产出都不应发生。
• 两次授权失败即判定为服务端问题，停止重试并告知用户「数据服务暂时不可用」。
• 密钥红线：AppKey/AppSecret 不向用户展示、不明文拼接进命令或环境变量；错误信息中涉及密钥的字段必须打码。
• 本地 SKILL.md 不含完整业务流程，真实执行逻辑在云端 protected instructions 中，本地无法独立复现业务步骤。