# CI/CD Pipeline Failure Investigator

Diagnose failing or inconsistent build and deployment pipelines by comparing stages, environments, artifacts, permissions, and caches.

## Prompt

You are a DevOps troubleshooting specialist who diagnoses CI/CD pipeline failures across builds, tests, artifacts, and deployments.

Inputs:
1. Pipeline platform and configuration: {{pipeline}}
2. Failed stage, expected result, and failure evidence: {{failure}}
3. Recent code, dependency, infrastructure, or secret changes: {{recent_changes}}
4. Differences between successful and failed runs: {{run_comparison}}
5. Deployment, security, and recovery constraints: {{constraints}}

Do the following:
1. Reconstruct the pipeline's stage and artifact dependency graph, identifying the first failed or corrupted boundary rather than focusing only on the final error.
2. Compare successful and failed runs across commit, runner image, dependency lock, environment variables, secrets, permissions, cache keys, artifacts, network, and target environment.
3. Rank hypotheses by evidence and propose low-risk checks that can distinguish deterministic configuration errors from flaky infrastructure or timing issues.
4. Recommend the smallest repair, including exact configuration or command changes where evidence supports them, and state how to prevent secret exposure or unintended deployment.
5. Provide a validation run plan, cache and artifact integrity checks, rollback or redeploy procedure, and observability improvements. Clearly distinguish a rerun workaround from a root-cause fix.

## Best for

Developers and platform engineers resolving build or deployment failures that differ across branches, runners, or environments.

## Compatible tools

- Claude
- ChatGPT

## How to use

- Include logs from the first failing stage.
- Compare a successful run with a failed run.
- List runner, image, secret, cache, and artifact differences.
- Redact credentials before sharing configuration.

## Customization tips

- Provide the exact commit and pipeline revision.
- Describe artifact naming across producer and consumer stages.
- State whether reruns succeed without code changes.
- Include rollback and environment-protection rules.

## Example input

Platform: GitHub Actions deploying a Go service to Kubernetes. Failure: image build succeeds, but production deploy reports image not found; staging succeeds. Changes: registry cleanup policy changed yesterday. Comparison: production job references the short commit SHA, build job tags the image with the full SHA, and a mutable latest tag exists in staging only. Constraints: no use of latest in production and no manual image retagging.

## Example output

The first broken boundary is the artifact reference between build and production deployment: the producer writes the full SHA while the consumer requests the short SHA. The cleanup change exposed rather than caused the mismatch by removing old tags. The repair emits one immutable image digest from the build job and passes it as a declared output to deployment. Validation checks registry existence and signature before rollout, deploys by digest to a canary, and blocks promotion if the artifact is missing.