Menú
Runbook for how releases, versioning, and the changelog work in this repo, and how to check or troubleshoot what is deployed.
Instalar con Codex o Claude Copia este prompt, pégalo en Codex, Claude u otro asistente, y deja que revise la página de la skill y la instale por ti.
Basado en la clasificación ocupacional SOC
Use when work may edit files, push branches, open or update pull requests, wait for CI, merge changes, or modify issue state, especially when the prompt is terse or says AFK, take to completion, fix and merge, or do not stop.
Use when two or more pull requests must be rebased, repaired, validated, queued, merged, drained, or coordinated as a set, especially for prompts such as take all open PRs, merge every PR, drain the PR queue, or orchestrate PRs.
Use when an existing pull request must be diagnosed, rebased, repaired, pushed, brought through CI, queued, or merged, including prompts such as fix this PR, rebase on main, fix CI, push back, CI pass, or merge.
Default delivery workflow for tracked repo changes. Use when the user asks to fix, add, implement, update, refactor, rename, bump, tweak, or otherwise end in a file change. Do not use for read-only questions or investigation.
Drain the ready-for-agent GitHub issue backlog: claim the oldest unclaimed issue via the lock-branch protocol, ship it through tdd-ship, label the outcome, repeat.
Review a GitHub PR of this repo: description accuracy, code quality against the project dev-skill standards, and a bug hunt with concrete failure scenarios.
| name | release |
| description | Runbook for how releases, versioning, and the changelog work in this repo, and how to check or troubleshoot what is deployed. |
| disable-model-invocation | true |
There is no manual release step: merging to main is the release. Use
this runbook to answer "how do I cut/check/troubleshoot a release".
On every push to main, .github/workflows/release.yml:
v* tag plus the
Conventional Commits since it (scripts/next_version.sh →
scripts/bump_version.py). Nothing is committed — the version lives in git
tags only; the tracked VERSION file is just the no-tags fallback.
Only feat/fix/breaking commits bump; ci/docs/test/chore-only pushes
create no tag.main branch), generates release
notes with AI from the commit log, and creates the GitHub Release.android and desktop jobs build and attach the
signed artifacts (version injected at build time by
scripts/inject_app_version.sh, not committed).Separately, ci.yml bakes the same computed version into the Docker image, so
the deployed app's /api/version and /api/changelog track main without a
post-merge bump commit.
The in-app "What's New" popup reads /api/changelog. Entries are AI-written
at build time; scripts/humanize_commits.py is the fallback that strips
Conventional-Commit jargon for customers. scripts/update_changelog.py
inserts entries idempotently. Treat all of it as generated output — never
hand-edit an entry and expect it to survive.
gh workflow run release.yml (workflow_dispatch).
If the computed tag already exists, the run is a no-op by design.curl <instance>/api/version and
compare with git tag --list 'v*' --sort=-version:refname | head -1.bumped=false from
scripts/next_version.sh), and check the release run logs:
gh run list --workflow release.yml.bash scripts/next_version.sh locally prints
version=/code=/tag=/bumped= — the same values CI uses.v* tag by hand; the workflow owns the tag namespace.CHANGELOG.md to "fix" a release.scripts/test_bump_version.py, scripts/test_update_changelog.py,
scripts/test_humanize_commits.py) via tdd-ship, like any other change.