Kortix Release
How to cut a Kortix production release, the versioning philosophy (when patch vs minor...
Install
npx skills add kortix-ai/suna --skill kortix-release -g -a claude-code -y- Repository
- kortix-ai/suna20.3k
- Category
- Git and review
- Updated
- 3d ago
- License
- See repository
- Context cost
- Mediumabout 3,000 tokens
- Runs scripts
- No, instructions only
What it does
How to cut a Kortix production release, the versioning philosophy (when patch vs minor vs major) and the exact flow: one Promote to Production dispatch takes the dev HEAD through staging to a release PR into prod, whose one release suite is the only gate; fix forward on dev until it is green, then merge and verify prod. Load WHENEVER the user wants to release, promote, cut/ship a version, publish a release, bump the version, or asks why a promotion is stuck. Load it too whenever another skill or doc needs to describe the release/promotion flow, this file is the one place it is written out in full.
Kortix Release
How a clean, accurate production release happens. Three parts: what version
(the bump philosophy), how a candidate gets tested (one Promote dispatch takes
the dev HEAD through staging to a release PR; its one release suite is the
only gate), and how prod gets it (merge → deploy → verify). The release notes you write become the GitHub Release, which
the public /changelog/releases page (Release history) renders as written, and the
weekly /changelog page merges by section (New / Improved / Fixed) into the
week the release was published, so they must reflect what actually shipped,
nothing invented, nothing missed.
Pairs with kortix-voice (how the notes read) and kortix-rollback (the
reverse direction). The version source of truth is the root VERSION file;
vX.Y.Z tags are immutable and map 1:1 to a commit + image.
This file is the single source of truth for the promotion flow. AGENTS.md
(CLAUDE.md), .agents/skills/contributing/SKILL.md, and
.agents/skills/testing/SKILL.md state only their own slice, what CI runs on
a PR into dev versus the release PR, and point here for the rest.
0. Golden rule, one dispatch, one suite, one gate
The only normal way to change prod is one Promote to Production dispatch.
It takes the dev HEAD, merges it into staging itself (a PR that runs
nothing), waits until staging serves that SHA, and opens the release PR into
prod. That PR runs the release suite once: the contract lanes on the
release tree, the deployed smoke and the browser journeys against staging,
CI, CodeQL and the scanners. Its check full suite + quality gates requires
every one of them green, and it is the only check that blocks anything
(testing reset, 2026-10-16). Never git push …:prod, never open a manual PR
into prod, never cherry-pick onto prod.
