tamtom/gplay-cli-skills

gplay-testers-orchestration

Manage testers for Google Play testing tracks (internal, closed alpha/beta, custom) using edit sessions. Use when assigning testers, creating closed tracks, or promoting builds between tracks.

First seen Feb 5, 2026

Installation

$ npx skills add tamtom/gplay-cli-skills --skill gplay-testers-orchestration

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from tamtom/gplay-cli-skills · top by installs.

npx skills add tamtom/gplay-cli-skills

Browse all from tamtom/gplay-cli-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 45
License LICENSE
Default branch main
Open issues 0
Status Active

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 4,945 B
  • docs SUMMARY.md 227 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 296 installs

SKILL.md

Testers Orchestration for Google Play

Use this skill to assign testers to a track and promote builds through the testing funnel. All tester changes happen inside an edit session and take effect only after gplay edits commit.

Testing tracks

Track Type Max testers Review Access
internal Internal 100 No Instant
alpha Closed testing Unlimited No Minutes
beta Open or closed testing Unlimited No/Yes Minutes
custom track Closed testing Unlimited No Minutes
production Public Unlimited Yes Days

alpha is a closed track (invite-only), not public. Testers on internal and closed tracks are managed by email address or by Google Group.

Tester commands

gplay testers has only three subcommands. There is no testers list — to list the testers on a track, use testers get.

  • gplay testers get — read the testers on a track.
  • gplay testers updatereplace the entire tester set (emails/groups not

included are removed).

  • gplay testers patchmerge with the existing set (preserves fields you

omit).

List (get) testers for a track

gplay testers get \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha

Assign testers (replace the whole set)

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "[email protected],[email protected]"

By Google Group instead of individual emails:

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --google-groups "[email protected],[email protected]"

Add testers without dropping existing ones (patch)

gplay testers patch \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "[email protected]"

Remove a tester (update = replace with the reduced set)

update replaces the resource, so re-send only the testers you want to keep:

CURRENT=$(gplay testers get --package com.example.app --edit $EDIT_ID --track alpha \
  | jq -r '.testers[]?')
KEEP=$(echo "$CURRENT" | grep -v "[email protected]" | paste -sd "," -)

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "$KEEP"

Assign testers inside an edit session (canonical flow)

Tester assignment is not a flag on gplay release. There is no --testers flag anywhere. The real flow is an edit session:

# 1. Create an edit
EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')

# 2. Upload the build
gplay bundles upload \
  --package com.example.app \
  --edit $EDIT_ID \
  --file app-release.aab

# 3. Assign the release to the track
gplay tracks update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --releases '[{"versionCodes":["123"],"status":"completed"}]'

# 4. Assign testers to the track
gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "[email protected],[email protected]"

# 5. Commit (nothing applies until this succeeds)
gplay edits commit --package com.example.app --edit $EDIT_ID

Create a closed testing track

Custom closed tracks are created inside an edit, then get testers assigned the same way:

EDIT_ID=$(gplay edits create --package com.example.app | jq -r '.id')

gplay tracks create \
  --package com.example.app \
  --edit $EDIT_ID \
  --track qa-ring

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track qa-ring \
  --emails "[email protected],[email protected]"

gplay edits commit --package com.example.app --edit $EDIT_ID

Promote a build between tracks

Promotion copies the source track's version codes to a destination track. --rollout is a fraction (0.0–1.0), not a percentage:

# Internal -> closed alpha
gplay promote --package com.example.app --from internal --to alpha

# Closed beta -> production at 10% staged rollout
gplay promote --package com.example.app --from beta --to production --rollout 0.1

Agent behavior

  • There is no testers list subcommand; use gplay testers get --track <track> to read a track's testers.
  • Never pass --testers to gplay release; assign testers via `testers

update/patch` inside an edit, then commit.

  • Use update to set the exact tester set, patch to add without removing.
  • --rollout values are fractions (0.1 = 10%), range 0.0–1.0.
  • Always gplay edits commit — tester changes are inert until committed.
  • Confirm flags with --help before running.