@cnbcool/cnb-cli 1.0.0 → 1.0.1

package/skills/diagnose-pr-pipeline/SKILL.md

@@ -1,88 +0,0 @@
----
-name: diagnose-pr-pipeline
-description: 用于获取 CNB 平台合并请求（Pull Request）报错的详细信息。当合并请求触发的 CI 流水线出现失败、报错、构建异常等情况时，可使用本 Skill 逐步定位具体报错原因。执行流程包括：查询 PR 状态检查获取构建编号、查询流水线构建状态获取失败 Stage ID、查询 Stage 详情获取具体报错信息。
----
-
-# 获取合并请求报错详情
-
-## 描述
-
-当 CNB 平台合并请求（Pull Request）触发的 CI 流水线出现报错时，通过本 Skill 可以逐步定位并获取具体的报错详情信息。
-
-> ⚠️ **注意：以下步骤必须严格按顺序执行，每一步的输出结果是下一步的输入依据。**
-
-## 依赖
-
-- [cnb-skill]: 提供与CNB（Cloud Native Build）OpenAPI的完整交互能力，支持项目、组织、代码仓库、Issue、PR、合并请求、流水线，制品库等核心功能的增删改查操作。适用于开发协作、代码管理和CI/CD流程管理场景。关键词：CNB、云原生构建、组织、代码仓库、Issue、PR、合并请求、流水线、制品库，查询、新增、修改、删除、评论、合并、审批。
-
----
-
-## 使用步骤
-
-### Step 1：查询 Pull Request 的状态检查
-
-查询指定 Pull Request 的状态检查信息，从返回结果中找到**状态检查的详细信息链接地址**。
-
-链接地址格式如下：
-
-```
-{CNB_WEB_ENDPOINT}/{CNB_REPO_SLUG}/-/build/logs/{sn}
-```
-
-| 参数                | 说明                     |
-| ------------------- | ------------------------ |
-| `CNB_WEB_ENDPOINT`  | CNB 平台的 Web 访问地址  |
-| `CNB_REPO_SLUG`     | 仓库的唯一标识（slug）   |
-| `sn`                | 流水线构建编号           |
-
-**目标：** 从链接地址中提取 `{sn}`，即流水线构建编号，供下一步使用。
-
----
-
-### Step 2：查询流水线构建状态
-
-使用上一步获取到的流水线构建编号 `{sn}`，查询该流水线的构建状态。
-
-从返回结果中找到**失败的 Stage ID**。
-
-**目标：** 获取失败 Stage 的 `id`，供下一步使用。
-
----
-
-### Step 3：查询流水线 Stage 详情
-
-使用上一步获取到失败 Stage 的 `id`，查询该 Stage 的详细信息。
-
-从返回结果中找到**具体的报错信息**。
-
-**目标：** 获取完整的报错详情，定位问题根因。
-
----
-
-## 执行流程图
-
-```
-查询 PR 状态检查
-      │
-      ▼
-提取详情链接中的构建编号 {sn}
-      │
-      ▼
-查询流水线构建状态（入参：{sn}）
-      │
-      ▼
-提取失败的 Stage ID
-      │
-      ▼
-查询 Stage 详情（入参：stage_id）
-      │
-      ▼
-获取具体报错信息 ✅
-```
-
----
-
-## 注意事项
-
-- 每一步必须在上一步**成功获取到所需参数**后再执行，不可跳步。
-- 若 Step 2 返回的构建中存在多个失败 Stage，可逐一查询每个失败 Stage 的详情，以获取完整的报错信息。

package/skills/dialog-ci-log/README.md

@@ -1,16 +0,0 @@
-# dialog-ci-log
-
-一个 Skill，用于查询 CNB CI 流水线的失败日志，快速定位构建失败原因。
-
-## 能力说明
-
-当你提供以下任一信息时，Skill 会自动查询并分析流水线的报错日志：
-
-- **构建编号（sn）**，如 `cnb-lf3-1jk2v2sl2`
-- **构建日志链接**，如 `https://cnb.woa.com/{repo}/-/build/logs/{sn}`
-
-Skill 会自动完成以下工作：
-
-1. 从输入中解析仓库标识和构建编号
-2. 查询流水线中所有失败 Stage 的详细日志
-3. 汇总失败原因，并给出修复建议

