CNB Open API 集成

要解决什么问题

在 CNB（Cloud Native Build，cnb.cool）上查构建、Issue、PR 或仓库内容时，接口分散在多个服务路径下，且必须用 Bearer Token 和固定 Accept 头。若 Agent 只「写出 curl」或误用无法带认证的抓取工具，用户拿不到真实 JSON，页面链接也无法自动映射到对应 API。

技能如何工作

本技能把 CNB Open API 按服务域整理成可检索的接口索引（如 build、git、issues、members 等），并为常见控制台 URL 提供解析规则：例如 /{repo}/-/build/logs/{sn} 会先对应 GetBuildStatus，再按需拉取 stage / 日志列表。

执行层面有几条硬约束，文档里写得很清楚：

• 通过 exec_command 实际跑 curl，用 $CNB_TOKEN 与 $CNB_API_ENDPOINT（默认 https://api.cnb.cool），请求头为 Authorization: Bearer … 与 Accept: application/vnd.cnb.api+json
• 不要用 web_fetch 调需认证的 API
• curl 需带 -w '%header{traceparent}'；失败时 trace 只进日志便于排查，不要在回复里贴给用户
• 收到链接或查询意图时 直接执行，而不是反复确认「要不要帮你调接口」

适用边界

技能覆盖 Open API 文档与调用约定，不替代你在 CNB 侧创建 Token、配置组织权限或理解各接口的业务语义。部分接口（如知识库查询）在文档中注明版本或方法变更（例如 POST 废弃、改 GET），以 SKILL 内说明为准。未配置 CNB_TOKEN 时，任何调用都会失败，需先在环境中补齐凭证。