nubecita: Skill for Claude Code

Dispatch the Promote to Production workflow (.github/workflows/promote.yaml) with the right inputs, surface the resolved target, then hand the gated approval back to the human.

What the workflow does (context): promotes an AAB already uploaded to the Play internal track to any combination of closed testing (alpha), open testing (beta), and production — no rebuild. The three tracks are chosen via boolean inputs (to_closed / to_open / to_production) and folded into a comma list. Two jobs: resolve (ungated, prints the target versionCode, the selected tracks, and all three changelogs to the run summary; fails fast if no track is selected) → promote (gated by the production environment's required-reviewer "Review deployments → Approve and deploy" button — one approval covers the whole batch). concurrency: promote-production serializes runs.

Per-track behavior handled by the lane: rollout % and update priority apply to production only; alpha/beta always go to 100% of testers with no priority, and a build already live on a testing track is skipped (no redundant re-promote). Only production re-runs to advance its staged rollout.

Input: optional hints from the user (which tracks, rollout %, priority, a specific versionCode). If absent, gather them interactively below.

Steps

1. Preflight. Confirm the tooling and that you're promoting the intended build:

   gh auth status >/dev/null && echo "gh: authed"
   gh workflow list | grep -i "Promote to Production" || echo "workflow missing"
   git rev-parse --abbrev-ref HEAD   # workflow_dispatch runs from main by default
   

   The promotion targets a Play versionCode (independent of the git branch), but the changelogs/fastlane come from the dispatched ref — so dispatch from main (the default) unless the user explicitly wants another ref. If they're on a feature branch, note that --ref main is used.

2. Gather the inputs (work together). First use the AskUserQuestion tool (multiSelect) to pick the target track(s), then ask the production-only knobs only if production is among the picks.

   • Tracks (multiSelect, at least one) — Closed testing (alpha) / Open testing (beta) / Production. Map the picks to the boolean inputs to_closed / to_open / to_production. Default suggestion: Production. (Testing tracks always go to 100% of testers, so they need no rollout/priority.)
   • rollout (ask only if Production is selected; default 0.1) — staged fraction. Options: 0.01 / 0.05 / 0.1 / 0.2 / 0.5 / 1.0. A fresh production promote starts low (e.g. 0.1); to advance an in-flight rollout, re-run with a higher fraction and the same versionCode. Ignored for alpha/beta.
   • in_app_update_priority (ask only if Production is selected; default 0) — options 0–5. 0 = default (no nudge); 1–3 = flexible in-app-update nudge; >=4 forces IMMEDIATE (blocking) update. Most releases use 0; reserve 4–5 for critical fixes. Not applied to testing tracks.
   • version_code (optional) — blank resolves to the latest build on the internal track. Only set it to promote/advance a specific older build.

3. Assemble + confirm the command. Show the exact command and get a yes before running — this publishes to real users / testers. Pass a boolean for each track (true/false); include rollout/in_app_update_priority only when Production is selected (they default otherwise):

   # include rollout / in_app_update_priority only when to_production=true (they default otherwise);
   # add -f version_code=<versionCode> only if a specific build was requested.
   gh workflow run "Promote to Production" --ref main \
     -f to_closed=<true|false> \
     -f to_open=<true|false> \
     -f to_production=<true|false> \
     -f rollout=<rollout> \
     -f in_app_update_priority=<priority>
   

   (gh workflow run promote.yaml … works too.)