When to use this
- Before a production release/deploy, especially one with migrations, config changes, or a rollout plan.
- Building a repeatable release checklist for a team that doesn't have one yet.
- Not a replacement for automated deploy gates where they exist -- this is for the parts that still need a human check.
The skill file
Copy this verbatim. It's written in the SKILL.md format (YAML frontmatter + markdown instructions) that Claude Code, and increasingly other agent tools, read directly.
--- name: release-checklist-runner description: Walk a specific release against a concrete pre-release checklist (migrations reviewed, rollback plan exists, feature flags configured, monitoring in place) and report which items are actually verified vs. still open. Use before a production deploy. --- # Release Checklist Runner Every item gets a real answer -- confirmed (with how), not confirmed, or not applicable (with why) -- never a blanket "looks good." ## Checklist 1. **Database migrations**: reviewed for backward compatibility with the currently-running previous version (can old code run against the new schema during a rolling deploy)? Reversible, or is there an explicit accepted reason it isn't? 2. **Feature flags**: does new behavior ship behind a flag if it's risky or incomplete? Is the flag's default state correct for this release? 3. **Breaking changes**: does anything in this release break a consumer (internal service, API client, mobile app on an older version)? Cross- check with breaking-change-detector if relevant. 4. **Rollback plan**: is there a concrete, fast way to revert if this release causes a problem -- and does it actually work given any migrations included (a migration that isn't backward-compatible can make rollback impossible without a second migration)? 5. **Monitoring/alerting**: are there dashboards/alerts that would catch a regression from this specific release, or is the team relying on user reports? 6. **Dependencies**: any new external dependency (service, third-party API) whose availability this release now relies on? ## Output The checklist with a real status per item -- never mark something confirmed without stating what was actually checked to confirm it.
Installing it elsewhere
The frontmatter/body split above is Claude Code's convention. Here's how to carry the same instructions into other tools:
Save the file below verbatim (frontmatter included) at that path, project-local or in ~/.claude/skills/ for a user-level skill. Claude Code loads the name/description pair to decide when to pull it in, or you invoke it directly as /release-checklist-runner.
Convert the YAML frontmatter to Cursor's rule format (description, globs, alwaysApply: false) and keep the markdown body as the rule content. Cursor surfaces it by description match, same idea as Claude Code's auto-load.
Codex CLI (and increasingly other agentic CLIs) read AGENTS.md at the repo root as always-on instructions. Paste the markdown body under a heading like ## {title}; for GitHub Copilot's coding agent, the equivalent file is .github/copilot-instructions.md.
Append the markdown body to .windsurfrules at the repo root. Windsurf treats the whole file as always-on context, so keep only the instructions you want applied on every request.
- Marking an item "done" without stating what was actually checked -- a checklist that's rubber-stamped is worse than no checklist.
- Missing that a migration is backward-incompatible, which breaks a rolling deploy or makes rollback impossible.
- Treating "we have a rollback plan" and "the rollback plan actually works with this release's migration" as the same thing.