eric-cerio/android-workflow
Eplayment Android development workflow for Copilot: plan, branch, lint, version, test, security gate, commit and push, distribution note. Every stage runs on its own, or as one chain with /ticket and /bugfix.
Create or pick the right git branch for an Android ticket - reusing the current branch, stacking on an epic branch, or cutting a new feature or bugfix branch from the base branch. Use when the user asks which branch to work on or to start a branch for a ticket, or as stage 03 of the Android workflow.
Commit and push the current Android ticket's work after showing the exact commit message, file list and push target, then offer the draft pull request. Use when the user asks to commit and push their ticket, or as stage 09 of the Android workflow. Requires a passing security gate for the current changes.
Implement an approved Android plan - scaffolding a feature through ViewModel, UseCase, Repository and Api with routes and DI, or making the smallest correct fix for a bug. Use when the user asks to implement a planned ticket or write the code for a fix, or as stage 04 of the Android workflow.
Produce the copy-pasteable Android test-distribution note for a build (the [FOR QA TESTING][Android][version][APP] block followed by the Jira links). Use when the user asks for the distribution note, the tester announcement, the QA note, or after a build has been pushed for testing. Stage 10 of the Android workflow.
Format and lint the Kotlin changes on this branch with ktlint, Android lint, and the code-sanitation checklist, on changed files only. Use when the user asks to lint, format, clean up or sanitise their Android changes, or as stage 05 of the Android workflow.
Set up an Android repository for the Copilot Android workflow by detecting its build, versioning, release-notes and distribution conventions and writing .ai/project/android-workflow.yml. Use when a repo has no workflow config, when another workflow skill says to run onboarding, or when adopting the workflow in a new Android project.
Plan an Android feature or bugfix before any code is written - collect the ticket details, find what to reuse, detect the architecture pattern and git state, then present the plan for approval. Use when the user wants to plan a ticket or a fix, investigate what a change would touch, or as stages 01-02 of the Android workflow.
Update the Android release notes and versionName for the current ticket, and register the branch for distribution if the repo needs it. Use when the user asks to bump the version, add the ticket to release notes, or prepare a branch for distribution, or as stage 06 of the Android workflow.
Run the four-layer Android security review on the current changes - guarded files, a diff scan for secrets and personal data and permission or dependency changes, a hardening audit, and a security review - and block the push on high-severity findings. Use when the user asks to check security, review a diff for vulnerabilities, or before pushing, or as stage 08 of the Android workflow.
Run the finishing half of the Android workflow on the current branch - lint, release notes and version, tests, the security gate, commit and push, then the distribution note. Use when the user has written code by hand and wants it shipped, or as stages 05-10 of the Android workflow.
Run or write Android JVM unit tests for a feature, package, class, or the current changes, using the repo's Gradle test task and the right JDK. Use when the user asks to run tests, test a feature, check whether tests pass, or add unit tests, or as stage 07 of the Android workflow.
Run the full Android bugfix workflow for a defect - intake and diagnosis, branch, optional implementation of the fix, then lint, version, tests, security gate, commit and push, and the distribution note. Use when the user reports a bug to fix, gives a Jira key for a defect, or types /bugfix.
Run the full Android feature workflow for a Jira ticket - intake and plan, branch, optional implementation, then lint, version, tests, security gate, commit and push, and the distribution note. Use when the user gives a Jira key to work on, says they want to start a ticket or a feature, or types /ticket.