What this prompt does
This prompt generates a production-ready GitHub Actions workflow for a [language] project using [framework]. It wires the workflow to run on your [trigger_events], sets up a version matrix across [versions], and caches dependencies for [package_manager]. From there it runs linting and static analysis, executes your test suite with [test_runner], uploads coverage to [coverage_tool], builds artifacts, and deploys to [deploy_target] on main-branch merges.
The structure works because it covers the pieces that make CI fast and safe rather than just "run the tests". Dependency caching keeps runs quick, a sensible [versions] matrix catches version-specific breakage, and proper secret handling keeps deploys from leaking credentials. By adding concurrency controls and failure notifications to Slack or Discord, it produces a workflow that behaves well under real team activity instead of a fragile demo pipeline. It also folds in linting and static analysis before tests, status badges for the README, and a build step that produces the artifacts you actually deploy, so the workflow is a single source of truth for quality gates rather than a scattered set of scripts that each contributor runs differently on their own machine.
When to use it
- You are setting up CI/CD for a new
[language]/[framework]project from scratch. - You want dependency caching for
[package_manager]so runs stay fast as the project grows. - You need to test against multiple
[versions]and want a matrix instead of a single runner. - You want coverage automatically uploaded to
[coverage_tool]on every push. - You need automated deploys to
[deploy_target]gated on main-branch merges. - You want failure notifications and concurrency controls so the pipeline plays nicely with a team.
Example output
Expect a complete workflow YAML: triggers for your [trigger_events], a matrix block covering [versions], cache steps for [package_manager], jobs for linting, static analysis, and [test_runner] tests with coverage upload to [coverage_tool], a build step, and a deploy job targeting [deploy_target] on main. Concurrency controls, status badges, and Slack or Discord failure notifications are typically included as part of the file.
Pro tips
- Set
[versions]to the runtimes you genuinely support; testing against versions you do not ship just slows the pipeline. - Match
[package_manager]exactly (Composer, npm, pnpm) so the cache keys and lockfile handling are correct. - Keep all credentials in GitHub secrets and let the deploy step reference them; never inline values for
[deploy_target]. - Use concurrency controls to cancel superseded runs on the same branch, which saves minutes on busy repositories.
- Start the
[deploy_target]job behind a manual approval or main-only condition until you trust the pipeline end to end. - Iterate by pasting a failing run's logs back and asking it to harden the specific step that broke.
