check-ci

检查 CI 状态并调查故障

目标

推送提交后，监控 CI/CD 流水线状态。发生故障时，委派给 debugger 技能进行系统性调查，并基于证据分析根本原因。

输入

可选提交引用：$ARGUMENTS（例如，HEAD、abc1234、feature-branch）

• 如果未指定，则默认为当前分支上的最新提交
• --pr=<reference> — 检查此 PR/MR 的目标分支、head、策略和可合并性；生命周期调用方必须提供此参数
• --once — 读取一次并立即返回，不等待

从 --pr 解析 PR_REFERENCE；如果省略，则使用当前分支对应的未关闭变更。通过提供方将 URL 规范化为数字编号/IID，然后再调用提供方 CLI。如果同时提供了提交引用和 PR/MR，两者的完整 head SHA 必须匹配；否则返回 CI: BLOCKED，并列出观察到的两个值。

如果不存在未关闭的 PR/MR，则保留独立运行行为：解析确切的提交 SHA、与已配置远程仓库关联的规范提供方仓库，以及该仓库的默认分支，并将其设为 TARGET。读取默认目标分支的 required/strict 策略和确切 SHA 的检查，并使用相同的肯定判定条件。设置 MERGEABLE: not-applicable 和 REVIEW_REQUIREMENTS: not-required；这些字段不表示存在变更请求。如果仓库/默认目标不明确、无法读取策略，或配置证明某项必需检查仅对 PR/MR 运行，则返回 CI: BLOCKED，而不是猜测或无限轮询。

--once：单次读取模式

读取一次 CI 状态，报告结果并返回。不要监视、休眠或轮询。通过经过身份验证的 CI/forge 提供方解析完整的 head SHA、PR/MR 目标分支，以及目标分支的必需检查策略。将完整的必需检查集合与针对确切 head 报告的检查进行比较；没有失败项的汇总结果，并不能证明某项必需检查已报告。

恰好输出一行状态：

CI: PENDING  — <n> running, <n> queued, <n> completed
CI: PASSED   — <n>/<n> required checks successful; <n> optional checks terminal/non-failing
CI: FAILED   — <failing check names>
CI: NONE     — no CI configuration detected for this commit
CI: BLOCKED  — required-check policy or exact-head status cannot be observed

按以下顺序选择：无法观察到确切 head/策略证据时为 BLOCKED；没有 CI 配置时为 NONE；任何必需或可选检查终态失败时为 FAILED；有缺失/运行中/排队中的检查，或严格策略下目标分支过期时为 PENDING；只有满足下方完整判定条件时才为 PASSED。

然后为每种结果输出以下证明块：

HEAD_SHA: <full SHA>
TARGET: <target branch or none>
TARGET_SHA: <full target-tip SHA or none>
REQUIRED_CHECKS: complete | pending (<identities>) | failed (<identities>) | none-configured | unknown (<reason>)
STRICT_POLICY: required | not-required | unknown (<reason>)
UP_TO_DATE: yes | no | not-required | unknown (<reason>)
CHECKS_JSON: [{"name":"<exact name>","source":"<app or pipeline>","identity":"<provider-stable context/app identity>","required":true,"status":"<conclusion or pending>"}]
MERGEABLE: yes | no (<reason>) | unknown (<reason>) | not-applicable
REVIEW_REQUIREMENTS: satisfied | pending (<requirements>) | not-required | unknown (<reason>)

PASSED 必须满足以下所有条件：

1. 至少有一项 CI 检查或流水线已针对确切 head 配置。
2. 目标策略要求的每项检查都出现在结果中，且已有终态结论。
3. 所有必需检查的结论均为成功。
4. 所有已报告的非必需检查均已进入终态且未失败；仅在此处，skipped 和 neutral 才可接受。
5. 如果目标策略要求分支严格/保持最新，则已批准的 head 包含当前目标分支的最新提交。

缺失的必需检查状态为 PENDING，而非成功。无法读取分支策略、提供方无法枚举必需检查，或 head 不匹配时，状态为 BLOCKED。调用方可以等待 PENDING；绝不能将 NONE 或 BLOCKED 视为通过。

