Menu
Analyze CI test failures with parallel log analysis and root cause identification
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
| name | ci-failures |
| description | Analyze CI test failures with parallel log analysis and root cause identification |
| license | MIT |
| compatibility | Claude Code |
| metadata | {"author":"Vercel Next.js Team","version":"1.0","priority":"high","source":"https://github.com/vercel/next.js/blob/main/.claude/commands/ci-failures.md"} |
| allowed-tools | ["Bash","Read","Task","WebFetch"] |
Analyzes failing tests from CI runs with parallel subagent log analysis.
When CI tests fail, use this workflow to identify and fix issues efficiently.
# Get PR checks status
gh pr checks <pr-number> | grep -i fail
# Get failed job names from a run
gh run view <run-id> --json jobs --jq '.jobs[] | select(.conclusion == "failure") | .name'
Query all failed jobs with pagination (large repos may have 100+ jobs):
# List all jobs (paginated)
gh api repos/{owner}/{repo}/actions/runs/{run-id}/jobs --paginate \
--jq '.jobs[] | select(.conclusion == "failure") | {name, id}'
Spawn 3-4 subagents to analyze logs simultaneously. Use GitHub API for in-progress runs:
# Get logs for a specific job (works for in-progress runs)
gh api repos/{owner}/{repo}/actions/jobs/{job-id}/logs
DO NOT use gh run view --log for in-progress runs - it fails.
For each failing test, extract:
Group failures by test file path, not by CI job name. Count jobs with identical failures but report once.
| Category | Description | Example |
|---|---|---|
| assertion | Wrong output values | Expected "foo", got "bar" |
| timeout | Tests hanging | Jest timeout exceeded |
| build | Compilation errors | TypeScript error, missing deps |
| routing | Wrong routes/status | 404 instead of 200 |
| source-map | Path mismatches | webpack-internal:// paths |
| cli-output | Wrong log messages | Missing expected warnings |
| infrastructure | Transient/network | 503 errors, flaky |
# Search job logs for errors (completed runs only)
gh run view <run-id> --job <job-id> --log 2>&1 | grep -E "FAIL|Error|error:" | head -30
# Check for specific failure patterns
gh run view <run-id> --job <job-id> --log 2>&1 | grep -E "Expected|Received|EADDRINUSE|timeout"
| Pattern | Fix |
|---|---|
rust check / build failed | Run cargo fmt locally |
| Prettier errors | Run pnpm prettier --write <file> |
| Test assertion failure | Run test locally to reproduce |
| EADDRINUSE | Port conflict - check parallel tests |
| Timeout | Check for missing await, slow async ops |
# Development mode
pnpm test-dev test/path/to/test.ts
# Production mode
pnpm test test/path/to/test.ts
# With debug output
DEBUG=* pnpm test test/path/to/test.ts
Create a summary table:
| Test File | Issue | Jobs Affected | Priority |
|---|---|---|---|
test/e2e/app.test.ts | Expected "200", got "404" | 3 jobs | HIGH |
test/unit/utils.test.ts | Timeout after 5000ms | 1 job | MEDIUM |
Use when a conversation is getting long, drifting, juggling multiple tasks, re-pasting the same files, or showing stale/confused context — and at the start of any new task. Triggers: long thread, context bloat, topic switch, repeated file uploads, 'why is it forgetting', degraded answers, finished one task and starting another.
Use when a user wants to deconstruct a complex problem, business challenge, product decision, strategy question, career crossroads, or stuck situation by stripping assumptions, identifying first principles, rebuilding options from foundational truths, and choosing one high-leverage action.
Audit role-based access control and permission drift across product surfaces.
Add a new feature to an existing @fabrk/* package following monorepo conventions
Build or rebuild the ADR index and dependency graph in AgentDB
Query AgentDB with semantic routing, hierarchical recall, causal graphs, and context synthesis