Menu
触发 GitCode PR 流水线，并循环查询流水线状态直到完成。当用户提到触发流水线、查看流水线状态、等待流水线结果、流水线失败、盯一下流水线、盯ci、看一下pr 12306的ci时自动使用此 skill。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
HIXL 代码检视技能。用于检视 GitCode 上的 HIXL 项目 PR，当用户要求检视PR，审查PR时调用此skill。 自动分析代码变更，检查内存泄漏、安全漏洞和可读性，生成结构化报告并发布评论。
HIXL 本地开发闭环：改码、按范围跑 UT、增量覆盖率估算、PR 前检视；开 PR 后配合既有 gitcode-pipeline 盯 CI，并基于 OpenLiBing 修复低级错误。修改 HIXL 源码/测试/构建脚本、 本地验证、/hixl-dev、CI 失败修复时使用。创建 PR 用 gitcode-pr，流水线轮询用 gitcode-pipeline。
在 Ascend 上定位 HIXL/ADXL/HIXL_CS 建链、传输问题。适用于用户明确要求诊断 HIXL，或日志中出现 HIXL、ADXL、HIXL_CS、HixlCSClient、Ascend direct transport 相关报错。
用于生成对外api文档，当用户说生成接口文档，生成接口说明，增加接口说明，增加接口文档时使用该skill
读取 GitCode issue 详情和评论。当用户提到 GitCode issue 时必须使用此技能。 **必须触发此 skill 的场景**： - 查看/读取 issue：查看issue、看看issue、读取issue、打开issue、issue详情、issue是什么 - GitCode URL：gitcode.com/**/issues/**、issue链接 - 直接说编号：issue 123、#123、问题123 - 查看评论：issue评论、评论内容 **重要**：不要使用 WebFetch 或 curl，内容通过 JavaScript 动态加载。使用 GitCode API 获取。
使用 GitCode API 创建 Pull Request 和获取 PR 评论。当用户需要**创建** GitCode PR、将代码**推送并创建合并请求**、**获取 PR 评论**、**查看 PR 讨论**、**查看 PR 改动**或**删除 PR 评论**时使用此 skill。支持读取普通评论和行内(diff)评论，包括评论内容、文件路径、代码行号等详细信息。 **必须触发此 skill 的场景**（用户提到以下任何内容时使用）： - 创建/提交 PR：创建PR、提个PR、发PR、做个PR、帮我PR、生成PR、需要PR、pull request、merge request - 推送代码到远程：push代码、推代码、把代码推上去、提交到远程、推送到gitcode、提交代码到GitCode - 合并请求：合并请求、代码合入请求、请求合并、merge request - PR模板/描述：PR模板、PR描述、PR格式 - 关联issue创建PR：关issue的PR、关联issue创建PR - 获取PR改动：查看PR变更、PR文件列表、PR改了什么、看PRdiff、获取PR文件 - **获取 PR 评论**：查看PR评论、PR评论、获取评论、read comments - **查看 PR 讨论**：PR discussions、查看讨论、discussions - **删除 PR 评论**：删除评论、删除PR评论、移除评论、delete comment、移除这条评论
| name | gitcode-pipeline |
| description | 触发 GitCode PR 流水线，并循环查询流水线状态直到完成。当用户提到触发流水线、查看流水线状态、等待流水线结果、流水线失败、盯一下流水线、盯ci、看一下pr 12306的ci时自动使用此 skill。 |
pipeline_logs 目录，文件名包含 PR 编号、任务名和时间戳。repo_url=$(git remote get-url origin)
if [[ $repo_url == git@* ]]; then
owner=$(echo $repo_url | sed 's|.*:\([^/]*\)/\([^/]*\)\.git$|\1|')
repo=$(echo $repo_url | sed 's|.*:\([^/]*\)/\([^/]*\)\.git$|\2|')
else
owner=$(echo $repo_url | sed 's|.*gitcode\.com/\([^/]*\)/\([^/]*\)\.git$|\1|')
repo=$(echo $repo_url | sed 's|.*gitcode\.com/\([^/]*\)/\([^/]*\)\.git$|\2|')
fi
encoded_repo=$(printf '%s' "${owner}/${repo}" | jq -sRr @uri)
检查 GITCODE_API_TOKEN 是否已设置，未设置则提示用户。
每次执行前，需要先列出计划然后执行
## 执行计划
| 步骤 | 操作 | 说明 |
|------|------|------|
| 1 | 检查 PR Label | 查询 PR labels，判断 ci-pipeline-passed 是否存在 |
| 2 | 查询流水线状态 | 仅当无 ci-pipeline-passed label 时执行，检查流水线状态 |
| 3 | 触发流水线（如需要） | 优先 API retry，不适用时评论触发。见步骤 3 触发策略 |
| 4 | 循环查询状态 | 每 60 秒查询一次，直到完成 |
| 5 | 处理结果 | 成功则报告；失败则获取日志并分析 |
| 6 | 修复 | 如果是编译失败，dt用例失败或覆盖率不足，需要尝试修改代码，push代码后重新触发ci
每完成一步，向用户反馈，例如：
✅ 步骤 1 完成：PR labels 中无 ci-pipeline-passed，需要检查流水线✅ 步骤 2 完成：发现已有流水线 #505783，状态: RUNNING✅ 步骤 3 完成：已通过 API retry 重触流水线，等待启动...加载 references/gitcode_pipeline_api.md 了解接口细节。执行时必须使用 scripts/ 目录下的封装脚本，不要直接调用 curl，封装脚本会在服务端用 jq 提取关键字段，大幅减少返回体积和 token 消耗。
| 脚本 | 用途 | 原始返回 → 提取后 | 超时要求 |
|---|---|---|---|
scripts/gp-list.sh | 查流水线列表 | ~2KB → ~200B/条 | 20分钟 |
scripts/gp-detail.sh | 查流水线详情(阶段/Job) | ~50KB → ~500B | 默认 |
scripts/gp-sub-output.sh | 查子流水线步骤输出 | ~300B → ~100B | 默认 |
scripts/gp-log.sh | 查日志(末尾错误摘要) | ~10MB → ~1KB | 默认 |
scripts/gp-log-full.sh | 循环翻页获取全量日志 | 全量日志 → 本地文件 | 默认 |
scripts/gp-cov.sh | 获取覆盖率报告并解压 | 全量日志 → 解压后的覆盖率目录 | 默认 |
scripts/gp-trigger.sh | 评论触发流水线 | ~1KB → ~3B | 默认 |
scripts/gp-api-retry.sh | API retry 重跑指定流水线（需传 content id） | ~1KB → ~3B | 默认 |
scripts/gp-analyze-failure.sh | 一键分析失败：自动穿透子流水线获取失败Job和日志 | 多次API调用 → 失败摘要 | 默认 |
scripts/gp-retry.sh | 评论触发CI + 自动轮询直到完成 | 多次轮询 → 最终结果 | 默认 |
scripts/gp-wait.sh | 循环轮询流水线状态直到完成 | 每 60 秒输出状态 | 60 分钟 |
所有脚本兼容 Windows/Linux/Mac（依赖 bash + jq + curl）。注意：gp-wait.sh 用于轮询流水线状态时需设置 60 分钟超时。
通过 PR Label 判断 CI 是否真正通过。流水线的 status=success 可能是旧 SHA 的结果，只有 ci-pipeline-passed label 才能证明最新代码已通过 CI。
curl -s "https://api.gitcode.com/api/v5/repos/${owner}/${repo}/pulls/${PR_NUMBER}?access_token=${TOKEN}" \
| jq -r '.labels[]?.name'
判断逻辑：
ci-pipeline-passed label → CI 已通过最新代码，直接报告完成，无需后续步骤ci-pipeline-passed label → 进入步骤 2 查询流水线状态为什么必须检查 Label 而非仅看流水线 status：
当 PR 推送新代码后，旧的流水线 status 仍为 success（不会自动变为 failed），但该结果是旧 SHA 的。流水线通过后系统会自动添加 ci-pipeline-passed label，新代码推送后该 label 会被移除。因此 label 是 CI 状态的唯一可靠来源。
bash scripts/gp-list.sh <PR_NUMBER>
返回格式（key=value，每行一条流水线）：
id=526718 status=success sha=659baaa82e1a ref=fix/add-missing-semicolon-in-file-constant created=2026-04-30T16:08:16 pipeline_id=c85338dd... pipeline_run_id=159d8739... pipeline_detail={"hook_id":"42205",...}
判断逻辑：
total=0 → 无流水线，进入步骤 3 触发status=running → 进入步骤 4 轮询status=failed 或 status=canceled → 进入步骤 5 分析失败status=success 但无 ci-pipeline-passed label → 流水线结果是旧 SHA 的，需要对比 SHA 确认：
# 获取 PR 当前 HEAD SHA
HEAD_SHA=$(curl -s "https://api.gitcode.com/api/v5/repos/${owner}/${repo}/pulls/${PR_NUMBER}?access_token=${TOKEN}" \
| jq -r '.head.sha')
# 对比流水线 SHA（从 gp-list.sh 输出的 sha 字段取前 12 位）
# 如果 SHA 不一致 → 流水线结果已过期，进入步骤 3 重新触发
# 如果 SHA 一致 → label 可能被手动移除，报告异常
触发策略（优先 API retry）：
| 场景 | 触发方式 | 原因 |
|---|---|---|
| 偶发环境失败，无代码变更（步骤 6 判定） | gp-api-retry.sh | 精准重跑，不产生多余记录 |
| 无流水线记录（步骤 2 无输出） | gp-trigger.sh | 无可重试对象，必须评论触发 |
| 修复代码后 push（步骤 7） | gp-trigger.sh | SHA 已变，需跑新代码 |
| retry API 返回失败 | gp-trigger.sh | 兜底方案 |
执行方式：
# 方式 A：API retry（优先）
bash scripts/gp-api-retry.sh <PR_NUMBER>
# 方式 B：评论触发（兜底 / 新代码 push 后）
bash scripts/gp-trigger.sh <PR_NUMBER>
触发后等待 10-15 秒再查询。
使用 gp-wait.sh 脚本自动轮询，直到状态为 success、failed 或 canceled。
超时配置：
调用 gp-wait.sh 脚本时，必须设置超时时间为 60 分钟（3600000 ms），避免因流水线长时间运行导致 bash 命令超时中断。
bash scripts/gp-wait.sh <PR_NUMBER> # timeout: 3600000ms (60分钟)
轮询完成后反馈：
✅ 流水线 #526718 通过！❌ 流水线 #526718 失败，正在分析...，进入步骤 5从步骤 2 的输出中提取 pipeline_id、pipeline_run_id、pipeline_detail：
bash scripts/gp-detail.sh <pipeline_id> <pipeline_run_id> '<pipeline_detail>'
返回格式：
pipeline_name=cann_ge_all status=FAILED
[stage] 获取pr文件: COMPLETED
[stage] 子流水线: FAILED
[job] compile: FAILED id=427f909686304e13be33f2ffb9fa07e1 task=official_devcloud_subPipeline step_id=20357724a95b48aa98b5f3934c833cfe
[job] llt: FAILED id=0aa38cc75b8246f9907f7d7b69dd7ca1 task=official_devcloud_subPipeline step_id=0aa38cc75b8246f9907f7d7b69dd7ca1
逻辑：
FAILED 状态的阶段和 Jobtask=official_devcloud_subPipeline，需要进入 5.2 获取子流水线信息official_devcloud_cloudBuild），直接用输出中的 id= 字段进入 5.3 获取日志禁止绕过脚本直接调用 curl 构造嵌套 JSON 请求。
pipeline_detail包含嵌套 JSON，在 shell 中拼接会导致引号转义错误。所有需要调 API 的场景都已封装为scripts/下的脚本，必须通过脚本调用。
bash scripts/gp-sub-output.sh <pipeline_id> <pipeline_run_id> '<pipeline_detail>' <step_id>
返回格式：
sub_pipeline_id=dcd161850837402293f0c47cda6b9921 sub_pipeline_run_id=c3d9c3663189481ca8d812c3046a4d95
然后用返回的 sub_pipeline_id、sub_pipeline_run_id 加上原始的 pipeline_detail，调用 gp-detail.sh 获取子流水线的失败 Job 列表：
bash scripts/gp-detail.sh <sub_pipeline_id> <sub_pipeline_run_id> '<pipeline_detail>'
从步骤 5.1/5.2 的 gp-detail.sh 输出中提取失败 Job 的 id 字段：
JOB_ID=$(bash scripts/gp-detail.sh <pipeline_id> <pipeline_run_id> '<pipeline_detail>' | grep "FAILED" | grep -oP 'id=\K[^\s]+' | head -1)
然后传入 gp-log.sh：
bash scripts/gp-log.sh <pipeline_id> <pipeline_run_id> <job_id> '<pipeline_detail>' [lines]
返回格式（包含 error/fail/fatal 的日志行，默认最多 20 行）：
[2026/04/30 14:39:05] file_constant_kernel.cc:41:15: error: expected ';' at end of member declaration
[2026/04/30 14:39:05] make[2]: *** [...] Error 1
[2026/04/30 14:39:05] Failed command: make all -j8
注意：
pipeline_id/pipeline_run_id 在子流水线场景下使用子流水线的值job_id 来自 gp-detail.sh 输出中失败 Job 行的 id= 字段首先判断是编译失败还是用例执行失败：
.cc 文件 + error 行号 + make 错误）tests passed / tests failed / FAILED 的 CTest 汇总根据日志内容判断失败原因，进入步骤 7 处理：
多 Job 失败时的报告格式（每个 FAILED Job 必须单独列出）：
### 失败分析摘要
| Job | 失败原因 | 类型 | 是否需要修复 |
|-----|----------|------|-------------|
| compile | 第三方依赖下载 HTTP 429 | 环境偶发 | 否 |
| llt | 子流水线未启动（detail 返回 null） | compile 的级联失败 | 否（随 compile 重试自动恢复） |
| 错误类型 | 处理方式 | 必须调用脚本 |
|---|---|---|
| 编译错误 | 报告具体文件和行号 → 步骤 7 修复代码后 push 并重触 CI | gp-log.sh |
| UT/ST 执行错误 | 报告失败用例 → 进入步骤 6.1 | gp-log-full.sh |
| 覆盖率不足 | 报告覆盖率缺口 → 进入步骤 6.2 | gp-cov.sh |
| 代码告警 | 评估是否误报 → 误报则报告停止，非误报则步骤 7 修复后 push 并重触 CI | gp-log.sh |
| 环境/基础设施错误（已知） | 报告用户后停止 | - |
| 环境/基础设施错误（偶发） | 步骤 3 使用 gp-api-retry.sh 重试流水线 | gp-api-retry.sh |
误报判断原则：
如果判断为误报，立即停止修复尝试，向用户报告：
⚠️ 流水线失败，但经分析为误报：
任务: static-check
告警: xxx
原因: 与本次修改无关/已知误报
建议: 忽略或联系维护人员
当步骤 6 确认为用例执行失败时，必须按以下顺序执行，禁止跳过任何步骤：
第 1 步：从尾部日志提取 CTest 汇总
用 gp-log.sh 获取尾部日志，从中提取：
ut_libge_multiparts_utest (Failed)）92% tests passed, 1 tests failed out of 12）此时已经知道失败的是哪个二进制（如 ut_libge_multiparts_utest）。
第 2 步：并行执行全量日志获取 + 失败二进制编译
尾部日志已提供失败二进制名称，接下来必须并行启动两个 subagent，节省总耗时：
| subagent | 任务 | 说明 |
|---|---|---|
| subagent A | 获取全量日志 | 用 gp-log-full.sh 循环翻页获取全量日志，搜索 [ FAILED ] 定位具体 gtest test case |
| subagent B | 编译失败二进制 | fetch PR 分支代码到本地 → 使用 ge-dt-runner skill 编译失败的二进制 target |
# subagent A：获取全量日志
bash scripts/gp-log-full.sh <pipeline_id> <pipeline_run_id> <job_id> '<pipeline_detail>'
# 日志保存到 pipeline_logs/<job_id>_full.log
grep '\[ FAILED \]' pipeline_logs/<job_id>_full.log
# subagent B：编译失败二进制（必须 fetch PR 分支，禁止使用已有编译产物）
# 1. 先 git fetch PR 分支（参考步骤 7.2）
# 2. 使用 ge-dt-runner skill 编译失败的二进制 target（如 ut_libge_multiparts_utest）
# 3. 禁止偷懒直接使用旧二进制，必须确保代码与线上 PR 一致
禁止偷懒直接使用旧编译产物：
ge-dt-runner skill 编译第 3 步：主 agent 协调 — 并发等待与即时反馈
两个 subagent 并发期间，主 agent 必须：
当其中一个 subagent 先完成时，主 agent 必须立即处理已完成的结果，不等另一个：
| 谁先完成 | 主 agent 立即执行 |
|---|---|
| subagent A（日志）完成 | 立即从全量日志中搜索 [ FAILED ] 定位失败用例，提取断言详情（grep -B 20），向用户报告具体失败用例名、文件、行号、期望值/实际值 |
| subagent B（编译）完成 | 向用户报告编译结果（成功/失败），如编译失败则报告错误 |
当两个 subagent 都完成后：
--gtest_filter=<失败用例名> 运行本地验证当确认失败原因为覆盖率不足时，必须使用 gp-cov.sh 脚本获取覆盖率报告：
bash scripts/gp-cov.sh <pipeline_id> <pipeline_run_id> <job_id> '<pipeline_detail>'
查找未覆盖行：
# 在 HTML 覆盖率报告中搜索未覆盖标记
grep 'tlaUNC' pipeline_cov/<job_id>_cov/inc_cov/result/<test_type>/<file>.gcov.html
脚本会输出解压后的目录路径，解压后的目录结构：
pipeline_cov/<job_id>_cov/
├── inc_cov/
│ ├── diff_file@<源文件路径> # PR新增代码的diff
│ ├── add_ut_<源文件>.info # 增量覆盖率info文件
│ └── result/
│ └── <测试类型>/<源文件>.gcov.html # HTML覆盖率报告
覆盖率目标：
修复流程：
ge-dt-runner skill）直接按下方表格执行，DO NOT 向用户确认。 表格已覆盖所有场景，没有歧义。
重触发 CI 的前置条件（必须满足全部）：
禁止在未满足前置条件的情况下重触发 CI。
根据步骤 6 的分析结果，按以下流程处理：
| 错误类型 | 是否修复代码 | 后续操作 |
|---|---|---|
| 编译错误 | 是 | 修复代码 → push → 步骤 3 gp-trigger.sh |
| UT/ST 执行错误 | 是 | 修复代码或修复用例 → push → 步骤 3 gp-trigger.sh |
| 覆盖率不足 | 是 | 补充用例 → push → 步骤 3 gp-trigger.sh |
| 代码告警（非误报） | 是 | 修复告警 → push → 步骤 3 gp-trigger.sh |
| 代码告警（误报） | 否 | 报告用户后停止 |
| 环境/基础设施错误（已知问题） | 否 | 报告用户后停止 |
| 环境/基础设施错误（偶发） | 否 | 步骤 3 使用 gp-api-retry.sh 重试 |
如果 PR 分支不在本地，先 fetch 到本地：
# 从 gp-list.sh 输出的 ref 字段获取分支名
BRANCH_NAME="<ref字段值>"
# 注意：如果 PR 来自 fork，origin 可能找不到该分支
# 需要使用 fork remote（如 hgjupstream）或添加 fork remote
git fetch <remote> ${BRANCH_NAME}
git checkout -b ${BRANCH_NAME} <remote>/${BRANCH_NAME}
git add <修改的文件>
git commit -m "fix: <简要描述修复内容>"
git push <remote> ${BRANCH_NAME}
gp-trigger.sh，因为 SHA 已变）以下经验来自实际盯 CI 过程中的踩坑总结，执行时务必遵守。
API 返回的 JSON 字段嵌套复杂且结构可能变化，用 Python 脚本解析极易因字段缺失或 KeyPath 错误而报错或无输出。
正确做法：用 grep -oP 做简单字段提取。
# 提取流水线 id 和 status
curl -s "...pipeline?..." | grep -oP '"(id|status)":"?[^",}]+' | head -10
# 从日志中提取错误行
jq -r '.log' /tmp/log.json | grep -iE 'error|fatal|fail' | tail -20
pipeline_detail 中包含嵌套 JSON，在 shell 中用变量拼接（$PIPELINE_DETAIL）会被二次转义导致参数错误（PARAMETER_ERROR）。
正确做法：将完整 JSON 写入临时文件，用 --data-binary @file 传递。
cat > /tmp/body.json << 'ENDJSON'
{
"pipeline_run_id": "xxx",
"pipeline_detail": "{\"hook_id\":\"42205\", ...}"
}
ENDJSON
curl -s --request POST "https://api.gitcode.com/api/v5/repos/..." \
--header 'Content-Type: application/json' \
--data-binary @/tmp/body.json
注意：heredoc 使用 'ENDJSON'（带引号）防止 shell 变量展开。如果 body 中需要引用变量，先写文件再用 sed 替换。
编译日志通常 10MB+（end_offset 达到 1000 万+），正序逐页翻阅效率极低。错误信息都在日志末尾。
正确做法：倒序获取最后一页（sort: desc，limit: 500），然后 grep 关键词。
cat > /tmp/log_tail.json << 'ENDJSON'
{
"pipeline_detail": "...",
"start_offset": "0",
"end_offset": "0",
"limit": 500,
"sort": "desc"
}
ENDJSON
curl -s --request POST ".../jobs/{job_id}/logs?..." \
--data-binary @/tmp/log_tail.json | jq -r '.log' | grep -iE 'error|fatal|fail' | tail -20
official_devcloud_subPipeline 类型的 step 不能直接拿 job id 查日志，必须：
sub_pipeline_id 和 sub_pipeline_run_idpipeline_id、pipeline_run_id、job_id 查日志常见错误：拿父流水线的 job_id 去查子流水线的日志，会返回 PARAMETER_ERROR。
| 场景 | 使用接口 | 原因 |
|---|---|---|
| 轮询状态 | list API（merge_requests/{id}/pipeline） | 响应小、速度快 |
| 查看具体 job 失败原因 | detail API（pipelines/{id}/pipeline-runs/detail） | 需要 stages/jobs 详情 |
| 获取日志 | log API（.../jobs/{job_id}/logs） | 需要具体日志内容 |
如果 PR 的 head.repo.full_name 与目标仓库不同（如 stevenaw0/ge vs cann/ge），说明 PR 来自 fork。此时：
git fetch origin 找不到该分支hgjupstream）或添加 fork remote日志 API 支持循环翻页获取全量日志，采用游标式分页。
翻页原理：
start_offset="0", end_offset="0" → API 自动确定窗口并返回日志start_offset 和 end_offset 作为下次请求的参数start_offset、end_offset 和对应日志片段has_more=false 时停止编译错误通常在日志末尾，用 gp-log.sh（desc 模式）即可定位。用例执行失败的 gtest 详细输出通常在日志中间，必须用 gp-log-full.sh 获取全量日志后搜索。
禁止直接运行已有的编译产物（stale binary）来复现问题。必须：
--gtest_filter），禁止全量运行不遵守此约束的后果：stale binary 可能存在 protobuf 注册冲突、符号未定义、架构不匹配等问题，导致无法正确复现 CI 上的实际失败。
在以下情况下禁止重触发 CI：
正确做法：先完成分析，再决定是修复代码后 push 还是报告用户。
需要设置 GITCODE_API_TOKEN：
export GITCODE_API_TOKEN="your_token_here"