在等待一项从未针对草稿报告过的必需检查之前，先检查 CI 触发条件。如果提供方配置或工作流规则证明该检查只有在准备好进行评审后才会启动，或明确排除草稿，则立即返回 CI: BLOCKED — draft suppresses required CI。只要套件的先草稿契约仍然有效，就不要轮询不会发生变化的状态。Player-coach 会保留草稿，并依据此证据结束流程；绝不会仅为触发 CI 而将其标记为准备就绪。

当严格/保持最新策略适用且 head 不包含当前目标分支的最新提交时，输出 CI: PENDING — target update required，并设置 UP_TO_DATE: no。这与检查正在运行的情况不同，因此编排流程可以将过期目标作为可修复反馈发回。 本套件有意采用比某些提供商更严格的结论规则：有些提供商有时允许必需检查以 skipped 或 neutral 结束，但本套件只有成功才算满足必需检查。配置了其他 CI 时，REQUIRED_CHECKS: complete 包括没有必需检查的情况；只有 CI: NONE 时才会同时出现 none-configured。

当提交头属于一个开放的 PR/MR 时，请在同一次提供商读取中检查是否可合并，并填充 MERGEABLE。此字段不会改变 CI 状态本身；承诺 PR 可合并的调用方除了要求 CI: PASSED，还必须要求 MERGEABLE: yes。

MERGEABLE 表示确切的源代码能否集成到目标分支，且不会发生代码冲突或提交头过时违规。草稿状态和待处理的人类审批不会让 CI 或代码层面的可合并性变为非绿色；请在 REVIEW_REQUIREMENTS 中单独报告。就绪状态的调用方可以在审查待处理时继续操作。执行合并的调用方必须在合并前立即确认审查要求为 satisfied 或 not-required。

PENDING 是正常且预期的结果——请返回该结果并停止。流水线处于待处理状态时，不要启动 debugger；只有最终状态为 FAILED 时才进行调查。BLOCKED 表示提供商可观测性故障，而非代码故障，因此请报告其证据，不要启动 debugger。

此模式适用于同时处理多项工作的调用方。监视流水线意味着在 CI 完成前一直占用会话；在监控完善的项目中，这可能长达一小时——而调用方本可以将这段时间用于其他工作。负责自行安排任务的调用方需要的是随时可以快速读取的结果，而不是阻塞等待。本节以下内容均描述默认的监视模式。

默认监视器使用相同的精确提交头必需策略绑定和相同的 PASSED 判定条件。检查仍在运行或排队时，它会持续轮询。PENDING — target update required 是可采取行动的状态，而非需要等待的状态，因此应立即返回，而不是继续轮询；调用方必须纳入目标分支的更新并生成新的提交头。对 FAILED 进行调查；对于 NONE 或 BLOCKED，应报告但不要将其视为绿色状态。读取到终态或可采取行动的状态后，输出上文定义的相同状态行和完整证明块。监视只改变时机，不改变结论。

流程

1. 识别近期提交： 获取要检查 CI 状态的最新提交
2. 检测 CI 平台： 识别正在使用的 CI/CD 系统
3. 监视 CI 状态： 实时轮询 CI 流水线，直至完成
4. 处理结果：
   • 如果成功 → 显示成功摘要
   • 如果失败 → 启动 debugger 进行调查
5. 显示报告： 展示该技能的调查结果或成功状态

CI 平台检测

命令会自动检查配置文件，以检测 CI/CD 平台：

检测优先级

