# Kortix Release

How to cut a Kortix production release, the versioning philosophy (when patch vs minor...

- Repository: https://github.com/kortix-ai/suna (20345 stars)
- Category: Git and review
- License: see repository
- Last updated: 2026-11-01
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add kortix-ai/suna --skill kortix-release -g -a claude-code -y`
Codex: `npx skills add kortix-ai/suna --skill kortix-release -g -a codex -y`
Cursor: `npx skills add kortix-ai/suna --skill kortix-release -g -a cursor -y`
Gemini CLI: `npx skills add kortix-ai/suna --skill kortix-release -g -a gemini-cli -y`

## Description

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.

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

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

The rest: https://github.com/kortix-ai/suna/blob/HEAD/.agents/skills/kortix-release/SKILL.md