package/skills/dialog-ci-log/SKILL.md

@@ -1,41 +0,0 @@
----
-name: dialog-ci-log
-description: 传入流水线的 sn ，查询 CI 流水线的错误日志。当用户提供 CI 构建链接或 sn 编号，想查看流水线报错、构建失败原因时使用。
-allowed-tools: Bash,Read,Write,Edit,Glob,Grep
----
-
-# 查询 CI 流水线错误日志
-
-## 使用场景
-
-用户提供以下任一信息时触发：
-- 流水线构建编号（sn），如 `cnb-lf3-1jk2v2sl2`
-- 构建日志链接，如 `${CNB_WEB_ENDPOINT}/{repo}/-/build/logs/{sn}`
-
-## 执行步骤
-
-### Step 1：解析参数
-
-从用户输入中提取必要信息：
-
-- **如果用户给了链接**：从 URL 中解析出 `CNB_REPO_SLUG` 和 `sn`
-  - URL 格式：`${CNB_WEB_ENDPOINT}/{CNB_REPO_SLUG}/-/build/logs/{sn}`
-  - `CNB_WEB_ENDPOINT` 从环境变量获取，默认为 `https://cnb.cool`
-  - 例：`https://cnb.cool/group/repo/-/build/logs/cnb-lf3-1jk2v2sl2` → `CNB_REPO_SLUG=group/repo`, `sn=cnb-lf3-1jk2v2sl2`
-
-`CNB_TOKEN` 从环境变量获取，若不存在则向用户询问。
-
-### Step 2：运行脚本获取日志
-
-```bash
-node ~/.codebuddy/skills/dialog-ci-log/scripts/get-failed-stage-logs.js {sn}
-```
-
-脚本路径：项目根目录下的 `scripts/get-failed-stage-logs.js`
-
-### Step 3：分析并汇报结果
-
-根据脚本输出：
-1. 列出所有失败的 Stage 名称
-2. 提取关键报错信息，给出简明的失败原因总结
-3. 如有可能，给出修复建议

package/skills/dialog-ci-log/scrips/get-failed-stage-logs.js