1. GitHub Actions

   • 检查 .github/workflows/*.yml 或 .github/workflows/*.yaml
   • 使用 gh CLI 访问 API
   • 解析工作流运行记录和作业日志

2. GitLab CI

   • 检查 .gitlab-ci.yml
   • 使用 glab CLI 访问 API
   • 解析流水线和作业日志

3. CircleCI

   • 检查 .circleci/config.yml
   • 使用检测到的令牌访问 CircleCI API

4. Jenkins

   • 检查 Jenkinsfile 或 .jenkins
   • 如果已配置 URL，则使用 Jenkins API

5. Travis CI

   • 检查 .travis.yml
   • 使用身份验证访问 Travis API

6. Azure DevOps

   • 检查 azure-pipelines.yml
   • 如果可用，则使用 Azure CLI

必需检查策略绑定

配置文件用于识别 CI 系统；经过身份验证的提供商用于识别合并目标分支所需满足的条件。发出 PASSED 前，必须解析两者。 如果没有 PR/MR，请根据确切提交配置的远程仓库解析提供方仓库，并查询其默认分支。GitHub 使用相同的分支规则，并分页查询 HEAD_SHA 的检查运行和状态，只省略 PR 审查／可合并性读取。GitLab 会枚举 SHA 等于 HEAD_SHA 的所有流水线、其作业以及项目／默认分支策略，但省略仅适用于 MR 的状态／审批读取。所有 SHA 完全匹配的流水线都计入检查；绝不能用其他引用的最新流水线替代。

**GitHub：**根据明确选定的 PR 解析规范的基础仓库，而不是检出内容的 origin，然后检查其 headRefOid、baseRefName 和 statusCheckRollup。同时查询经典分支保护中的必需状态检查，以及适用于目标分支的规则。如果策略提供了上下文和应用／集成身份，请予以保留；不得用一个提供方的必需检查来满足另一个提供方的同名结果。在同一证明过程中解析严格／最新状态策略和当前目标分支顶端 SHA。如果适用严格策略，要求提供方的合并状态不是 BEHIND，并要求比较结果证明目标分支顶端 SHA 是确切头部的祖先（或与之相同）；仅有绿色检查汇总并不足够。证明不存在策略的 404 与授权／API 故障不同。将分支名称进行 URL 编码后再插入 API 路径。

应用判定条件前，先规范化 GitHub 重试记录。按稳定的检查标识对检查运行分组：名称加应用 ID；仅当提供方字段有文档说明能在同一逻辑检查的重试间保持稳定时，才将其纳入扩展标识。绝不能使用每次运行各异的 external_id、套件 ID 或工作流运行 ID 作为扩展标识。如果 GitHub Actions 提供了关联的 run_attempt，优先选择其值最大的记录；否则选择 completed_at／started_at 最新的记录，再选择提供方 ID 最大的记录。如果无法通过稳定键区分同一应用中独立的同名检查，则返回 CI: BLOCKED，而不是猜测。按上下文加创建者／应用身份对提交状态分组，并依次按 created_at 和 ID 选择提供方记录中最新的一条；不能只依赖端点返回顺序。只有这些选出的记录才能进入 CHECKS_JSON 或必需检查评估。将被取代的记录保留为审计备注，但重试成功后，已被取代的失败记录不能导致确切头部失败。如果仍有两条记录同样是最新记录且状态冲突，则返回 CI: BLOCKED。分支策略必须匹配相同的稳定上下文／应用身份，不能仅按显示名称匹配。

TARGET_BRANCH_ENCODED=$(jq -rn --arg value "$TARGET_BRANCH" '$value|@uri')
# BASE_REPOSITORY is the provider-scoped canonical base selected from PR_REFERENCE;
# BASE_REPOSITORY_PATH is its OWNER/REPO portion for REST paths.
gh -R "$BASE_REPOSITORY" pr view "$PR_REFERENCE" \
  --json headRefOid,baseRefName,isDraft,statusCheckRollup,mergeable,mergeStateStatus,reviewDecision
gh api --hostname "$BASE_HOST" \
  "repos/$BASE_REPOSITORY_PATH/branches/$TARGET_BRANCH_ENCODED/protection/required_status_checks"
gh api --hostname "$BASE_HOST" --paginate \
  "repos/$BASE_REPOSITORY_PATH/rules/branches/$TARGET_BRANCH_ENCODED"
TARGET_REF_JSON=$(gh api --hostname "$BASE_HOST" \
  "repos/$BASE_REPOSITORY_PATH/git/ref/heads/$TARGET_BRANCH_ENCODED")
TARGET_SHA=$(echo "$TARGET_REF_JSON" | jq -er .object.sha)
COMPARE_STATUS=$(gh api --hostname "$BASE_HOST" \
  "repos/$BASE_REPOSITORY_PATH/compare/$TARGET_SHA...$HEAD_SHA" --jq .status)
case "$COMPARE_STATUS" in ahead|identical) UP_TO_DATE=yes ;; behind|diverged) UP_TO_DATE=no ;; *) exit 1 ;; esac
gh api --hostname "$BASE_HOST" --paginate -H 'Accept: application/vnd.github+json' \
  "repos/$BASE_REPOSITORY_PATH/commits/$HEAD_SHA/check-runs?per_page=100"
gh api --hostname "$BASE_HOST" --paginate \
  "repos/$BASE_REPOSITORY_PATH/commits/$HEAD_SHA/statuses?per_page=100"

**GitLab：**根据明确选定的 MR 解析规范的目标项目，而不是检出内容的 origin，然后检查其确切头部流水线、项目合并／流水线策略、目标受保护分支设置、外部状态检查、详细合并状态和审批状态。要求 MR 的 diff_refs.head_sha、选定的流水线 SHA 和请求的 HEAD_SHA 一致。根据 MR 的 head_pipeline.id 选择流水线，绝不能仅选择最新流水线。保留每个作业在提供方中的稳定流水线／作业标识。只有所有非可选作业都已进入终止状态，流水线才算完成。将 checking、CI pending、必须纳入目标分支的提交，或源分支冲突视为非绿色状态；草稿和待审批事项仅报告在 REVIEW_REQUIREMENTS 中。如果无法枚举项目策略或外部状态检查要求，则返回 BLOCKED，而不是假设没有要求。将分支名称进行 URL 编码后再插入 API 路径。

TARGET_BRANCH_ENCODED=$(jq -rn --arg value "$TARGET_BRANCH" '$value|@uri')
# Resolve BASE_SELECTOR from the explicit MR URL's project, or from the configured provider
# repository/remote for number, branch, and standalone calls.
BASE_PROJECT_JSON=$(glab -R "$BASE_SELECTOR" repo view --output json)
BASE_REPOSITORY_URL=$(echo "$BASE_PROJECT_JSON" | jq -er .web_url)
BASE_HOST=$(echo "$BASE_REPOSITORY_URL" \
  | sed -E 's#^[a-zA-Z][a-zA-Z0-9+.-]*://([^/]+)/.*#\1#')
BASE_REPOSITORY_PATH=$(echo "$BASE_PROJECT_JSON" \
  | jq -er '.path_with_namespace // .full_path')
BASE_PROJECT_PATH_ENCODED=$(jq -rn --arg value "$BASE_REPOSITORY_PATH" '$value|@uri')
BASE_REPOSITORY="$BASE_HOST/$BASE_REPOSITORY_PATH"
BASE_REPOSITORY_SELECTOR=$BASE_REPOSITORY_URL
BASE_PROJECT_ID=$(glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_PATH_ENCODED" | jq -er .id)
MR_LOOKUP=$PR_REFERENCE
case "$PR_REFERENCE" in
  http://*|https://*)
    clean_reference=${PR_REFERENCE%%\?*}
    clean_reference=${clean_reference%/}
    MR_LOOKUP=${clean_reference##*/}
    case "$MR_LOOKUP" in ''|*[!0-9]*) exit 1 ;; esac
    ;;
