github-actions-check

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

GitHub Actions Check Skill

GitHub Actions 检查技能

Operator Context

操作者上下文

This skill operates as an operator for GitHub Actions monitoring workflows, configuring Claude's behavior for automated CI/CD status checking after git operations. It implements the Observe and Report pattern -- wait for workflow registration, check status, identify failures, suggest remediation.

该技能作为GitHub Actions工作流监控的操作工具，用于配置Claude在git操作后自动检查CI/CD状态的行为。它实现了观察与报告模式——等待工作流注册、检查状态、识别失败、建议修复方案。

Hardcoded Behaviors (Always Apply)

硬编码行为（始终适用）

CLAUDE.md Compliance: Read and follow repository CLAUDE.md files before execution
Over-Engineering Prevention: Only check what's directly relevant. No speculative monitoring, no custom API scripts when gh CLI works, no workflow file modifications
Wait Before Check: Always wait 5-10 seconds after push for GitHub to register the workflow
Complete Output Display: Show full
```
gh
```
command output, never summarize as "build passed" or "tests failed"
Branch-Aware Checking: Always check workflows for the branch that was actually pushed, not default branch
Prefer gh CLI: Always use
```
gh
```
CLI over raw API calls -- it handles auth, pagination, and formatting

CLAUDE.md 合规性：执行前读取并遵循仓库中的CLAUDE.md文件
避免过度设计：仅检查直接相关内容。不进行推测性监控，当gh CLI可用时不使用自定义API脚本，不修改工作流文件
检查前等待：推送后始终等待5-10秒，让GitHub完成工作流注册
完整输出展示：显示
```
gh
```
命令的完整输出，绝不简化为“构建通过”或“测试失败”
分支感知检查：始终检查实际推送的分支对应的工作流，而非默认分支
优先使用gh CLI：始终使用
```
gh
```
CLI而非原始API调用——它会自动处理认证、分页和格式问题

Default Behaviors (ON unless disabled)

默认行为（启用状态，除非手动禁用）

Communication Style: Report facts without self-congratulation. Show command output rather than describing it. Be concise but informative.
Temporary File Cleanup: Remove any temporary scripts or cache files created during workflow status checking at task completion.
Failure Investigation: When failures detected, identify specific failing jobs and suggest local reproduction commands
Auto-fix Suggestions: For common failures (linting, formatting), provide exact fix commands without executing them

沟通风格：只报告事实，不自我夸耀。直接展示命令输出而非描述内容。简洁且信息完整。
临时文件清理：任务完成后删除工作流状态检查过程中创建的所有临时脚本或缓存文件
失败调查：检测到失败时，识别具体的失败任务并提供本地复现命令
自动修复建议：针对常见失败（代码检查、格式问题），提供确切的修复命令但不自动执行

Optional Behaviors (OFF unless enabled)

可选行为（禁用状态，除非手动启用）

Automatic Fix Application: Only fix and re-push if user explicitly requests it
Watch Mode: Only use
```
gh run watch
```
for interactive monitoring if user asks
Detailed Job Logs: Only fetch full job logs (
```
gh run view --log-failed
```
) if user needs debugging details

自动修复应用：仅在用户明确请求时才进行修复并重新推送
监控模式：仅在用户要求时使用
```
gh run watch
```
进行交互式监控
详细任务日志：仅在用户需要调试细节时获取完整任务日志（
```
gh run view --log-failed
```
）

What This Skill CAN Do

该技能可实现的功能

Check workflow run status for a specific branch after push
Identify which jobs failed and show their output
Suggest local reproduction commands for common CI failures
Report on multiple workflow runs for comparison
Show complete gh CLI output for user review

推送后检查特定分支的工作流运行状态
识别失败任务并展示其输出
针对常见CI失败提供本地复现命令
报告多个工作流运行情况以便对比
显示完整的gh CLI输出供用户查看

What This Skill CANNOT Do

该技能不可实现的功能

Auto-fix and re-push without explicit user permission
Modify workflow YAML files or CI configuration
Replace local debugging (use systematic-debugging for root cause analysis)
Replace local linting (use code-linting for pre-push checks)
Summarize or abbreviate gh CLI output

未经用户明确许可自动修复并重新推送
修改工作流YAML文件或CI配置
替代本地调试（如需根因分析请使用systematic-debugging）
替代本地代码检查（如需推送前检查请使用code-linting）
简化或缩写gh CLI输出

Instructions

操作步骤

Step 1: Identify Repository and Branch

步骤1：识别仓库和分支

Goal: Determine which repository and branch to check.

bash

undefined

目标：确定要检查的仓库和分支。

bash

undefined

Get repository from git remote