@@ -1,124 +0,0 @@
-#!/usr/bin/env node
-
-/**
- * 查询流水线失败 Stage 日志
- *
- * 用法: node scripts/get-failed-stage-logs.js <sn>
- *
- * 环境变量:
- *   CNB_API_ENDPOINT - API 地址，默认 https://api.cnb.cool
- *   CNB_REPO_SLUG    - 仓库标识，如 owner/repo（必填）
- *   PLUGIN_CNB_ACCESS_TOKEN        - 访问令牌（必填）
- */
-
-const sn = process.argv[2];
-if (!sn) {
-  console.error('用法: node scripts/get-failed-stage-logs.js <sn>');
-  process.exit(1);
-}
-
-const API_ENDPOINT = process.env.CNB_API_ENDPOINT;
-const REPO_SLUG = process.env.CNB_REPO_SLUG;
-const TOKEN = process.env.PLUGIN_CNB_ACCESS_TOKEN;
-
-if (!REPO_SLUG) {
-  console.error('缺少环境变量 CNB_REPO_SLUG');
-  process.exit(1);
-}
-if (!TOKEN) {
-  console.error('缺少环境变量 PLUGIN_CNB_ACCESS_TOKEN');
-  process.exit(1);
-}
-
-const HEADERS = {
-  Accept: 'application/vnd.cnb.api+json',
-  Authorization: TOKEN,
-};
-
-async function request(path) {
-  const url = `${API_ENDPOINT}/${REPO_SLUG}${path}`;
-  const res = await fetch(url, { headers: HEADERS });
-  if (!res.ok) {
-    throw new Error(`请求失败: ${res.status} ${res.statusText} — ${url}`);
-  }
-  return res.json();
-}
-
-async function getBuildStatus(sn) {
-  return request(`/-/build/status/${sn}`);
-}
-
-async function getStageDetail(sn, pipelineId, stageId) {
-  return request(`/-/build/logs/stage/${sn}/${pipelineId}/${stageId}`);
-}
-
-async function main() {
-  console.log(`查询构建 sn=${sn} 的流水线状态...\n`);
-
-  const buildStatus = await getBuildStatus(sn);
-
-  if (!buildStatus.pipelinesStatus || typeof buildStatus.pipelinesStatus !== 'object') {
-    console.log('未找到流水线状态信息');
-    console.log('返回数据:', JSON.stringify(buildStatus, null, 2));
-    return;
-  }
-
-  const pipelines = Object.entries(buildStatus.pipelinesStatus);
-  if (pipelines.length === 0) {
-    console.log('该构建没有流水线');
-    return;
-  }
-
-  let hasFailure = false;
-
-  for (const [pipelineName, pipeline] of pipelines) {
-    const { id: pipelineId, status, stages } = pipeline;
-
-    if (!Array.isArray(stages)) continue;
-
-    const failedStages = stages.filter((s) => s.status === 'error');
-    if (failedStages.length === 0) continue;
-
-    hasFailure = true;
-    console.log(`━━━ 流水线: ${pipelineName} (status: ${status}) ━━━\n`);
-
-    for (const stage of failedStages) {
-      console.log(`▸ 失败 Stage: ${stage.name || stage.id} (status: ${stage.status})`);
-
-      try {
-        const detail = await getStageDetail(sn, pipelineId, stage.id);
-
-        if (detail.error) {
-          console.log(`  错误信息: ${detail.error}`);
-        }
-        if (detail.duration != null) {
-          console.log(`  耗时: ${detail.duration}ms`);
-        }
-
-        if (Array.isArray(detail.content) && detail.content.length > 0) {
-          console.log('  ─── 日志 ───');
-          for (const line of detail.content) {
-            console.log(`  ${line}`);
-          }
-          console.log('  ─── 日志结束 ───');
-        } else {
-          console.log('  （无日志内容）');
-        }
-      } catch (e) {
-        console.error(`  查询 Stage 详情失败: ${e.message}`);
-      }
-
-      console.log();
-    }
-  }
-
-  if (!hasFailure) {
-    console.log('所有流水线均无失败的 Stage');
-    console.log(`整体构建状态: ${buildStatus.status}`);
-  }
-}
-
-main().catch((e) => {
-  console.error(`执行失败: ${e.message}`);
-  process.exit(1);
-});

package/skills/pr-diff/README.md

@@ -1,3 +0,0 @@
-# pr-diff-skill
-
-获取 PR 的 diff 变更信息。当需要查看 PR 代码变更、获取文件差异时使用此技能。

package/skills/pr-diff/SKILL.md

