Write a GitHub Actions CI workflow

Have Claude Code write a GitHub Actions workflow from your project's own build and test commands, with secrets referenced by name and nothing pushed.

Task: Write a GitHub Actions CI workflow · Other tasks

Fill in the details

What the workflow should do (required)

Branch whose pushes trigger it (required)

Deploy details and secret names

Optional. Give the names of secrets only, never their values.

Copy your prompt

This site doesn't run Claude or show model output. Results depend on your input and the model you use.

Your prompt (you can edit it)

Write a GitHub Actions workflow that does this on every push to [fill in: Branch whose pushes trigger it]:
[fill in: What the workflow should do]

First read how the project installs dependencies, builds and runs its tests (package files, scripts, Makefile, README), and look at any workflows already in .github/workflows. Use the commands the project already uses rather than new ones. If an existing workflow covers part of this, propose extending it instead of adding a duplicate.

Requirements:
- Refer to secrets only through the GitHub secrets context. Never write a secret value into the file, and list every secret I need to add in the repository settings.
- Give the workflow only the permissions it needs.
- Any deploy step runs only after the tests pass, and only for pushes to [fill in: Branch whose pushes trigger it].
- Pin each action to a version.
- If a step needs information you cannot find in the repository, such as a deploy target, add a clear TODO comment instead of guessing, and list it.

Create or edit only the workflow file. Do not commit, push or trigger a run. If a linter for workflow files is installed, run it on the file.

Report: the file path, one line per job and step explaining what it does, the secrets and settings I must add, the TODOs, and how I can try the workflow safely before relying on it.

2 required fields are empty.

What you type is kept in this tab's session storage so a reload doesn't lose it. Use "Clear this task" to remove it. Browsers can restore session data when they reopen tabs, so closing a tab isn't a guaranteed way to erase it.

When to use this template

Your repository is on GitHub and has no CI yet, or its workflow is out of date, and you want a first version built from the commands the project already uses.
You can say in a sentence what should happen on a push, such as testing and then deploying, and want the YAML, job order and conditions worked out for you.
You want a workflow file you can read and review before anything runs, with the secrets it needs listed by name.

When not to use it

You want Claude itself to run in your workflows, for example to answer @claude mentions in pull requests. That is the Claude Code GitHub Action; run /install-github-app in Claude Code to set it up.
Your CI runs somewhere other than GitHub Actions. Adjust the first sentence of the prompt for your CI system, since the GitHub-specific requirements will not apply.
The deploy needs credentials or infrastructure decisions that nobody has made yet. Settle where staging lives and how it is reached first, or the file will be mostly TODOs.

Why this structure

Reading the project before writing anything is the first instruction, so the workflow runs the install, build and test commands the project really uses instead of generic ones.
The check for existing workflows avoids a second file that runs the same tests twice on every push.
The secrets rule follows the advice in the Claude Code GitHub Actions docs: keep keys and tokens in GitHub Secrets and only reference them from the workflow, so the file itself holds no secret values.
Minimal permissions and "deploy only after the tests pass" are written as requirements, because a workflow that deploys on a red build or has broad write access is hard to spot in review.
TODO comments instead of guesses make the gaps visible. An invented deploy target can look correct in YAML and fail only when it runs.
The last rule keeps this to one file on your machine: no commit, no push and no triggered run, so you decide when the workflow first goes live.

Example input (fictional)

What the workflow should do

Install dependencies, run the linter and the tests, and if they pass, deploy to staging.

Branch whose pushes trigger it

main

Deploy details and secret names

Deploy with scripts/deploy.sh staging. It needs the secrets STAGING_HOST and STAGING_DEPLOY_KEY.

Follow-ups to send Claude

Add a job that runs the tests on pull requests to main as well, without the deploy step.
Cache the dependency install between runs, using the cache option that fits this project's package manager.
Walk me through what happens step by step on a push where the tests fail, and on one where they pass.

Common mistakes

Pasting secret values into the deploy field. Give names only; add the values yourself in the repository settings.
Pushing the workflow straight to the default branch with a deploy step you have not tried. Try it on a branch or with the deploy step disabled first.
Describing the steps in general terms such as "the usual checks". Name what must run and in which order, so the jobs and their conditions come out right.

Fix a build error at the root cause: Paste a build error; Claude Code reproduces it, fixes the root cause without suppressing the error, and shows the build and tests passing again.
Draft release notes from git history: Have Claude Code compare two git tags or branches and draft release notes grouped into breaking changes, features and improvements for your readers.
Build something new from an existing pattern: Point Claude Code at code that already works the way you want, so the new feature matches its structure, naming, tests and error handling.

See all templates

Sources

Claude Code docs: Prompt library (Anthropic documentation)
Claude Code GitHub Actions: Protect your credentials (Anthropic documentation)
Claude Code GitHub Actions: Setup (Anthropic documentation)
Claude Code best practices: Provide specific context in your prompts (Anthropic documentation)