Skip to content
SlashClone
DiscoverUse in ClaudeSubmit a link
Sign in
Made by@slashclone

Release on green

@slashclone/release-on-green

Set up a release pipeline with no manual gates: when CI passes on main, migrate the database, deploy, run a smoke test, and roll back on its own if the smoke test fails. Writes the GitHub Actions workflow for you to review; never deploys or stores secrets itself.

SkillDevOpsv0.1.0 (latest)
Use in Claude Save Like Clone Comment
Activity
New: be the first to try it

How this works

  1. It is a skill: written instructions Claude reads when your request matches what the skill is for. You do not call it by name; just ask for the task.
  2. While it works, it reads and changes files in the places it lists, nowhere else.
  3. Nothing runs until you choose to use it, and you can remove it any time.

SKILL.md

Release on green

Goal: every commit that passes CI on the main branch ships to production on its own, and a bad deploy undoes itself. People only step in when something fails.

The pipeline

  1. Trigger: workflow_run on the CI workflow, only when it concluded success, only for the main branch. Never on pull requests.
  2. Concurrency: one release at a time, cancel-in-progress: false, so a migration is never cut off. Let CI cancel older runs instead, so the newest release includes everything.
  3. Record what is live before changing anything (the current deployment id or image), so rollback has a target.
  4. Migrate the database with the project's own migration command. Migrations must be backwards compatible with the code that is still live (add columns before using them; drop them a release later).
  5. Deploy the web app, then any other services whose files changed (compare the commit range, skip what did not change).
  6. Post-deploy hooks: anything that must re-register with the new deploy (job queues, webhooks).
  7. Smoke test production with a script that retries for about two minutes (see the production-smoke-test kit).
  8. Roll back to the recorded deployment if the smoke test fails, then fail the run so the team is notified.

Steps

  1. Read the existing CI workflow and the deploy commands the project already uses. Ask which hosting providers are in play; do not guess.
  2. Write .github/workflows/release.yml with the steps above. Pin every action to a full commit SHA with the version in a comment.
  3. List the repository secrets the workflow needs (names only). Tell the person to add them with gh secret set NAME, typing the value themselves. Never ask for or print a secret value.
  4. If the host also deploys on every git push, turn that off in its config so there is one path to production.
  5. Explain how to roll back by hand and where the run logs are.

Rules

  • No manual approval steps unless the person asks for one.
  • Never put secrets in the workflow file, logs, or commit messages.
  • Least privilege: permissions: contents: read at the top, wider only on the job that needs it.

Files

  • SKILL.md
  • kit.json

Did it work?

0worked for them0did not work

Sign in to say whether it worked for you.

Nobody has said yet. Tried it? Tell the next person.