从git远程仓库获取地址

git remote get-url origin

Get the branch that was pushed

获取已推送的分支

git branch --show-current


**Gate**: Repository and branch identified. Proceed only when gate passes.

git branch --show-current


**检查点**：已识别仓库和分支。仅当检查通过时继续。

Step 2: Wait and Check Workflow Status

步骤2：等待并检查工作流状态

Goal: Allow GitHub to register the workflow, then retrieve status.

bash

undefined

目标：等待GitHub完成工作流注册，然后获取状态。

bash

undefined

Wait for GitHub to register the workflow run

等待GitHub注册工作流运行

sleep 10

Check workflow runs for the pushed branch

检查已推送分支的工作流运行情况

BRANCH=$(git branch --show-current) gh run list --branch "$BRANCH" --limit 5


Show the complete output. Do not summarize.

**Gate**: Workflow status retrieved and displayed. Proceed only when gate passes.

BRANCH=$(git branch --show-current) gh run list --branch "$BRANCH" --limit 5


显示完整输出，请勿简化。

**检查点**：已获取并展示工作流状态。仅当检查通过时继续。

Step 3: Investigate Failures

步骤3：调查失败原因

Goal: If any workflow failed, identify the specific failing jobs.

Only execute this step if Step 2 shows a failed or failing run.

bash

undefined

目标：如果存在工作流失败，识别具体的失败任务。

仅当步骤2显示运行失败或正在失败时执行此步骤。

bash

undefined

Get details of the failed run

获取失败运行的详细信息

gh run view <run-id>

For deeper investigation (only if user requests)

如需深入调查（仅在用户请求时）

gh run view <run-id> --log-failed


For each failing job, identify:
1. Which job failed (build, test, lint, deploy)
2. The specific error message
3. A local reproduction command

```markdown

gh run view <run-id> --log-failed


针对每个失败任务，需识别：
1. 失败的任务类型（构建、测试、代码检查、部署）
2. 日志中的具体错误信息
3. 本地复现命令

```markdown

Failure Report

失败报告

Job: [job name] Error: [specific error from logs] Local reproduction: [command to reproduce locally] Suggested fix: [exact commands to fix, if applicable]


**Gate**: All failures identified with reproduction commands. Proceed only when gate passes.

任务：[任务名称] 错误：[日志中的具体错误] 本地复现：[本地复现命令] 建议修复方案：（如适用）[确切的修复命令]


**检查点**：已识别所有失败并提供复现命令。仅当检查通过时继续。

Step 4: Report and Suggest

步骤4：报告结果并提供建议

Goal: Present findings and suggest next steps without auto-fixing.

If all checks passed:

Show the complete
```
gh run list
```
output
Confirm which workflows ran and their status

If checks failed:

Show the failure report from Step 3
Suggest local reproduction commands
Suggest fix commands (but do NOT execute without permission)
Ask the user if they want you to apply fixes

Gate: Complete status report delivered to user.

目标：呈现调查结果并提供下一步建议，但不自动修复。

如果所有检查通过：

显示完整的
```
gh run list
```
输出
确认运行的工作流及其状态

如果检查失败：

显示步骤3中的失败报告
提供本地复现命令
提供修复命令（但未经许可不得执行）
询问用户是否需要应用修复方案

检查点：已向用户交付完整的状态报告。

Error Handling

错误处理

Error: "gh CLI not found"

错误："gh CLI not found"

Cause: GitHub CLI not installed on the system Solution:

Check if
```
gh
```
is available:
```
which gh
```
If missing, suggest installation:
```
brew install gh
```
or
```
sudo apt install gh
```
As last resort, use
```
curl
```
with GitHub API (but prefer installing gh)

原因：系统未安装GitHub CLI 解决方案：

检查
```
gh
```
是否可用：
```
which gh
```
若未安装，建议安装：
```
brew install gh
```
或
```
sudo apt install gh
```
万不得已时使用
```
curl
```
调用GitHub API（但优先安装gh）

Error: "gh auth required"

错误："gh auth required"

Cause: GitHub CLI not authenticated Solution:

Run
```
gh auth status
```
to check current auth
If not authenticated, suggest
```
gh auth login
```
Check if GITHUB_TOKEN environment variable is set as alternative

原因：GitHub CLI未完成认证 解决方案：

运行
```
gh auth status
```
检查当前认证状态
若未认证，建议执行
```
gh auth login
```
检查是否已设置GITHUB_TOKEN环境变量作为替代方案

Error: "No workflow runs found"

错误："No workflow runs found"

Cause: Workflow not triggered, branch has no workflows, or checked too early Solution:

