Check Android release readiness without publishing by default, including versionCode and versionName, signing and keystore boundaries, release build types, R8/ProGuard, mapping outputs, app bundles, APKs, Play delivery handoffs, privacy, permissions, changelogs, and repository-owned release automation routing through Gradle, CI, Fastlane, or Play Developer Publishing API clients.
Scanned 9/5/2026
Install to Claude Code
npx -y skills add gaelic-ghost/socket --skill release-readiness-workflow --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Release Readiness Workflow?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/gaelic-ghost-release-readiness-workflow)More formats (shields.io, HTML) on the badges page.
---
name: release-readiness-workflow
description: Check Android release readiness without publishing by default, including versionCode and versionName, signing and keystore boundaries, release build types, R8/ProGuard, mapping outputs, app bundles, APKs, Play delivery handoffs, privacy, permissions, changelogs, and repository-owned release automation routing through Gradle, CI, Fastlane, or Play Developer Publishing API clients.
license: Apache-2.0
compatibility: Designed for Codex and compatible Agent Skills clients working with Android release-preparation surfaces.
metadata:
owner: gaelic-ghost
repo: socket
category: android-release
allowed-tools: Read Bash(rg:*) Bash(git:*) Bash(./gradlew:*) Bash(gradle:*) Bash(gh:*)
---
# Android Release Readiness Workflow
## Purpose
Check whether an Android app or library is ready for release without starting a publish workflow by default.
The practical decision is which version, signing, packaging, policy, changelog, and automation surfaces must be verified before a human or repo-owned release system publishes artifacts.
## Source Check
Use repo-local Gradle files, release docs, CI workflows, Fastlane files, checked-out automation sources, and Dash.app docsets opportunistically for exact Gradle or Java questions. Use official documentation as authority for Android-specific release, signing, privacy, permissions, and Play behavior:
- [Prepare and roll out a release](https://developer.android.com/studio/publish)
- [Android App Bundles](https://developer.android.com/guide/app-bundle)
- [Sign your app](https://developer.android.com/studio/publish/app-signing)
- [Shrink, obfuscate, and optimize your app](https://developer.android.com/build/shrink-code)
- [Play Developer API](https://developers.google.com/android-publisher)
- [Fastlane supply documentation](https://docs.fastlane.tools/actions/supply/)
Translate documentation into concrete release files, commands, artifacts, and gates.
## Inspection Workflow
1. Identify release ownership:
- app module
- release build type
- product flavors
- version code and version name
- changelog or release notes
- CI release workflow
- Fastlane, Gradle Play Publisher, Play Developer Publishing API client, or custom scripts
2. Inspect signing boundaries:
- signing config names
- keystore references
- environment variable names
- secret-handling docs
- local placeholder configs
3. Inspect packaging:
- app bundle tasks
- APK tasks
- R8/ProGuard files
- mapping output expectations
- native debug symbols if present
4. Inspect policy-sensitive surfaces:
- permissions
- exported components
- privacy disclosures
- target SDK requirements
- Play delivery tracks and rollout docs
5. Route automation:
- identify the repo-owned release command or CI job
- explain required credentials or approvals
- stop before publish unless the user explicitly requested the publish action
## Command Selection
Prefer dry, local, or artifact-building checks first:
```bash
./gradlew :app:lintRelease
./gradlew :app:assembleRelease
./gradlew :app:bundleRelease
```
Use repository-documented release commands when they exist. Treat commands that upload, promote, submit for review, or publish as explicit approval-gated actions.
## Automation Routing
When a repository already owns release automation, report:
- automation owner: Gradle, CI, Fastlane, Play Developer Publishing API client, or custom script
- trigger: local command, CI workflow dispatch, tag, branch, or manual approval
- credentials: environment variable names or secret names, without printing secret values
- artifacts: AAB, APK, mapping file, native symbols, changelog, or release notes
- publish boundary: the exact command or click that would upload, promote, or release
## Output Shape
Return:
1. `Release surface`: app or library module, variant, flavor, and artifact type.
2. `Versioning`: version code, version name, changelog, and policy status.
3. `Signing`: signing config, secret boundary, and local-safe checks.
4. `Packaging`: AAB, APK, R8/ProGuard, mapping, and symbol outputs.
5. `Automation route`: Gradle, CI, Fastlane, Play API, custom script, or none found.
6. `Validation path`: commands run or recommended.
7. `Publish boundary`: what was deliberately not run without explicit approval.
## Guardrails
- Do not publish, upload, promote, submit for review, or change Play tracks by default.
- Do not print keystore passwords, service account keys, tokens, or signing secrets.
- Do not invent release automation when the repo has no release owner.
- Do not bump version code, version name, target SDK, or signing config without explaining the release impact.
- Do not remove R8/ProGuard rules or mapping outputs casually.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!