Prepare Release
DevOps & Securityprepare-releasePrepare Release is an Agent Skill for devops & security published in the mobile-dev-inc/Maestro repository on GitHub: a SKILL.md instruction file an AI agent can load to do this task.
Use this skill when the user asks to "prepare a release", "update the changelog", "bump the version", "prepare release notes", or "cut a release". Automates changelog generation from git commits since the last tag and version bumping across gradle.properties files.
How to use this skill
Bring this guide into your coding agent with a prompt tailored to the tool you use.
- Open your project in Codex.
- Copy and paste the prompt below.
- Review files and risks before approving any action.
Inspect the Agent Skill at https://github.com/mobile-dev-inc/Maestro/blob/HEAD/.claude/skills/prepare-release/SKILL.md and all supporting files. Report provenance, permissions, scripts, dependencies, and security risks. Propose an exact installation into .agents/skills/prepare-release, but wait for my approval before writing files or running scripts.
Copying this prompt does not install or run the skill. Review third-party files before use.
Prepare Release Skill
Automates the three-file release-prep workflow: CHANGELOG.md entry, and version bumps in both gradle.properties files.
Steps
1. Determine the version number
Check if the user has provided a version number in their message. If not, use AskUserQuestion to ask:
"What version number should this release be? (e.g. 2.5.1)"
Use the version exactly as provided (no v prefix).
2. Find commits since the last tag
Run these two commands:
git describe --tags --abbrev=0
Then use the resulting tag (e.g. v2.5.0) to list commits:
git log <tag>..HEAD --oneline
3. Update CHANGELOG.md
File: CHANGELOG.md
Insert a new version section between the ## Unreleased line and the first existing version header. Format:
## <version>
- <entry 1>
- <entry 2>
...
Editorial rules for commit → entry conversion:
- Each commit becomes one
-bullet point. - Strip conventional-commit prefixes (
fix:,feat:,fix(scope):, etc.) and capitalise the first word. - Remove PR number suffixes like
(#1234)only if the commit message is already clear without them; otherwise keep them. - Rewrite for clarity and consistency with the existing CHANGELOG tone (sentence case, imperative or noun phrases).
- Do not add a "Thanks to" contributors line — that is added manually.
4. Update version numbers in both gradle.properties files
Update these two files so all three files carry the same version:
gradle.properties — change the VERSION_NAME line:
VERSION_NAME=<new version>
maestro-cli/gradle.properties — change the CLI_VERSION line:
CLI_VERSION=<new version>
5. Run ChangeLogUtilsTest
./gradlew :maestro-cli:test --tests "maestro.cli.util.ChangeLogUtilsTest"
The key test (test format last version) reads CLI_VERSION from maestro-cli/gradle.properties and asserts that the CHANGELOG contains a non-empty entry for that version. All three files must be consistent for the test to pass.
Report the test result. If it fails, diagnose and fix before finishing.