release
Maps which systems a change touches, what must move together, and records each shipped version in an immutable release table.
looks for
- "ship it", "cut a release", "tag a version"
- a change that touches both a server and its clients
- docs or store listings that may lag the code
- what still needs updating?
outputs
- → a release checklist for this version
- → a new row in {{RELEASE_TABLE}}
- → a needs-release / no-release decision with reason
SKILL.md
Release
A release is rarely one artifact. The usual failure is shipping one track and forgetting another: the app is on 1.4 while the docs describe 1.3, or the server gained a field no installed client can read yet.
1. List your systems
| System | How it reaches users | Versioned by | Moves with a release? |
|---|---|---|---|
| {{APP}} | installer / auto-updater | {{APP_VERSION_FILE}} | Yes |
| {{MOBILE}} | app stores | version + build number | Yes; build number always goes up |
| {{WEB}} | deploys on push | not versioned | No, but it is live first |
| {{DOCS}} | deploys on push | page minAppVersion | Yes; goes live with the release |
| Repo | nothing ships from it | the tag vX.Y.Z | Yes; the tag is the record |
Ordering rule. Anything that is live for everyone at once (web, API) may only add things that older clients already tolerate. Anything clients must have first waits until the release is out.
2. Before tagging
- Versions match across everything that ships together.
- Data migrations are numbered, tested and not colliding with another branch.
- Generated files are regenerated (check mode shows no diff).
- Docs and release notes for every touched screen.
- Screenshots: a missing image beats a stale one.
- Known issues updated (internal and public).
- The
verifysubagent is green.
3. After publishing
- Store listings, privacy/data-safety forms and release notes still true.
- Update feeds / auto-update manifests report the new version.
- Checksums of published files match the local build.
- Add the row to the release table.
Release table
{{RELEASE_TABLE}}:
| Version | Channel | Published (UTC) | Tag | Checksum | Mobile build | What shipped | Open issues |
- Add a row only after files are live and feeds report them.
- A version is immutable: a mistake is a new version, never an edited row.
- Promotion (beta → stable) adds a line to the existing row.
Does this need a release?
- Web/API only, additive, safe default → deploy, no release.
- Docs only → deploy docs; note which version they describe.
- Anything inside the installed app or a schema change → release.
- Both sides must change → server first, keeps answering the old shape.
Customize for your project
{{APP}},{{MOBILE}},{{WEB}},{{DOCS}},{{APP_VERSION_FILE}},{{RELEASE_TABLE}}(e.g.docs/release-status.md).- Your channels (beta / stable) and where published files live.
pairs with
- agenttrueorfalse
verify
Runs all checks to completion and reports pass/fail per suite with quoted errors, separating code failures from environment problems.
- is it green?
- a failing pre-commit hook or CI job
- a change about to be committed or merged
Claude · Codex · ChatGPT - personatrueorfalse
qa-verifier
Runs the real checks, records an honest PASS/FAIL/PENDING report in the work order, and never fakes green.
- implementation finished
- a request to close a work order or merge
- is it green?
Claude · Codex · ChatGPT - personatrueorfalse
docs-scribe
Updates the docs that a change made stale, documenting only what was actually built.
- a new or changed endpoint
- a new table, column or model field
- a new folder or module without a map
Claude · Codex · ChatGPT - skilltrueorfalse
adr
Captures one decision with its context, rejected options and consequences in a numbered, immutable record.
- a technology or vendor choice
- a change that is hard to reverse
- a decision made in chat that nobody wrote down
Claude · Codex · ChatGPT