Menu
Watch a GitHub Actions CI run, diagnose failures from logs, apply fixes, re-push, and repeat until green or escalate. Use when CI is failing and the user wants to debug and fix it iteratively, or says "fix CI", "debug the build", or similar.
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
Use when asked to rewrite or format text in the user's voice, "make this sound like me", "match my voice", "de-stiffen this", when text "reads too corporate / businessy / stiff", to "strip the em-dashes / agent typography", or to draft a Slack announcement, PR body, or doc in the user's voice. Also /match-voice.
Use when writing or rewriting reader-facing technical text — documentation, READMEs, runbooks, procedures, error messages, release notes, incident reports, API guides, agent/system prompts — or when asked to "de-slop", "make this readable", "simplify this doc", "write for non-native readers", "apply STE", "Simplified Technical English", or "ASD-STE100", or to prepare text for translation. Also use to CHECK such text for clarity violations. Do NOT use for chat replies, PR/review comments, or commit messages (that is terse-output), nor for marketing, brand, or personal-voice writing (that is match-voice) — this skill deletes persuasion by design.
Use when the user asks for a deep review, full review, comprehensive review, production readiness assessment, full audit, multi-domain audit, "security and reliability and code review", or "review everything". Also use when the user explicitly requests performance review alongside the comprehensive request (e.g. "include perf", "review including performance", "deep review with perf"); without that explicit phrasing, performance is excluded. Do NOT use for narrow single-domain reviews (use the matching review-* skill directly).
Review code architecture (SOLID, design patterns, package design, coupling, testability), Go best practices, and protobuf/API design using manual analysis and static analysis tools (gocyclo, staticcheck, buf). Use when the user asks for a code review, architecture review, Go review, protobuf review, SOLID review, or design pattern review.
Use when the user wants to execute an approved implementation plan and says any of "do it" (with a plan in scope), "lets do it" / "let's do it", "confirmed" (as approval to proceed on a plan), "implement the plan", "implement this", "execute the plan", "start implementing", "work through the plan", "implement the next phase", "build it out", "knock out the plan", or "/implement-plan PATH". Also use when a plan file (`./.plans/PLAN.md`, any `./.plans/*.md`, or legacy `./PLAN.md` / `./docs/plans/*.md`) is present and the user signals readiness to begin coding. Do NOT use when the user is still discussing, refining, or asking questions about the plan, nor when no plan exists — short imperatives like "do it" or "confirmed" alone are ambiguous; verify a plan is in scope before activating.
Use when the user asks to review the plan, sanity-check the plan, vet the plan, evaluate the plan, "is this plan ready", feasibility check on a plan, "review-plan PATH", or when another skill (like implement-plan) requests pre-flight plan evaluation before execution. Do NOT use when no plan file is in scope (the user is likely asking for a summary — use Read instead), nor when the user is asking about source code (use review-code), nor when the user wants documentation review (use review-documentation).
| name | ci-debug-loop |
| description | Watch a GitHub Actions CI run, diagnose failures from logs, apply fixes, re-push, and repeat until green or escalate. Use when CI is failing and the user wants to debug and fix it iteratively, or says "fix CI", "debug the build", or similar. |
Iteratively watch CI, diagnose failures, fix, and re-trigger until the run passes or escalation is needed.
Find the latest run for the current branch:
gh run list --branch $(git branch --show-current) --limit 1 --json databaseId,status,conclusion,name
If a specific run ID or workflow is provided by the user, use that instead.
If the run is still in progress:
gh run watch <run_id> --exit-status
If it already completed, proceed to diagnosis.
On failure, fetch logs for the failed job(s):
gh run view <run_id> --log-failed
Delegate log analysis to a two-stage subagent pipeline when the failed-log output is more than ~200 lines. CI logs flood main context fast and the parent only needs the root cause, not the raw output. Per parallelize-subagents, delegate-investigation, and subagent-model-routing:
Stage 1 — Extract (Haiku): Spawn an Explore subagent (model: haiku) per failed job (parallel if multiple jobs failed). Prompt: paste the command to fetch the log (not the log itself); ask for "first failing assertion + ~10 lines of surrounding context, ≤50 lines, prefixed with Status: ...". Haiku handles the mechanical extraction; no interpretation needed at this stage.
Stage 2 — Interpret (Sonnet): After Stage 1 completes, spawn a generalPurpose subagent (model: sonnet) with the Stage 1 structured output pasted inline plus the failure categories below. Ask for "likely root cause + file:line if identifiable, ≤100 words, prefixed with Status: ...".
For short logs (<200 lines), inspect inline.
Common failure categories:
If the fix is mechanical (typo, missing flag, wrong version, import ordering, fmt issue):
If the fix requires a design decision or is ambiguous:
After pushing the fix, wait for the new run to appear:
gh run list --branch $(git branch --show-current) --limit 1
Then watch it (back to step 2).
Stop and escalate to the user if:
Report what was tried, what failed, and what options remain.
Escalate to bisect when log analysis can't pinpoint which change broke the job. Typical signs: failure looks unrelated to the recent diff, error message points at code untouched in the branch, or a previously-green test on the same branch is now red. Hand the failing test/command to /bisect as the reproducer; it isolates the offending commit.
~/.claude/rules/probe-not-assume.md: confirm via tool/command before recommending; do not infer.