메뉴
Use this skill when releasing Kata CLI, Symphony, or the Pi Symphony extension, bumping versions, updating changelogs, or creating release PRs. Triggers include "release", "bump version", "publish", "create release PR", "ship it", "cut a release".
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use when the user wants to create the next milestone, release goal, or scoped delivery target for an existing Kata project.
Use when the user asks to plan a phase, slice upcoming work, or turn a milestone goal into executable Kata tasks.
Use when the user wants to update an in-flight Kata project, refresh project artifacts, revise the current milestone, adjust requirements or roadmap context, or pause work to record ad hoc project direction changes. This skill interactively updates durable project and active milestone artifacts without creating new execution scope.
Use this skill when the user wants to prove, test, UAT, validate, capture evidence for, or clean up backend integrations for either Kata CLI or the Symphony runtime against real GitHub Projects v2 or Linear instances. Use it for Kata CLI operation coverage, Symphony helper operation coverage, backend health checks, provider proof links, evidence bundles, cleanup of prior UAT runs, and keeping the UAT harness current when CLI or Symphony runtime contracts change.
Use when the user wants to finish, close, ship, archive, or mark the active Kata milestone complete.
Use when the user wants to execute a standalone Kata issue, one-off issue plan, backlog issue, or isolated implementation plan created by kata-plan-issue. This skill selects or retrieves an open issue from the backend, confirms the issue with the user, then executes its approved plan with fresh subagents and two-stage review per task.
| name | releasing-kata |
| description | Use this skill when releasing Kata CLI, Symphony, or the Pi Symphony extension, bumping versions, updating changelogs, or creating release PRs. Triggers include "release", "bump version", "publish", "create release PR", "ship it", "cut a release". |
Kata has three active independently versioned release targets. Ask which target if not clear from context.
| Target | Package | Tag Format | Reference |
|---|---|---|---|
| CLI | @kata-sh/cli | cli-vX.Y.Z | references/cli-release.md |
| Symphony | symphony (Rust binary) | symphony-vX.Y.Z | references/symphony-release.md |
| Pi Symphony Extension | @kata-sh/pi-symphony-extension | pi-symphony-vX.Y.Z | references/pi-symphony-extension-release.md |
Root package.json version is 0.0.0 — never touch it. The root may contain Pi package manifest metadata for monorepo git installs, but it is not the version source for any release. Each app or package owns its own version. Versions are independent and do not need to match.
| Type | When | Example |
|---|---|---|
patch | Bug fixes, small improvements | 0.4.9 → 0.4.10 |
minor | New features, backward compatible | 0.4.9 → 0.5.0 |
major | Breaking changes | 0.4.9 → 1.0.0 |
Once the target is identified, read the corresponding reference file for the full release steps, CI behavior, and acceptance criteria. Then follow it.
For build failures and CI issues, read release-troubleshooting.md.
Quick checks:
package.json (or Cargo.toml for Symphony) must differ from existing git tagsNPM_TOKEN secret is set and private: false in apps/cli/package.jsonapps/symphony/**; version in Cargo.toml must differ from existing symphony-v* tagscargo build --release locally firstapps/symphony/pi-extension/**; version in apps/symphony/pi-extension/package.json must differ from existing pi-symphony-v* tags and npm versionsNPM_TOKEN secret is set, package is private: false, and runtime dependencies are in dependenciespackage.json has a pi manifest pointing at the extension and root runtime deps include extension runtime deps such as ws