القائمة
Analyze CI test failures with parallel log analysis and root cause identification
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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