@@ -1,97 +0,0 @@
----
-name: pr-diff
-description: 获取 PR 的 diff 变更信息。当需要查看 PR 代码变更、获取文件差异时使用此技能。
-allowed-tools: Bash
----
-
-# 获取 PR Diff
-
-获取 PR 的代码变更差异信息，用于代码评审、变更总结等场景。
-
-## 1. 判断场景并获取 SHA
-
-### 场景 A：PR 评论触发（`CNB_PULL_REQUEST_IID` 存在）
-
-直接从环境变量获取：
-- head SHA：`CNB_PULL_REQUEST_SHA`
-- target SHA：`CNB_PULL_REQUEST_TARGET_SHA`
-
-若环境变量不存在，通过 API 查询当前 PR 详情。
-
-### 场景 B：Issue 或其他场景引用 PR
-
-用户输入中提及了 PR 编号（如 `!45`），需要：
-1. 从用户输入中解析 PR 编号
-2. 通过 API 查询该 PR 详情获取 SHA
-3. fetch 对应的 commit（本地可能没有）
-
-### API 查询 PR 详情
-
-```bash
-# 将 ${pr_iid} 替换为实际 PR 编号
-pr_info=$(curl -s \
-  "${CNB_API_ENDPOINT:-https://api.cnb.cool}/${CNB_REPO_SLUG}/-/pulls/${pr_iid}" \
-  -H "Accept: application/vnd.cnb.api+json" \
-  -H "Authorization: Bearer $CNB_TOKEN")
-
-head_sha=$(echo "$pr_info" | jq -r '.head.sha')
-target_sha=$(echo "$pr_info" | jq -r '.base.sha')
-
-# 场景 B 需要确保本地有这些 commit
-git fetch origin "$head_sha" "$target_sha" 2>/dev/null || git fetch origin
-```
-
-## 2. 获取 Diff
-
-### 获取变更文件列表
-
-```bash
-git diff --name-only "${target_sha}...${head_sha}"
-```
-
-### 获取变更统计
-
-```bash
-git diff --stat "${target_sha}...${head_sha}"
-```
-
-### 获取完整 Diff
-
-```bash
-git diff -U5 "${target_sha}...${head_sha}"
-```
-
-### 获取特定文件的 Diff
-
-```bash
-git diff -U5 "${target_sha}...${head_sha}" -- path/to/file.ts
-```
-
-## 3. 过滤文件
-
-根据使用场景，可排除无需关注的文件：
-
-```bash
-# 常见排除模式
-git diff -U5 "${target_sha}...${head_sha}" -- . \
-  ':!package-lock.json' ':!yarn.lock' ':!pnpm-lock.yaml' ':!go.sum' ':!*.lock' \
-  ':!*.png' ':!*.jpg' ':!*.gif' ':!*.svg' ':!*.ico' \
-  ':!*.min.js' ':!*.min.css' ':!*.map' \
-  ':!dist/*' ':!build/*' ':!node_modules/*'
-```
-
-**可排除的文件类型**：
-- 锁文件：`package-lock.json`、`yarn.lock`、`pnpm-lock.yaml`、`go.sum`、`Cargo.lock`
-- 图片/字体：`*.png`、`*.jpg`、`*.gif`、`*.svg`、`*.woff`、`*.ttf`
-- 二进制：`*.exe`、`*.dll`、`*.so`、`*.jar`、`*.pyc`
-- 压缩包：`*.zip`、`*.tar.gz`、`*.rar`
-- 构建产物：`dist/`、`build/`、`out/`、`target/`、`.next/`
-- 依赖目录：`node_modules/`、`vendor/`、`.venv/`
-- 压缩文件：`*.min.js`、`*.min.css`、`*.map`
-
-## 4. 使用建议
-
-1. **diff 过大时**：先用 `--name-only` 查看文件列表，再按需获取具体文件
-2. **代码评审**：建议排除锁文件、图片、构建产物
-3. **变更总结**：可保留更多文件，但排除二进制和依赖目录
-4. **上下文行数**：`-U5` 提供 5 行上下文，可按需调整

package/skills/pr-summary/README.md

@@ -1,3 +0,0 @@
-# pr-summary-skills
-
-PR 变更总结工具。仅用于合并请求（PR）场景。当用户请求总结 PR 变更、概述改动内容、生成变更说明时使用此技能。

package/skills/pr-summary/SKILL.md

@@ -1,70 +0,0 @@
----
-name: pr-summary
-description: PR 变更总结工具。仅用于合并请求（PR）场景。当用户请求总结 PR 变更、概述改动内容、生成变更说明时使用此技能。
-allowed-tools: Bash,Read,Glob,Grep
----
-
-# PR 变更总结
-
-对 PR 的代码变更进行分析，生成结构化的变更总结。
-
-## 执行步骤
-
-### 1. 获取变更信息
-
-使用 **pr-diff** Skill 获取 PR 变更：
-- 先获取变更统计（`--stat`）和文件列表（`--name-only`）
-- 再按需获取关键文件的具体 diff
-
-### 2. 过滤文件
-
-**优先分析**（核心代码）：
-- 业务逻辑：`src/`、`lib/`、`app/`、`packages/`
-- API/接口：`api/`、`routes/`、`controllers/`
-- 配置文件：`*.config.*`、`*.yml`、`*.yaml`
-- 数据库/模型：`models/`、`schema/`、`migrations/`
-
-**跳过**（非核心文件）：
-- 依赖锁文件：`package-lock.json`、`yarn.lock`、`go.sum`
-- 构建产物：`dist/`、`build/`、`.next/`
-- 生成文件：`*.min.js`、`*.map`
-- 纯测试文件（除非测试是本次变更重点）
-
-### 3. 分析变更
-
-按以下维度分析：
-
-| 维度 | 关注点 |
-|------|--------|
-| **变更类型** | feat（新功能）、fix（修复）、refactor（重构）、perf（性能）、docs（文档）、chore（配置/依赖） |
-| **影响范围** | 涉及哪些模块、影响哪些功能点 |
-| **关键改动** | 核心逻辑变更、API 变化、数据结构变更 |
-| **破坏性变更** | 不兼容改动、需要迁移的内容 |
-
-若上下文不足以理解代码意图，使用 Read 工具读取完整源文件。
-
-## 输出格式
-
-```markdown
-**{type}**: {一句话描述}
-
-**主要改动**
-- {模块}: {变更说明}
-- {模块}: {变更说明}
-
-**注意**: {破坏性变更或风险点；如无则省略}
-```
-
-## 总结原则
-
-1. **简洁明了**：突出重点，避免逐行复述 diff
-2. **按功能分组**：按模块/功能组织，而非逐文件罗列
-3. **突出意图**：说明"为什么改"而非仅描述"改了什么"
-4. **识别风险**：主动指出破坏性变更和需要关注的点
-
-## 大型 PR 处理
-
-当文件数超过 20 个时：
-1. 先用 `--stat` 分析变更分布，按模块归类
-2. 重点分析核心模块变更（变更量大或涉及关键逻辑）
-3. 在末尾概括未详细分析的文件/模块

