What this prompt does
This prompt scaffolds a complete GitHub Actions CI/CD pipeline for a [project_type] project. It produces ten coordinated workflows: PR checks (lint with [linter], test with [test_command], type check, security scan), build-and-artifact on merge to [main_branch], staging deploy on [staging_branch], gated production deploy, a rollback workflow, a scheduled dependency audit ([audit_schedule]), semantic-versioned releases, a cache strategy for [cache_targets], matrix testing across [test_matrix], and Slack failure notifications, all using reusable workflows and composite actions.
The structure works because it wires the trust-building pieces in from the start: PR gates, security scanning, a real rollback path, and concurrency controls. A pipeline people don't trust gets bypassed, so the prompt deliberately includes notifications and concurrency so failures are visible and runs don't stomp on each other. The reusable-workflow and composite-action emphasis keeps the YAML from rotting into copy-pasted duplication as the project grows.
When to use it
- Standing up CI/CD for a new repo before bad habits calcify.
- Adding a real rollback and staging path to a pipeline that only does "deploy on merge."
- Introducing security scanning and scheduled dependency audits to an existing project.
- Setting up matrix testing across
[test_matrix]to catch version-specific breakage. - Consolidating duplicated workflow YAML into reusable workflows and composite actions.
- Wiring Slack notifications so a failing pipeline is impossible to ignore.
Example output
You get a set of YAML workflow files plus supporting config: a PR-check workflow running [linter] and [test_command], a build workflow, environment-gated deploy workflows for staging and production, a rollback workflow, a scheduled audit on [audit_schedule], a release workflow with changelog generation, cache configuration for [cache_targets], a test matrix block, reusable/composite action definitions, secrets setup notes, and concurrency controls. Expect to adapt secret names and deploy steps to your provider.
Pro tips
- Set
[test_command]to your exact command including coverage flags, so the generated job matches what runs locally. - Keep
[cache_targets]tight; caching the wrong directories can cache stale builds or balloon storage. - Use real branch names for
[main_branch]and[staging_branch]; mismatches silently skip workflow triggers. - Treat the generated secrets as placeholders and wire them through GitHub Environments for the production gate.
- Validate the
[test_matrix]against versions you actually support; testing dead versions wastes minutes. - Run the production deploy behind manual approval first, then automate once the rollback workflow is proven.
