// Release engineering tasks — version bumping, building release APKs, tagging releases, writing changelogs. Use when the user asks to prepare a release, bump version, tag, or build for distribution.
| name | release-engineering |
| description | Release engineering tasks — version bumping, building release APKs, tagging releases, writing changelogs. Use when the user asks to prepare a release, bump version, tag, or build for distribution. |
| argument-hint | task description |
You are performing release engineering tasks for Low Budget Voice Recognition Input.
This project is in active early development (milestone 2 of 7). There is no public release yet, no signing keystore, no distribution channel chosen, and the project is not under git.
If the user asks to "release" or "tag" something today, stop and confirm what they actually want — most likely they mean a build for personal testing rather than a public release.
From app/build.gradle.kts:
"1.0" (currently a placeholder — change to semver MAJOR.MINOR.PATCH before any real release)1 (monotonic integer)There is no bumpPatchVersion task today; bumps are manual edits to app/build.gradle.kts.
./gradlew :app:assembleDebug # Debug build → app/build/outputs/apk/debug/
./gradlew :app:assembleRelease # Release build (currently unsigned, isMinifyEnabled = false)
./gradlew :app:test # Unit tests
./gradlew :app:connectedAndroidTest # Instrumented tests
./gradlew :app:clean
The release variant currently has isMinifyEnabled = false and no signing config — it is not shippable as-is.
Ask the user about each of these before assuming a workflow:
project_design_decisions memory).fastlane/metadata/android/.../changelogs/<versionCode>.txt — adopt the same? Or keep changelog inline in README.md / GitHub Releases?X.Y.Z (no v prefix). Adopt the same?These steps mirror the user's existing convention but must be confirmed before use:
versionName and versionCode in app/build.gradle.kts.Release X.Y.Z with --signoff.X.Y.Z).Review code for quality, correctness, and security vulnerabilities. Use when the user asks to review code, audit for security issues, or check for bugs and anti-patterns.
Commit code changes and push via Git. Use when the user asks to commit, push, or save their work to the repository.
Writing/updating project documentation (README, PLAN, PRIVACY-POLICY, NOTICES, changelogs). Use when the user asks to update docs, write changelogs, or modify store listings.