package/skills/tapd-resource-fetcher/README.md

@@ -1,3 +0,0 @@
-# tapd-saas-resource-fetcher
-
-获取 Tapd SaaS 环境资源。当用户提供 Tapd 链接或提及 Tapd 需求/缺陷/任务/迭代时使用。支持获取需求(story)、缺陷(bug)、任务(task)、迭代(iteration)类型资源，调用接口获取完整资源数据以供分析。

package/skills/tapd-resource-fetcher/SKILL.md

@@ -1,97 +0,0 @@
----
-name: tapd-saas-resource-fetcher-skills
-description: 获取 Tapd SaaS 环境资源。当用户提供 Tapd 链接或提及 Tapd 需求/缺陷/任务/迭代时使用。支持获取需求(story)、缺陷(bug)、任务(task)、迭代(iteration)类型资源，调用接口获取完整资源数据以供分析。
-allowed-tools: Bash,curl
----
-
-# 获取 Tapd SaaS 资源
-
-当用户提供 Tapd 链接时，识别资源类型和 ID，调用接口获取完整资源数据，供后续分析使用。
-
-## 执行步骤
-
-### 1. 识别 Tapd 资源链接
-
-从用户输入中识别 Tapd 链接，支持以下格式：
-
-`https://www.tapd.cn/tapd_fe/{workspace_id}/{resource_type}/detail/{resource_id}`
-
-- resource_type 为资源类型。 可取值为 story、bug、task、iteration
-- workspace_id 为项目 ID
-- resource_id 为资源 ID
-
-对于给出的链接，提取 workspace_id 和 resource_type，resource_id, 用于之后的请求资源。
-
-
-### 2. 调用接口获取资源数据
-
-**重要**：请求前需替换 `{workspace_id}`, `{resource_type}`, `{resource_id}`
-
-对每个识别到的资源，按照以下方式获取资源数据：
-
-```bash
-curl -X GET "{$CNB_API_ENDPOINT}/tapd/reference/{workspace_id}/{resource_type}/{resource_id}" \
--H "Accept: application/vnd.cnb.api+json" \
--H "Authorization: Bearer $CNB_TOKEN" \
--H "Content-Type: application/json"
-```
-
-**示例** https://www.tapd.cn/tapd_fe/64201929/story/detail/1164201929001000017, 其中 workspace_id 为 64201929，resource_type 为 story，id 为 1164201929001000017。
-请求接口如下：
-```bash
-curl -X GET "{$CNB_API_ENDPOINT}/tapd/reference/64201929/story/1164201929001000017" \
--H "Accept: application/vnd.cnb.api+json" \
--H "Authorization: Bearer $CNB_TOKEN" \
--H "Content-Type: application/json"
-```
-
-### 3. 结果返回
-API 返回标准的 JSON 格式响应。请根据 HTTP 状态码判断请求是否成功：
-
-- 200: 请求成功
-- 400: 请求参数错误
-- 401: 未授权
-- 403: 禁止访问
-- 404: 资源不存在
-- 500: 服务器内部错误
-
-当本地调用返回的 `status` 在 200 ~ 299 之间，需要进一步检查响应体中的 `data` 字段：
-- 如果 `data` 包含有效数据，返回 `data` 内容给用户。
-- 如果 `data` 为空数组 `[]`，说明 TAPD 侧未找到对应资源，按照 3.1 节中的"数据为空"场景提示用户。
-
-只有当 `status >= 300` 时，才将 `status` 和 `trace` 返回给用户。
-#### 3.1 错误处理与用户提示
-
-**情况一：HTTP 状态码 >= 300**
-
-响应体为 JSON 格式：`{"errcode": <错误码>, "errmsg": "<错误信息>"}`。
-
-**请根据 `errcode` 给出对应的用户友好提示**：
-
-| errcode | 含义 | 用户侧友好提示 |
-|---------|------|----------------|
-| `2000076` | TAPD 功能未启用 | 当前项目未启用 TAPD 集成功能，请联系项目管理员在项目设置中开启 TAPD 集成。 |
-| `2000073` | 未找到 TAPD 绑定信息 | 你尚未绑定 TAPD 账号，请先前往个人设置页面绑定 TAPD 账号后再试。 |
-| `2000074` | 获取 TAPD 访问令牌失败 | TAPD 授权信息已过期或无效，请重新绑定 TAPD 账号后再试。 |
-| `2000075` | 获取 TAPD 资源详情失败 | 无法获取该 TAPD 资源，可能是你没有对应项目的访问权限，或者资源 ID 不正确，请检查链接后重试。 |
-| `401` | 未授权 | 请先登录 CNB 平台后再使用此功能。 |
-| `403` | 禁止访问 | 你没有权限访问该资源。 |
-| `404` | 资源不存在 | 未找到对应的资源，请检查链接中的项目 ID 和资源 ID 是否正确。 |
-| 其他 | 未知错误 | 请求失败，请稍后重试。如果问题持续存在，请联系管理员并提供 trace 信息。 |
-
-**情况二：HTTP 200 但 `data` 为空数组**
-
-当 HTTP 状态码为 200，响应体格式为 `{"status": 1, "data": [], "info": "success"}`，`data` 为空数组 `[]` 时，说明 TAPD 接口调用成功但未查询到对应资源。
-
-此时应给出提示：**未找到该 TAPD 资源，请检查链接中的资源 ID 是否正确。**
-
-**注意**：给出用户提示时，不要暴露内部实现细节（如具体的错误堆栈、用户 ID 等），只提供操作引导。
-
-
-### 4. 多资源处理
-
-若用户提供多个 Tapd 链接，**逐个**调用接口获取，每次只请求一个资源：
-
-1. 提取所有链接中的资源 ID 列表
-2. 按顺序逐一调用接口，每次获取一个资源
-3. 汇总所有资源数据后统一展示

