Claude/ChatGPT Prompt to Build a Reusable GitHub Actions Workflow

What this prompt does

This prompt makes the model act as a senior DevOps engineer and build a reusable GitHub Actions workflow, returning working YAML rather than pseudocode. Four placeholders tailor it: [purpose] (what the pipeline does), [toolchain] (the runtime and tooling), [matrix] (the dimensions to test across), and [secrets] (the secrets the workflow declares and consumes).

The structure works because it targets the real failure mode of CI: the same lint-test-build pipeline copy-pasted into every repo until one drifts and breaks silently. By asking for a workflow_call definition with typed inputs, a matrix across [matrix], correctly keyed caching, concurrency that cancels superseded runs, a factored-out composite action, and an example consumer in another repo, the prompt centralizes the pipeline so one fix lands everywhere. The cache-key emphasis matters because a bad key quietly serves stale builds. Declaring [secrets] in the workflow_call contract makes the interface explicit, so consumers know exactly what to pass, and pinning [toolchain] keeps the setup, cache, and build steps consistent with the runtime you actually ship on.

When to use it

• You keep copy-pasting the same CI pipeline into every repo and want one reusable source.
• You need a workflow_call definition with typed inputs, defaults, and declared [secrets].
• You want a matrix across [matrix] with fail-fast tuned for fast feedback.
• You need dependency and build caching keyed correctly for [toolchain].
• You want concurrency control that cancels superseded runs on the same ref.
• You need a composite action for steps repeated across jobs plus a consumer example.

Example output

Expect three separate code blocks: the reusable workflow YAML (a workflow_call with typed inputs, sensible defaults, and declared secrets, a matrix across [matrix], caching keyed for [toolchain], and concurrency that cancels superseded runs), the composite action YAML factoring out the repeated steps, and an example consumer workflow in a different repo that calls the reusable one. The whole thing reflects [purpose] so the jobs match what you actually run.

Pro tips

• Get the cache keys right for [toolchain] — a bad key serves stale builds and sends you chasing ghosts for hours.
• List [secrets] precisely so the workflow_call declares exactly what consumers must pass and nothing leaks implicitly.
• Tune fail-fast on the [matrix] to your taste: on for fast feedback, off when you want full coverage of which combinations fail.
• Keep [purpose] specific (e.g. lint + test + typecheck for Node apps) so the generated steps map to your real pipeline.
• Test the consumer workflow in a second repo before rolling it out; that is where input and secret wiring mistakes surface.
• Give typed inputs sensible defaults so most consumers can call the workflow with almost no configuration and override only when they need to.
• Move any step repeated across matrix jobs into the composite action rather than duplicating it inline, so a single edit updates every job at once.