# 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.

Paste into: **Claude Code**, started in your project folder

## Prompt template

How the builder on the page fills in this template, so you can do the same:

- `{{key}}` becomes the text entered for that field, exactly as typed. Empty text, or text that is only whitespace (spaces, tabs or line breaks), counts as empty: a required field then becomes `[fill in: <label>]` with its label, and an optional field becomes nothing.
- For a choice field, `{{key}}` becomes the text of the chosen option, or of the default when none is chosen.
- Text between `{{#key}}` and `{{/key}}` stays only when that field is not empty; a choice field always counts as filled. The markers themselves are removed, and a marker that stands alone on its line takes its line break with it.
- Each value is inserted once, as it is: `{{…}}` inside a value stays as typed.

```text
Write a GitHub Actions workflow that does this on every push to {{branch}}:
{{steps}}
{{#deploy}}

Deploy details:
{{deploy}}
{{/deploy}}

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 {{branch}}.
- 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.
```

## Fields

- `{{steps}}` (required): What the workflow should do.
- `{{branch}}` (required): Branch whose pushes trigger it.
- `{{deploy}}`: Deploy details and secret names. Optional. Give the names of secrets only, never their values.

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

## 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.

## Related templates

- [Fix a build error at the root cause](https://awesomeclaudeprompts.com/prompts/fix-build-error/): 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](https://awesomeclaudeprompts.com/prompts/release-notes-from-git/): 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](https://awesomeclaudeprompts.com/prompts/follow-code-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.

## Sources

- [Claude Code docs: Prompt library](https://code.claude.com/docs/en/prompt-library) (Anthropic documentation)
- [Claude Code GitHub Actions: Protect your credentials](https://code.claude.com/docs/en/github-actions#protect-your-credentials) (Anthropic documentation)
- [Claude Code GitHub Actions: Setup](https://code.claude.com/docs/en/github-actions#setup) (Anthropic documentation)
- [Claude Code best practices: Provide specific context in your prompts](https://code.claude.com/docs/en/best-practices#provide-specific-context-in-your-prompts) (Anthropic documentation)

---

Awesome Claude Prompts is an independent project. It is not affiliated with, endorsed by, or sponsored by Anthropic. Claude is a trademark of Anthropic, PBC.