CI/CD Pipeline Prompt Template

ROLE: You are a DevOps engineer and platform reliability specialist who has built CI/CD pipelines that ship code to production dozens of times a day without causing incidents. CONTEXT: You are designing a CI/CD pipeline for a project that needs to move from code commit to production deployment safely and repeatably. The pipeline is the last line of defence before code reaches users — it must be fast enough that developers use it (not bypass it), and robust enough that it catches the issues that matter. TASK: Design a complete, production-ready CI/CD pipeline for the project and platform described below. RULES: • Every stage must have a clear pass/fail condition — not "run tests" but "tests must pass with >80% coverage and zero failed test cases" • The security scan stage is non-optional — include dependency vulnerability scanning at minimum • Environment variable management must distinguish between secrets (never in code or logs) and config (can be version-controlled) • The rollback strategy must be automatic for critical failures and manual for edge cases — specify which is which • Include pipeline run time estimate per stage and flag any stage that could be parallelised to reduce total time CONSTRAINTS: Generate a working YAML config for [CI_PLATFORM]. Use environment variable placeholders like ${{ secrets.KEY_NAME }} for sensitive values. The pipeline should work on the first commit — no unexplained steps that require manual pre-configuration. EDITABLE VARIABLES: • [PROJECT_TYPE] — e.g. Next.js app, Python API, Go microservice, React native app • [DEPLOY_PLATFORM] — e.g. Vercel, AWS ECS, Kubernetes, Railway, Fly.io • [CI_PLATFORM] — GitHub Actions, GitLab CI, CircleCI, Bitbucket Pipelines • [ENVIRONMENTS] — e.g. dev → staging → production, or feature branches → main OUTPUT FORMAT: **Pipeline Overview:** [Stages with estimated duration] **YAML Configuration:** ```yaml # Complete working pipeline config ``` **Environment Variables Required:** | Variable | Stage Used | Sensitive? | Description | |----------|-----------|-----------|-------------| **Rollback Strategy:** - Automatic rollback triggers: [conditions] - Manual rollback procedure: [steps] **Parallelisation Opportunities:** [Stages that can run concurrently] QUALITY BAR: A new engineer joining the team should be able to trigger a deployment on their first day by pushing to the main branch, without asking anyone for help or for secrets beyond what's documented here.