skillZs
★ LIVE SKILL TAGS ★
>>> LIVE SKILLS INDEX <<<
* OPEN SOURCE *
NO LOGIN, NO TRACKING
※ REAL INSTALL DATA ※
← back to all skills
tamtom/gplay-cli-skills327 installs

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.

How do I install this agent skill?

npx skills add https://github.com/tamtom/gplay-cli-skills --skill gplay-testers-orchestration
view source ↗

Is this agent skill safe to install?

  • Gen Agent Trust Hubpass

    The skill provides instructions for managing Google Play app testers using the 'gplay' command-line tool. It includes methods for listing, adding, and removing testers via email or Google Groups. The analysis identified a standard surface for indirect prompt injection when processing tool output, but no malicious behavior was detected.

  • Socketpass

    No alerts

  • Snykpass

    Risk: LOW · No issues

  • Runlayerwarn

    1/1 file flagged

What does this agent skill do?

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

TrackTypeMax testersReviewAccess
internalInternal100NoInstant
alphaClosed testingUnlimitedNoMinutes
betaOpen or closed testingUnlimitedNo/YesMinutes
custom trackClosed testingUnlimitedNoMinutes
productionPublicUnlimitedYesDays

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 update — replace the entire tester set (emails/groups not included are removed).
  • gplay testers patch — merge 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 "tester1@example.com,tester2@example.com"

By Google Group instead of individual emails:

gplay testers update \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --google-groups "beta-testers@example.com,qa-team@example.com"

Add testers without dropping existing ones (patch)

gplay testers patch \
  --package com.example.app \
  --edit $EDIT_ID \
  --track alpha \
  --emails "newtester@example.com"

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 "user@example.com" | 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 "tester1@example.com,tester2@example.com"

# 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 "qa1@example.com,qa2@example.com"

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.

Add the canonical catalog link to the repository README so users can inspect current installs and available audits. The publishing guide covers the complete discovery path.

<a href="https://skillzs.dev/skills/tamtom/gplay-cli-skills/gplay-testers-orchestration">View gplay-testers-orchestration on skillZs</a>