CI/CD & Deployment Prompts

What's Inside

• ▸Failing-build diagnosis (path aliases, workspace deps, compile-vs-runtime)
• ▸Broken HEALTHCHECK / readiness-probe fixes for multi-target images
• ▸Safe Kubernetes rollouts + stuck-rollout ("pushed but didn't pull") recovery
• ▸Rollback-to-last-known-good incident response
• ▸CrashLoopBackOff & post-deploy 5xx/outage triage
• ▸Post-deploy health verification that proves it, not just "pushed"
• ▸CI/CD pipeline reliability audit + conventional commits & deploy notes
• ▸Deployment observability and rebuild-safe config & secrets

Try One Before You Buy

Published verbatim from the pack: “Diagnose a failing container build” — When your image build breaks and the error is noisy or misleading.

You are a senior build engineer. My container build for {{service}} is failing.

Error output:
{{paste_build_output}}

Work in this order and stop at the first real cause:
1. What changed most recently? Check for uncommitted or recent edits to build
   config (tsconfig/paths, package manifests, lockfiles, base image tag).
2. Is it a dependency-resolution failure (workspace/monorepo package not found,
   missing lockfile entry) rather than a code error?
3. Is it a compile/type error that will ALSO fail at runtime if forced through?
   Flag these — do not suggest suppressing them.
4. Only after 1–3, look at the build tool itself.

Output: the single root cause, the minimal fix, and one check to confirm the
fix before I push.

Why it works: Real build breaks are usually a recent config change or an unresolved workspace dep masquerading as a code error — chase those before touching the Dockerfile.

Every prompt in the pack ships with a when-to-use line and a why-it-works note like this one.