Wait longer (up to 30 seconds) and retry
Verify
```
.github/workflows/
```
directory exists in the repository
Check if workflow is configured to trigger on the pushed branch
Verify push event matches workflow trigger conditions

原因：工作流未触发、分支无对应工作流或检查时机过早 解决方案：

等待更长时间（最多30秒）后重试
验证仓库中是否存在
```
.github/workflows/
```
目录
检查工作流是否配置为在已推送分支上触发
验证推送事件是否匹配工作流触发条件

Anti-Patterns

反模式

Anti-Pattern 1: Checking Immediately After Push

反模式1：推送后立即检查

What it looks like:

git push && gh run list --limit 1

Why wrong: GitHub needs 5-10 seconds to register the workflow. Immediate checks show stale results from previous runs. Do instead: Always

sleep 10

between push and status check.

表现：

git push && gh run list --limit 1

问题：GitHub需要5-10秒注册工作流。立即检查会显示之前运行的过时结果。 正确做法：在推送和状态检查之间始终执行

sleep 10

。

Anti-Pattern 2: Summarizing Workflow Results

反模式2：简化工作流结果

What it looks like: "The build passed successfully." Why wrong: Hides which jobs ran, timing, warnings. User cannot verify results. Violates Complete Output Display behavior. Do instead: Show the complete

gh run list

gh run view

output verbatim.

表现：“构建已成功通过。” 问题：隐藏了运行的任务、耗时和警告信息。用户无法验证结果。违反了完整输出展示的行为要求。 正确做法：逐字显示完整的

gh run list

或

gh run view

输出。

Anti-Pattern 3: Auto-Fixing Without Permission

反模式3：未经许可自动修复

What it looks like: Detecting lint failure, then running

ruff check --fix . && git push

automatically. Why wrong: Makes code changes and git commits without user review. May introduce unintended changes. Violates optional behavior default. Do instead: Suggest fix commands and wait for explicit user confirmation before executing.

表现：检测到代码检查失败后，自动执行

ruff check --fix . && git push

。问题：未经用户审核就修改代码并提交git。可能引入意外变更。违反了可选行为的默认设置。 正确做法：提供修复命令，等待用户明确确认后再执行。

Anti-Pattern 4: Checking Wrong Branch

反模式4：检查错误分支

What it looks like:

gh run list --limit 1

without specifying

--branch

. Why wrong: May show workflow runs from other branches (main, other feature branches). Gives misleading status for the user's actual push. Do instead: Always use

--branch "$BRANCH"

with the branch that was actually pushed.

表现：未指定

--branch

参数直接执行

gh run list --limit 1

。问题：可能显示其他分支（主分支、其他功能分支）的工作流运行结果。会对用户实际推送的分支状态产生误导。 正确做法：始终使用

--branch "$BRANCH"

指定实际推送的分支。

Anti-Pattern 5: Using Raw API When gh CLI Is Available

反模式5：gh CLI可用时仍使用原始API

What it looks like: Writing 50 lines of Python with

requests

to hit the GitHub API. Why wrong:

gh

handles auth, pagination, and formatting automatically. Custom code adds unnecessary complexity and maintenance burden. Do instead: Use

gh run list

gh run view

, and

gh run watch

. Only fall back to API if

gh

is truly unavailable.

表现：编写50行Python代码，使用

requests

调用GitHub API。问题：

gh

会自动处理认证、分页和格式问题。自定义代码会增加不必要的复杂度和维护负担。 正确做法：使用

gh run list

、

gh run view

和

gh run watch

。仅在

gh

确实不可用时才回退到API调用。

References

参考资料

This skill uses these shared patterns:

Anti-Rationalization - Prevents shortcut rationalizations
Verification Checklist - Pre-completion checks

该技能使用以下共享模式：

反合理化模式 - 防止寻找捷径的合理化借口
验证清单 - 完成前检查

Domain-Specific Anti-Rationalization

领域特定反合理化

Rationalization	Why It's Wrong	Required Action
"Build passed" (without showing output)	Claim without evidence is unverifiable	Show complete gh output
"Checked right after push"	Too early shows stale results	Wait 10 seconds minimum
"Those failures are pre-existing"	Assumption without evidence	Compare with previous runs
"I'll just fix and re-push"	Auto-fixing without permission	Ask user before applying fixes

合理化借口	问题所在	要求操作
“构建通过”（未展示输出）	无证据的声明无法验证	显示完整的gh输出
“推送后立即检查了”	时机过早，显示过时结果	至少等待10秒
“这些失败是之前就存在的”	无证据的假设	与之前的运行结果对比
“我直接修复并重新推送了”	未经许可自动修复	应用修复前询问用户