ci-debugger

CI Debugger

Goal

Find the first meaningful CI failure, explain the root cause with evidence, propose the smallest fix, and recommend the validation command that should prevent recurrence.

When to use

• A CI, build, deploy, or package-manager job failed.
• The user provides logs, a run URL, or asks to inspect CI live.
• Long logs need targeted extraction instead of full dumping.

When not to use

• The user asks for broad repo health rather than one failed pipeline.
• The failure requires production incident response beyond CI diagnosis.
• The user wants dependency risk review without a failing job; use dependency-update-review.

Inputs

• CI provider, workflow/job name, run URL, failed step, and logs.
• Package manager output, build artifacts, test reports, and recent diffs.
• Repo scripts, workflow YAML, and environment requirements.

Inputs to inspect

• Inspect the failed step, first meaningful error, relevant workflow config, package scripts, and changed files.
• Use targeted log excerpts instead of dumping full logs.

Process

1. Identify the failed job and failed step.
2. Extract the first meaningful error, not the last cascade.
3. Search logs with targeted patterns and inspect nearby context.
4. Map the failure to code, config, dependency, environment, or infra.
5. Propose a minimal fix and a regression validation command.
6. Avoid broad rewrites unless the failure proves a systemic issue.

Workflow

Follow the process above and verify the minimal fix locally when possible. Report skipped live CI checks explicitly.

Decision points

• If logs are incomplete, ask for the failed step or run URL.
• If credentials or external services are required, separate local validation from live validation.
• If multiple jobs fail, group by shared root cause before fixing each.

Safety rules

• Do not paste full secrets from logs.
• Do not rerun expensive or write-capable workflows without approval.
• Do not assume downstream failures are separate bugs until the first failure is resolved.