Skip to content

Your first 5 commands after gplay setup --auto

You just ran:

Terminal window
brew install tamtom/tap/gplay
gplay setup --auto

--auto installed gcloud if missing, enabled the Google Play Android Publisher API in a fresh GCP project, created a service account, downloaded its key, and (assuming you accepted its Play Console invite) hooked it into your developer account.

Now what? Here are the five commands to run before you do anything else. Together they prove auth works, show you your app’s current state, and set you up to automate the rest.

1. gplay auth doctor — sanity-check the setup

Section titled “1. gplay auth doctor — sanity-check the setup”
Terminal window
gplay auth doctor

Runs every check that could bite you later:

  • Does the service-account JSON parse?
  • Does its email have Play Console developer access?
  • Does the linked GCP project have the Android Publisher API enabled?
  • Do all the requested scopes work with the current key?

If everything’s green, you’re wired up. If not, --fix --confirm tries to auto-remediate:

Terminal window
gplay auth doctor --fix --confirm

2. gplay apps list — see what you can touch

Section titled “2. gplay apps list — see what you can touch”
Terminal window
gplay apps list --output table

Every app the service account has access to. If you expected an app to show up and it doesn’t, the service account isn’t invited to it yet — do that in Play Console → Users and Permissions.

For scripting, drop --output table — the JSON is what agents want.

3. gplay tracks list — where does each app live?

Section titled “3. gplay tracks list — where does each app live?”

Pick the app you’re focused on:

Terminal window
gplay tracks list --package com.example.app --output table

Shows every track (internal, alpha, beta, production, custom closed-testing) with the version code and rollout fraction currently live in each.

This is the map you’ll return to every time you’re about to promote or roll back.

4. gplay listings list — what does the store look like right now?

Section titled “4. gplay listings list — what does the store look like right now?”
Terminal window
gplay listings list --package com.example.app --output table

Every localized store listing — title, short description, full description length, whether screenshots and graphics are set. If your app supports 10 locales, all 10 rows are here.

To fetch a single locale’s full text:

Terminal window
gplay listings get --package com.example.app --locale en-US

5. gplay vitals crashes query — how healthy is the app?

Section titled “5. gplay vitals crashes query — how healthy is the app?”
Terminal window
gplay vitals crashes query \
--package com.example.app \
--time-range LAST_7_DAYS \
--output table

Top crash clusters over the last 7 days. If you were about to promote a release, this tells you whether the current production build is healthy enough to build on.

Pair it with:

Terminal window
gplay vitals performance startup \
--package com.example.app \
--time-range LAST_7_DAYS

For startup latency baseline.

Once you know your way around, these two flags change everything:

--dry-run — every write command intercepts the HTTP request and logs it to stderr without executing. Safe preview:

Terminal window
gplay listings update --dry-run \
--package com.example.app \
--locale en-US \
--short-description "New tagline"

--paginate — every list command auto-fetches all pages:

Terminal window
gplay reviews list --package com.example.app --paginate

Together they cover 90% of what you’ll do.

Now that auth works and you know your app’s shape, install the Agent Skills:

Terminal window
npx skills add tamtom/gplay-cli-skills

Then in Claude Code (or any of the 12 supported agents):

What can you tell me about com.example.app? Summarize current tracks, active locales, top crashes, and any subscriptions.

The agent chains the five commands above (plus gplay subscriptions list) and gives you a one-paragraph brief. First-day productivity.

Depending on why you installed gplay:

Full command reference at /reference/.