skills/build-release/SKILL.md
Bump iOS/Android build numbers, build the Android .aab bundle, commit and push. Use this skill whenever the user says 'build release', 'bump build', 'build aab', 'bump and push', 'bump ios build number', 'build the aab file', or any combination of bumping build numbers, building Android bundles, and pushing. Also trigger when user says 'release build' or 'ship the build'.
npx skillsauth add kitfunso/omniskill build-releaseInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Automates the full release build workflow for the Phzse app: bump build numbers, build web assets, build the Android .aab, commit everything, and push.
C:/Users/skf_s/phzse project directoryExecute these steps in order. Stop and report if any step fails.
cd "C:/Users/skf_s/phzse" && git branch
Confirm you're on master. If not, warn the user before proceeding.
Read these two files to find the current build number:
codemagic.yaml — find the line agvtool new-version -all N and extract Nandroid/app/build.gradle — find the line versionCode N and extract NversionName from build.gradle (e.g., "2.1.0") for the .aab filenameBoth should be the same number. The new build number = current + 1.
Edit both files, replacing the old number with the new one:
codemagic.yaml: agvtool new-version -all {NEW}android/app/build.gradle: versionCode {NEW}cd "C:/Users/skf_s/phzse" && npm run build
Wait for completion. This must succeed before proceeding.
cd "C:/Users/skf_s/phzse" && npx cap sync android
cd "C:/Users/skf_s/phzse/android" && ./gradlew bundleRelease
This takes 30-60 seconds. Must finish with BUILD SUCCESSFUL.
cp "C:/Users/skf_s/phzse/android/app/build/outputs/bundle/release/app-release.aab" \
"C:/Users/skf_s/phzse/app-release-v{VERSION_NAME}-build{NEW_BUILD}.aab"
The .aab is gitignored, so it won't be committed — it's just for local reference / Play Store upload.
Stage all modified files (not untracked directories like .gstack/ or prototypes/):
git add codemagic.yaml android/app/build.gradle
Also stage any OTHER unstaged modified files from the current session (check git status first). Do NOT stage untracked directories unless they're clearly part of the work.
Commit with:
chore: bump build {NEW_BUILD} and release .aab
Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
Then push:
git push
Tell the user:
app-release-v{VERSION}-build{NEW}.aabdevelopment
Weekly engineering retrospective. Analyzes commit history, work patterns, and code quality metrics with persistent history and trend tracking. Team-aware: breaks down per-person contributions with praise and growth areas. Use when asked to "weekly retro", "what did we ship", or "engineering retrospective". Proactively suggest at the end of a work week or sprint.
development
Systematically QA test a web application and fix bugs found. Runs QA testing, then iteratively fixes bugs in source code, committing each fix atomically and re-verifying. Use when asked to "qa", "QA", "test this site", "find bugs", "test and fix", or "fix what's broken". Proactively suggest when the user says a feature is ready for testing or asks "does this work?". Three tiers: Quick (critical/high only), Standard (+ medium), Exhaustive (+ cosmetic). Produces before/after health scores, fix evidence, and a ship-readiness summary. For report-only mode, use /qa-only.
development
Report-only QA testing. Systematically tests a web application and produces a structured report with health score, screenshots, and repro steps — but never fixes anything. Use when asked to "just report bugs", "qa report only", or "test but don't fix". For the full test-fix-verify loop, use /qa instead. Proactively suggest when the user wants a bug report without any code changes.
testing
Eng manager-mode plan review. Lock in the execution plan — architecture, data flow, diagrams, edge cases, test coverage, performance. Walks through issues interactively with opinionated recommendations. Use when asked to "review the architecture", "engineering review", or "lock in the plan". Proactively suggest when the user has a plan or design doc and is about to start coding — to catch architecture issues before implementation.