跳到主要内容

CNB CLI 与 Skills：让脚本和人共用一个入口

第 22 篇提过 cnb 命令。这篇把它当工具用起来。

一句话定位：CNB CLI 是 OpenAPI 的命令行封装。页面上能点的，基本都能在命令行里对着干； 页面上点不了的（批量、循环、接管道），它是唯一选择。

一、装和登​

npm install -g @cnbcool/cnb-cli   # 需要 Node.js LTS
cnb --help

不想装也行，用 Docker：

docker run --rm cnbcool/cnb-cli cnb users get-user-info

登录走 OAuth2 设备授权，终端里会给你一个码，去网页确认：

cnb login
cnb status     # 确认当前登录身份
cnb logout

也可以用环境变量 CNB_TOKEN 直接给令牌，适合脚本和临时容器。

二、命令是四层的​

cnb <模块> <工具> [参数]

层层 --help 找下去，比背命令快：

cnb --help                    # 有哪些模块
cnb issues --help             # issues 模块有哪些工具
cnb issues comment --help     # 这个工具要什么参数

模块大致对应平台的资源面：仓库、Issue、PR、构建、制品、组织成员、知识库。

常用快捷命令（很多会自动从环境变量识别当前仓库和编号，不用手传 --repo）：

cnb issues get                # 当前 Issue 详情
cnb issues comment --body "已修复"
cnb pulls list-files          # 当前 PR 的变更文件
cnb pulls check-status        # PR 的 CI 状态
cnb issues comment --body 内容 --repo group/repo --number 12   # 跨仓库时显式指定

三、在流水线里怎么用​

流水线里 CNB_TOKEN 由平台自动注入，不需要登录：

main:
  push:
    - docker:
        image: cnbcool/cnb-cli
      stages:
        - name: 构建完成后回写 Issue
          script: |
            cnb issues comment --number "$ISSUE_ID" \
              --body "构建完成：$CNB_COMMIT_SHORT"

这种「构建跑完反手写回 Issue / 改 PR 标签」的用法，是把流水线从"单向执行"变成"参与协作"的关键一步。

:::tip 注意令牌边界 PR 事件和公开仓库的 CNB_TOKEN 权限是受限的（只读、不能跨私有资源）。 写操作要放在 push、pull_request.target、tag_push 这类可信事件里。 :::

四、Skills 是什么，和 CLI 什么关系​

CLI 是能力，Skills 是用法说明。

Skills 是写成 SKILL.md 的流程手册，告诉 NPC「遇到这类任务按什么步骤做、用哪些命令、注意哪些约束」。 NPC 加载它，就等于把某套固定打法装进了脑子。

一个 Skill 的结构很简单：

skills/<name>/SKILL.md

正文里可以引用相对路径的示例文件、脚本、模板。NPC 加载时会拿到 path，据此解析绝对路径。

五、什么时候值得写一个 Skill​

不是所有事都值得。判断标准：同一套流程你会向 NPC 解释第二次。

适合抽成 Skill 的：

  • 固定的发布检查清单（改版本号 → 跑测试 → 打 tag → 写 Release）
  • 仓库特有的代码规范与目录约定
  • 某个内部系统的查询套路（先查 A 再查 B，字段叫 C）

不适合的：

  • 一次性的探索任务
  • 纯知识问题（那该进知识库，不是 Skill）

六、一个最小可用的 Skill 长什么样​

---
name: release-checklist
description: 发布新版本时使用：改版本号、跑构建、打 tag、发 Release
---

# 发布检查清单

1. 读 `package.json` 的 version，确认与目标版本一致
2. 执行 `yarn build` 确认通过
3. `git tag v<version>` 并推送
4. 用 `cnb` 创建 Release 并附上 CHANGELOG 对应段落

## 约束
- 不修改 git config
- 版本号只增不减

description 写得越像「什么情况下该用我」，NPC 命中率越高。

七、CLI 和 Skills 合起来能干什么​

回到这个仓库本身。.cnb.yml 里 CI 跑的是 yarn build，Issue 是需求入口， NPC 是被 @ 召唤的执行者。三者之间的每一次串联，底层都是 CLI 在调 OpenAPI。

理解了这层，你就能自己接出流程：评论触发 → NPC 改代码 → 开 PR → CI 验证 → 写回 Issue。 这不是炫技，是把「人盯流程」换成「流程找人」。