agentsclimarketplace
Sign in

Gplay recovery

Skill unliftedq/agents/android-dev/skills/gplay-recovery

Drive Google Play app recovery actions with gplay `recovery` — the incident-response remediation that force-updates users stuck on a bad release back to a safe version via a remote in-app update. `create` stages a harmless draft; `deploy` activates it (production-impacting); `cancel` stops it (irreversible); `add-targeting` widens the audience (append-only); `list` shows a versionCode's recoveries. Keyed by package + versionCode, outside the Edit model. Use when a shipped build is broken and you need to push affected users off it, or to inspect/steer an existing recovery.From its SKILL.md

Install
npx -y skills add unliftedq/agents --skill gplay-recovery

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

4.1 KB, 951 tokens by cl100k_base, as published. Nobody here has run it

gplay recovery (incident response for a bad release)

gplay recovery manages app recovery actions — Google's targeted incident-response remediation. When a shipped versionCode turns out to be bad, a recovery force-updates the impacted users to a safe version via a remote in-app update. Shared conventions (auth, output, exit codes, --dry-run/--confirm, --package pinning) are in gplay-cli-usage. The whole namespace is [experimental].

Two structural facts to hold onto:

  • Keyed by package + versionCode, and it lives outside the Edit model (no editId) — a recovery has its own appRecoveryId and a draft → active → canceled lifecycle.
  • --version-code is the bad version — the one users are stuck on that you want them off.

The lifecycle, in order

# 1. Stage a DRAFT (harmless — nothing is pushed yet, so no --confirm):
gplay recovery create --version-code 431 --all-users
gplay recovery create --version-code 431 --regions US,FR      # or scope it
gplay recovery create --version-code 431 --sdk-levels 30,31

# 2. Inspect the recoveries on that versionCode (find the appRecoveryId):
gplay recovery list --version-code 431

# 3. Activate — this force-updates impacted users. Production-impacting:
gplay recovery deploy <appRecoveryId> --confirm

# 4a. Widen the audience later (append-only — see below):
gplay recovery add-targeting <appRecoveryId> --regions DE,ES --confirm

# 4b. …or stop it (irreversible):
gplay recovery cancel <appRecoveryId> --confirm

create — a harmless draft

create stages a draft; nothing reaches a user until deploy. Because a draft is harmless it needs no --confirm (use --dry-run to validate inputs with no HTTP call). It requires --version-code and at least one audience selector: --all-users, --regions <CC,CC> (CLDR codes), or --sdk-levels <N,N>. The recovery type defaults to a remote in-app update (--remote-in-app-update, the only type Play models today).

deploy / cancel — the gated writes

  • deploy <id> activates the draft — the production-impacting step that force-pushes users off the bad build. Requires --confirm (missing → exit 3); rehearse with --dry-run.
  • cancel <id> stops the action: it persists with status CANCELED and cannot be resumed — this is irreversible. Requires --confirm. To target users again after a cancel you must create a new recovery.
  • GPLAY_READONLY refuses both (exit 4).

add-targeting is append-only — it can only widen

The audience of a recovery can be widened but never narrowed. add-targeting <id> adds users/regions/SDK levels (--all-users, --regions, --sdk-levels), requires --confirm, and is append-only at the API level. There is no "remove targeting". To shrink the blast radius, you must cancel the recovery and create a fresh one — plan the initial audience conservatively for exactly this reason.

list, and the missing view

recovery list --version-code <N> shows each recovery's id, status, and creation time (--version-code required — recoveries are keyed by version). There is no recovery view — the API exposes only list, so list is how you read a recovery's state and find its appRecoveryId. --output json passes ListAppRecoveriesResponse through verbatim.

Confirm the current verbs and flags with gplay recovery --help and gplay recovery <command> --help — the surface is [experimental] (ADR-0030) and may still evolve.

What ships with it: 1 file

221 B alongside SKILL.md

Gives 0 of the 12 instructions most ship operate skills give in 951 tokens

Counted across 779 of the 1,178 authors here whose files we hold, read 2026-08-07

  • Document a rollback plan before deploymentin 41 of 779, across 22 files
  • Update the changelogin 21 of 779, across 19 files
  • Run the test suitein 20 of 779
  • Create an annotated git tagin 20 of 779
  • Clean up feature flags after full rolloutin 18 of 779, across 10 files
  • Verify deployment health after launchin 18 of 779, across 10 files
  • Test both feature flag statesin 17 of 779, across 9 files
  • Verify the working tree is cleanin 17 of 779
  • Make database migrations backward-compatiblein 16 of 779, across 8 files
  • Set up error monitoring before launchin 15 of 779, across 7 files
  • Monitor metrics at each rollout stagein 14 of 779, across 5 files
  • Create a GitHub releasein 14 of 779

Said here and by no other author read

  • create a draft recovery using the bad version-code
  • include at least one audience selector when creating
  • list recoveries to find the app recovery id
  • confirm before deploying a recovery
  • confirm before widening targeting
  • cancel recovery to shrink the blast radius

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,144. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.