package/skills/text-path-converter/README.md

@@ -1,3 +0,0 @@
-# cnb-text-relative-path-converter-skills
-
-用于AI对cnb内的资源使用相对路径的补全

package/skills/text-path-converter/SKILL.md

@@ -1,30 +0,0 @@
----
-name: CNB-Text-Relative-Path-Converter
-description: 读取 CNB (Cloud Native Build) ISSUE 或合并请求的内容时使用。将描述、评论、Review 中包含的相对路径（如 `./src/foo.ts`）转换为绝对路径，避免因路径歧义导致误读，支持纯文本与 Markdown 格式。
-requires:
-  bins: [node]
-  files: [scripts/convertLink.js]
----
-
-# CNB 文本相对路径转换器
-
-## 使用方式
-
-获取到 ISSUE 或合并请求的描述、评论、Review 的原始内容后，执行以下脚本进行转换。脚本会将所有相对路径替换为绝对路径，并将转换结果输出到标准输出。
-
-```bash
-# 执行转换，结果输出到标准输出
-node scripts/convertLink.js <在此粘贴原始内容>
-```
-
-## 示例
-
-**转换前：**
-```
-请参考 ./src/utils/helper.ts 中的实现，以及 ../docs/api.md 的说明。
-```
-
-**转换后：**
-```
-请参考 https://cnb.cool/cnb/cool/default-npc-agent/-/git/raw/main/src/utils/helper.ts 中的实现，以及 https://cnb.cool/cnb/cool/default-npc-agent/-/git/raw/main/docs/api.md 的说明。
-```