agentsclimarketplace

Gplay cli usage

Skill unliftedq/agents/android-dev/skills/gplay-cli-usage

A collection of portable, domain-focused AI agents managed by kman.

Install
npx -y skills add unliftedq/agents --skill gplay-cli-usage

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.

What its author says it does

Copied from the file, not written here

The cross-cutting conventions every gplay command shares — credential/account resolution order, package targeting and `.gplay/` pinning, output formats (table/json/markdown), semantic exit codes, the `--dry-run`/`--confirm` safety gates, stdout-is-data/stderr-is-logs, and the Edit lifecycle (implicit per-command, or explicit `edits begin/commit/discard` transactions). Use when running or designing any gplay command, wiring gplay into CI, branching on its exit codes, introspecting the Android Publisher API surface offline with `gplay schema`, or building a more specific gplay workflow on top of these rules.

SKILL.md

9.6 KB, ~2.3k tokens by cl100k_base, as published. Nobody here has run it

gplay CLI conventions (foundation)

This is the foundation skill: the conventions that hold for every gplay command, factored out once so the workflow skills (gplay-release-flow, gplay-setup, gplay-apps, gplay-tracks, gplay-reviews, gplay-metadata-sync, gplay-compliance, gplay-team) can reference it instead of repeating them. The normative source of truth is docs/DESIGN.md in the CLI repo; this skill summarizes it for agents and does not freeze per-command flag lists.

--help is the source of truth

gplay's commands are self-describing. Confirm the current verbs, flags, and defaults from the binary, never from memory:

gplay --help                       # the whole command tree
gplay <group> --help               # a namespace (releases, tracks, team, …)
gplay <group> <command> --help     # one command, with its real flags
gplay exit-codes                   # the semantic exit-code table

If this skill and --help ever disagree, trust --help.

gplay schema — the offline API map

Where --help documents gplay's own surface, gplay schema introspects the underlying Android Publisher API offline (no credential, no HTTP call) from an index compiled into the binary — does a method exist, what does it send and return, what fields and enums does a type carry:

gplay schema --list                 # compact catalog: id · http · path
gplay schema tracks                 # match across method id, REST path, type name
gplay schema Track                  # expand a schema's fields, types, enums
gplay schema edits.tracks.update    # a method's request/response, one hop deep
gplay schema --method PATCH         # filter the method surface by HTTP verb

[experimental] (gplay v0.5.0) — confirm the surface with gplay schema --help.

Which credential / account (resolution order)

Every authenticated command resolves the service-account credential in this order, highest priority first:

  1. --service-account <path-or-inline-json> — a JSON file path or inline JSON content. Overrides everything below.
  2. --account <name> — a specific stored Account. Overrides env + the active Account.
  3. GPLAY_SERVICE_ACCOUNT env var — a path or inline JSON.
  4. The active stored Account (set up via gplay auth login).

Setting this up from scratch is the gplay-setup skill. Auth problems exit 10 (bad/again credential) or 11 (the service account is not invited on the app/account).

Which app (--package + project pinning)

Most commands need a target package. Resolution (ADR-0004):

  1. --package com.example.app on the command, else
  2. the package pinned in .gplay/config.json for the current repo.

Pin once with gplay init (or gplay apps init) so day-to-day commands need no --package. Managing the registry of packages is the gplay-apps skill.

Output: table on a TTY, JSON in a pipe

--output takes table, json, or markdown. The default is auto (ADR-0005): a human table on a terminal, JSON when piped or in CI. For machine consumption, ask for --output json explicitly — read commands pass the API payload through (ADR-0003), and write commands return the request/diff body, so a CI gate is usually one jq line. The pass-through promise is about not reshaping the API, not that every --output json is an API echo: the offline reference commands that wrap no API call — team permissions and schema — synthesize their own (gplay-owned, documented) JSON instead.

stdout is data, stderr is logs. Parse stdout; warnings, progress, and -v/--verbose flow steps go to stderr and never pollute the JSON. (Example: reviews list prints its "last 7 days only" warning to stderr.)

Exit codes — branch on the number, not the text

gplay exit-codes prints the full table. The semantic codes:

