メニュー
Use when PR checks fail, CI is red, or GitHub Actions workflows break - systematically inspects failing checks via gh CLI, pulls logs, checks for flakiness and scopes the breaking commit, scopes external checks, then creates fix plan using existing plan skill
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | github-ci-fix |
| description | Use when PR checks fail, CI is red, or GitHub Actions workflows break - systematically inspects failing checks via gh CLI, pulls logs, checks for flakiness and scopes the breaking commit, scopes external checks, then creates fix plan using existing plan skill |
Systematic workflow for debugging failing PR checks using gh CLI. Identifies GitHub Actions failures with logs, scopes external checks (Buildkite, etc.) as out-of-scope, then uses existing plan workflow for fixes.
gh auth status # Required scopes: repo, workflow
STOP if unauthenticated: gh auth login --scopes repo,workflow
| Task | Command |
|---|---|
| Find current PR | gh pr view --json number,url |
| Check PR status | gh pr checks <pr> |
| View run details | gh run view <run-id> |
| Get failed logs | gh run view <run-id> --log-failed |
| Full run log | gh run view <run-id> --log |
| Recent runs for this check | gh run list --workflow <name> --branch <branch> --json conclusion,headSha,createdAt -L 20 |
| Rerun without code changes (flakiness probe) | gh run rerun <run-id> --failed |
gh auth status # If fails: ask user to authenticate
gh pr view --json number,url # Or use user-provided PR number
gh pr checks <pr> # Shows check name, status, details URL
GitHub Actions (detailsUrl has /actions/runs/): Pull logs, extract snippets, fix
External CI (Buildkite, CircleCI): Report URL only, request user to share logs
STOP: Do not attempt external CI log access.
Before treating a failure as a bug to fix, rule out flakiness — a fix for a flaky test is a wasted diagnosis, and a "fix" that just happens to make a flaky test pass on the next run isn't actually verified.
Flakiness probe:
gh run rerun <run-id> --failed # same commit, no code change
gh run view <run-id> --json conclusion --jq .conclusion # poll until done
If it now passes with nothing changed, it's flaky — report that (test name, run URL, "passed on rerun with no changes") rather than diagnosing a bug that isn't there. Don't silently move on either: a flaky check is still worth flagging to the user, since it can mask a real failure next time.
Corroborate with history, especially if a rerun isn't practical (slow or expensive job):
gh run list --workflow <name> --branch <branch> --json conclusion,headSha,createdAt -L 20
A mixed pass/fail pattern across unchanged code on recent commits is the same flakiness signal without needing a live rerun.
If it's consistently failing (not flaky), scope the breaking commit so the fix targets the actual regression instead of the whole diff since last green:
# Find the last passing SHA and first failing SHA from the run history above,
# then list the suspect commits between them:
git log --oneline <last-good-sha>..<first-failing-sha>
For a failure that's expensive to reproduce per-commit, git bisect against
the specific failing check (run it locally, or trigger the same CI job per
bisect step) narrows this further than reading the commit list alone.
# Extract run ID from detailsUrl: .../runs/<run-id>
gh run view <run-id> --log-failed # Preferred: failed jobs only
gh run view <run-id> --log # Alternative: full log
Extract 20-50 lines before failure with error messages and stack traces.
Report: GitHub Actions (name, URL, log snippet, diagnosis, flaky-or-real verdict, breaking commit if scoped) + External (name, URL, "share logs")
Plan: REQUIRED - Use EnterPlanMode. Never skip for "simple fixes".
Implement: After approval: code changes → tests → commit → push
Verify: gh pr checks <pr> then gh run view <run-id> --log-failed if still failing
# Multiple failing jobs
gh run view <run-id> --json jobs --jq '.jobs[] | select(.conclusion=="failure")'
# Log too large: use --log-failed (skips successful steps)
gh run view <run-id> --log-failed
# Re-run after fix (avoids rebuilding successful jobs)
gh run rerun <run-id> --failed
In scope: GitHub Actions failures, log extraction, flaky-vs-real triage, breaking-commit scoping, scoping external checks, plan creation Out of scope: External CI log access, fixes without plan approval, bypassing auth
gh authenticationIf you see these, STOP and follow the workflow.
| Mistake | Fix |
|---|---|
| "I'll fix it without seeing logs" | STOP. Pull logs first. |
| "It failed, so it must be a real bug" | STOP. Rerun first — rule out flakiness before diagnosing. |
| "Buildkite is just like GitHub Actions" | STOP. External checks are out of scope. |
| "Simple fix, no need for plan" | STOP. Use plan workflow. |
| "I'll parse the web UI" | STOP. Use gh CLI. |
| "Auth is optional" | STOP. Required for all operations. |
Before: Changes without seeing errors, confusion on check scope, inline plans, fixes chasing flaky tests After: Auth verification, systematic logs, flaky-vs-real triage, breaking-commit scoping, proper boundaries, plan workflow integration
Consult a stronger model mid-task for a second opinion before committing to an approach, when stuck, or before declaring a non-trivial task done — the fast-executor + strong-advisor pattern, implemented with the Agent and Workflow tools (Claude Code does not expose Anthropic's raw API advisor tool). Use when running on a cheaper/faster model for mechanical work and a hard design/architecture/risk decision needs a stronger check, or when authoring a Workflow script that should get expert review partway through instead of only at the end.
Use when the user says "caveman mode", "talk like caveman", "use caveman", "less tokens", or "be brief", invokes /caveman, or when token efficiency is requested. Switches responses to an ultra-compressed terse style (multiple intensity levels available, ~75% token reduction) while preserving full technical accuracy.
Use right after being corrected on something a CLAUDE.md file should already have told you, when explicitly asked to review CLAUDE.md, or periodically after a session with a lot of back-and-forth — reviews THIS conversation for friction and proposes a bounded CLAUDE.md edit. A lightweight, single-session complement to skill-tuning-loop (which mines many sessions and validates a proposal against held-out cases before surfacing it — reach for that instead when the ask is "make this systematic," not "check right now"). Own version of the dx plugin's `/dx:review-claudemd`.
Generate a solution, evaluate it against explicit pass/fail criteria, refine using the feedback, repeat until it passes or a round cap is hit. Use for tasks with a clear, checkable bar and demonstrable value from iteration — a bug fix that must pass a test suite, code that must satisfy a lint/style rubric, a document that must meet stated requirements. Distinct from advisor-checkpoint (one strategic consult before committing) — this is a convergence loop against a concrete standard.
Write a structured handoff document before a session ends, before a context-heavy interruption (SSH/tmux disconnect, context running low, a worktree being handed to another worker or agent), or when explicitly asked for a handoff — captures progress, what worked/failed, and the exact next step so a fresh session can resume without re-deriving context. Own version of the dx plugin's `/dx:handoff`.
Run a large batch of independent work items (a fleet-wide harvest, a multi-repo sync-down, an overnight backlog) as a persistent coordinator loop instead of one item at a time. Use when there are enough independent units of work that dispatch-review-merge would otherwise repeat many times in a row, or when the batch should keep making progress across a heartbeat interval instead of stalling until the next message.