esac
MR_IID=$(glab -R "$BASE_REPOSITORY_SELECTOR" mr view "$MR_LOOKUP" --output json | jq -er .iid)
MR_JSON=$(glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID")
test "$(echo "$MR_JSON" | jq -er .target_project_id)" = "$BASE_PROJECT_ID"
MR_HEAD_SHA=$(echo "$MR_JSON" | jq -er '.diff_refs.head_sha // .sha')
HEAD_PIPELINE_ID=$(echo "$MR_JSON" | jq -r '.head_pipeline.id // empty')
HEAD_PIPELINE_PROJECT_ID=$(echo "$MR_JSON" | jq -r '.head_pipeline.project_id // empty')
test "$MR_HEAD_SHA" = "$HEAD_SHA"
glab api --hostname "$BASE_HOST" "projects/$BASE_PROJECT_ID" \
  | jq '{only_allow_merge_if_pipeline_succeeds, only_allow_merge_if_all_discussions_are_resolved, merge_method, squash_option}'
if [ -n "$HEAD_PIPELINE_ID" ]; then
  test -n "$HEAD_PIPELINE_PROJECT_ID" # otherwise exact project scope is unprovable: BLOCKED
  PIPELINE_PROJECT_JSON=$(glab api --hostname "$BASE_HOST" \
    "projects/$HEAD_PIPELINE_PROJECT_ID")
  PIPELINE_REPOSITORY_SELECTOR=$(echo "$PIPELINE_PROJECT_JSON" | jq -er .web_url)
  PIPELINE_JSON=$(glab api --hostname "$BASE_HOST" \
    "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID")
  test "$(echo "$PIPELINE_JSON" | jq -er .sha)" = "$HEAD_SHA"
  glab api --hostname "$BASE_HOST" --paginate \
    "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID/jobs"
fi
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID/status_checks"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID/approvals"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/merge_requests/$MR_IID/approval_state"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/protected_branches/$TARGET_BRANCH_ENCODED"
glab api --hostname "$BASE_HOST" \
  "projects/$BASE_PROJECT_ID/repository/branches/$TARGET_BRANCH_ENCODED"

如果有文档明确说明外部状态检查不可用，且返回 404，则将其视为空集合；授权失败或不支持枚举则返回 BLOCKED。如果未提供 HEAD_PIPELINE_ID，请结合项目流水线策略和仓库 CI 配置，判定为 NONE、PENDING 或因草稿而抑制的 BLOCKED；绝不能默认将流水线缺失视为成功。 对于其他提供方，请根据 harness 暴露的已认证能力，解析等效的策略和精确头状态操作。缺少等效操作时，输出 CI: BLOCKED。

监控工作流

1. 初始状态检查

# Get latest commit
git rev-parse HEAD

# Get commit details
git log -1 --format="%H %s"

# Check push status
git log "$CI_REMOTE/$BRANCH"..HEAD

2. CI 状态轮询

对于 GitHub Actions：

# List workflow runs for the exact commit; required-check truth still comes from the policy
# and exact-SHA check/status API reads above
gh -R "$BASE_REPOSITORY" run list --commit "$HEAD_SHA"

# Get run details
gh -R "$BASE_REPOSITORY" run view "$RUN_ID"

# Watch run status
gh -R "$BASE_REPOSITORY" run watch "$RUN_ID"

对于 GitLab CI：

# Read only the MR's exact head_pipeline selected above
glab api --hostname "$BASE_HOST" \
  "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID"

# Get the exact pipeline's jobs
glab api --hostname "$BASE_HOST" --paginate \
  "projects/$HEAD_PIPELINE_PROJECT_ID/pipelines/$HEAD_PIPELINE_ID/jobs"

# Get job logs
glab -R "$PIPELINE_REPOSITORY_SELECTOR" ci trace "$JOB_ID"

3. 实时更新

每 5-10 秒显示一次状态更新：

⏳ CI Status: In Progress
  ✓ Build: Success
  ⏳ Tests: Running... (2m 15s)
  ⏳ Lint: Queued
  - Deploy: Pending

故障调查

CI 失败时，将调查委派给 debugger 技能：

技能调用

使用 Skill 工具调用 debugger，并提供：

• CI 作业／流水线 ID
• 失败的作业名称
• 相关日志摘录
• 提交信息

提示词示例：

Investigate CI failure for commit [SHA]:
- Failed jobs: [job names]
- CI platform: [GitHub Actions/GitLab CI/etc]
- Job logs available via: [command to fetch logs]

Please gather evidence about:
1. What specifically failed (tests, build, lint, etc.)
2. Exact error messages and stack traces
3. Which files/changes are involved
4. Root cause based on evidence

Provide a complete investigation report.

技能将执行的操作

debugger 技能将：

1. 获取失败作业的完整 CI 日志
2. 找出确切的错误消息和位置
3. 沿执行流程追踪故障
4. 收集有关环境和上下文的证据
5. 呈现调查结果，但不提出修复方案

输出格式

默认监视器可以显示以下面向用户的摘要，但始终要以单次读取模式定义的确切 CI: 状态行和完整证明块作为结尾。生命周期调用方解析的是这项最终约定， 而不是表情符号摘要。

成功情况

✅ CI Status: All checks passed!

📊 Summary:
  ✓ Build: Success (1m 23s)
  ✓ Tests: 156 passed (2m 45s)
  ✓ Lint: No issues (0m 15s)
  ✓ Security: No vulnerabilities (0m 38s)

🎉 CI and code-level mergeability are green; review requirements are reported below.

失败情况

❌ CI Status: Failed

📊 Summary:
  ✓ Build: Success (1m 23s)
  ❌ Tests: 2 failed, 154 passed (2m 45s)
  ⚠️ Lint: 3 warnings (0m 15s)
  ✓ Security: No vulnerabilities (0m 38s)

🔍 Launching `debugger` to investigate...

然后呈现技能的完整调查报告，其中包括：

• 问题调查报告
• 收集到的证据（日志、错误、堆栈跟踪）
• 根本原因分析（基于事实）
• 受影响的组件
• 解决建议

技能报告会提供基于证据的调查结果，但不会实施修复。

错误处理

• **无 CI 配置：**输出 CI: NONE 和完整证明块
• **需要身份验证：**输出 CI: BLOCKED 和读取失败的证据
• **API 速率限制：**监视器模式下，延迟后重试；--once 模式下，输出 CI: BLOCKED
• **网络问题：**监视器模式下，采用指数退避重试；--once 模式下，输出 CI: BLOCKED
• **长时间运行的 CI：**继续等待。CI 流程复杂是特性，不是故障——见下文“耐心等待”
• **日志不完整：**尝试利用现有信息进行处理

耐心等待

运行了一小时的流水线并不意味着流水线停滞不前。在 CI 足够可靠、可用于阻止合并的项目中，测试套件本来就有意设计得很全面；而多个分支同时合并时，共享运行器会排队，因此作业甚至还没开始，就可能在 Queued 状态下等待很久。这两种情况都很正常。

因此，绝不要仅凭经过的时间就断定 CI 卡住了、出故障了或不值得继续等待。不要建议跳过 CI、通过重新运行来“解除卡住”状态，或不等 CI 就合并。只有出现终态结果、明确的 CI_CHECK_TIMEOUT，或用户要求停止时，才结束等待。达到明确超时时，最后再进行一次精确头读取，并返回 CI: PENDING — timeout reached; <n> running, <n> queued, <n> completed 以及完整证明块。超时不会将待处理检查变成失败或成功。如果没有指定超时且等待时间较长，请说明仍在等待什么，并继续等待。

平台专属功能

GitHub Actions

• 支持矩阵构建（多种作业变体）
• 下载制品以查看详细日志
• 重新运行失败作业的命令
• 工作流分派触发器

GitLab CI

• 流水线阶段分析
• 手动作业触发器
• 支持合并请求流水线
• 检测子流水线

配置选项

用户可以通过环境变量自定义行为：

• CI_CHECK_TIMEOUT：等待 CI 完成的正整数秒数（默认：未设置——无限等待）
• CI_POLL_INTERVAL：检查状态的频率（默认：10s）

最终说明

核心工作流

1. 除非另有说明，否则始终先检查最新提交
2. 自动检测 CI 平台，不要假定使用 GitHub Actions
3. 持续监控 CI 状态，无需用户输入
4. CI 完成后：
   • 成功 → 提供成功摘要及耗时详情
   • 失败 → 立即启动 debugger

技能委派

5. 启动 debugger 时：
   • 提供提交 SHA 和任务详情
   • 附上用于获取相关日志的命令
   • 指明哪些任务失败
   • 让该技能进行系统性调查

报告

6. 提供该技能的完整调查报告
7. 该技能的报告将以证据为依据，而不是以解决方案为导向
8. 绝不自动修改代码或实施修复
9. 呈现调查结果后，等待人工决定后续步骤

错误处理

10. 如果仓库使用多个 CI 平台，则一并处理
11. 如果 CI 仍在运行，继续等待并报告进度——流水线耗时较长并不代表已停滞

使用示例

# Check CI for latest commit
/check-ci

# Check CI for specific commit
/check-ci abc1234

# Check CI for a branch
/check-ci feature/new-api