CodeMeaningRetry-safe
0Success
1Generic error (fallback)no
2CLI misuse (unknown flag/command, bad value, missing arg)no
3A named safety flag is missing (--confirm / --grant-admin) — re-run with ityes, with the flag
4Denied by environment policy (GPLAY_READONLY) — a mutating command was refusedno — change the environment
10Authentication failureno
11Authorization (403 — SA not invited)no
20Client-side validation (bad AAB, unknown locale, …)no
30API 4xx (not found, conflict, gone, …)no
40API 5xx (upstream unhealthy)yes
50Network (timeout, DNS, refused)yes
60State conflict (open edit, rate-limited, ambiguous target)sometimes

Agents should treat 3 as "append the named flag and re-run", 4 as "the environment forbids this write — do not retry, change the deployment", 40/50 as "back off and retry", and 2/10/11/20/30 as "fix the input, do not retry blindly".

Safety: --dry-run everywhere, --confirm for live writes

  • --dry-run is available on write commands: it validates inputs and prints the payload/diff it would send, with no HTTP call (and usually no auth needed). Reach for it before any production-affecting write.
  • --confirm gates the writes that reach real users or the live store — production releases, metadata apply, compliance datasafety set. Omitting it fails with exit 3 and names the flag. CI=true never auto-confirms.
  • --grant-admin is the stronger gate for conferring admin in gplay-team.
  • GPLAY_READONLY=1 (truthy = enforced) is the environment-level guard for agent deployments that must only read. Because the safety flags above are advisory — an agent holding the credential can pass them itself — set this in the environment and the kernel refuses every mutating command before credential resolution and before any network call, regardless of flags, while read commands and --dry-run previews keep working. Its refusal exits 4 (denied by environment policy) — which, unlike 3, is not resolvable by adding a flag; the only fix is to change the environment.

When a write refuses for a missing flag, the message names it — that refusal is agent-resolvable (ADR-0017): re-run with the flag it asked for. The GPLAY_READONLY refusal (exit 4) is the deliberate exception: it is not agent-resolvable.

The Edit lifecycle — implicit by default, explicit when you batch

Google Play mutations run inside a transactional Edit (edits.insert → change → edits.commit). gplay offers two ways to drive it.

Implicit (the default). Each write command performs the whole three-step dance on its own: it opens its own Edit, makes the change, and commits, discarding the Edit automatically on failure. You do not manage Edit IDs by hand. --keep-edit-on-failure skips that auto-discard for debugging.

Explicit (gplay edits …, when several changes must land together). To batch multiple writes into one atomic commit, open an Edit yourself:

gplay edits begin            # opens an Edit, pins its id to .gplay/edit-<package>.json
gplay metadata apply …       # these writes detect the pin and reuse the open Edit
gplay releases upload … --release-notes-dir ./notes
gplay edits status           # local read (no auth/network): shows the open edit, or none
gplay edits commit           # publish everything at once, and clear the pin
# gplay edits discard        # …or abandon the whole batch, clearing the pin

While the pin exists, subsequent write commands reuse the open Edit instead of opening their own, so the changes commit together or not at all. In explicit mode there is no auto-commit and no auto-discard — the lifecycle is yours until you commit or discard. Notes: a project (gplay init) is required since the pin lives under .gplay/; opening a second Edit while one is pinned is refused (exit 60); if commit fails (e.g. a validation error) the Edit stays open and the pin remains — fix and re-run, or discard.

(A few surfaces sit outside the Edit model on purpose — compliance datasafety, device-tiers, recovery, orders, vitals, games are direct writes/reads with no editId, so edits begin does not batch them; their skills call that out.)

Map of skills

SurfaceSkill
Auth onboardinggplay-setup
App registry + detailsgplay-apps
Releases (upload/promote/rollout)gplay-release-flow
Tracks + testersgplay-tracks
Reviewsgplay-reviews
Store listings + imagesgplay-metadata-sync
Data Safetygplay-compliance
Team users + grantsgplay-team
Managed Play private appsgplay-customapps
Post-launch vitals (crashes/ANRs)gplay-vitals
Orders (view/refund)gplay-orders
Play Games config (achievements/leaderboards)gplay-games
App recovery (bad-release remediation)gplay-recovery
Device tier configsgplay-device-tiers

What ships with it: 1 file

221 B alongside SKILL.md

Keep looking

Skills are one crate of 328,083. 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.