Gpc User Management

Name: Gpc User Management
Author: yasserstudio

yasserstudio/gpc-skills

25 installs
1 repo stars
Updated August 1, 2026
yasserstudio/gpc-skills

Helps with ai & agent building tasks.

About

gpc-user-management is a Claude Code skill for ai & agent building. It helps solo builders move faster with AI-assisted coding.

gpc-user-management
AI & Agent Building
AI-coding skill

Gpc User Management by the numbers

25 all-time installs (skills.sh)
Ranked #9,764 of 16,546 AI & Agent Building skills by installs in the Skillselion catalog
Data as of Aug 2, 2026 (Skillselion catalog sync)

npx skills add https://github.com/yasserstudio/gpc-skills --skill gpc-user-management

Add your badge

Show developers this skill is listed on Skillselion. Paste this into your README.

[![Listed on Skillselion](https://skillselion.com/badge/skills/yasserstudio/gpc-skills/gpc-user-management.svg)](https://skillselion.com/skills/yasserstudio/gpc-skills/gpc-user-management)

Installs	25
repo stars	★ 1
Last updated	August 1, 2026
Repository	yasserstudio/gpc-skills ↗

What it does

Helps with ai & agent building tasks.

Files

SKILL.mdMarkdownGitHub ↗

gpc-user-management

Manage developer account users, permissions, and testers with GPC.

When to use

Inviting or removing users from a Google Play developer account
Updating user permissions (developer-level or per-app)
Listing and auditing who has access to the developer account
Adding or removing testers from testing tracks (internal, alpha, beta)
Importing testers in bulk from a CSV file
Setting up Google Group-based tester access

Inputs required

Authenticated GPC — gpc auth status must show valid credentials
Developer account ID — required for user commands (--developer-id or GPC_DEVELOPER_ID)
App package name — required for tester commands and per-app grants (--app)
Email addresses — for inviting users or adding testers
CSV file — for bulk tester import (--file)

Procedure

0. Verify setup

gpc auth status
gpc config get app

User commands require --developer-id. Set it once:

export GPC_DEVELOPER_ID=1234567890

Or pass it per command: gpc users list --developer-id 1234567890.

1. Users — list and inspect

# List all users in the developer account
gpc users list --developer-id 1234567890

# Get details for a specific user
gpc users get user@example.com --developer-id 1234567890

# JSON output for scripting
gpc users list --developer-id 1234567890 --json

2. Users — invite

Invite a new user with developer-level permissions and optional per-app grants:

# Invite with developer-level permissions
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION VIEW_FINANCIAL_DATA \
  --developer-id 1234567890

# Invite with per-app grants
gpc users invite user@example.com \
  --grant "com.example.app:VIEW_APP_INFORMATION,MANAGE_TESTING" \
  --developer-id 1234567890

# Combine developer-level and per-app permissions
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES" \
  --developer-id 1234567890

# Preview first
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION \
  --developer-id 1234567890 \
  --dry-run

Read: references/permissions.md for the full list of developer-level and per-app permission constants.

Note: Permission changes may take up to 48 hours to propagate across Google's systems.

3. Users — update permissions

# Update developer-level permissions
gpc users update user@example.com \
  --role VIEW_APP_INFORMATION VIEW_FINANCIAL_DATA MANAGE_ORDERS \
  --developer-id 1234567890

# Update per-app grants
gpc users update user@example.com \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES,MANAGE_TESTING" \
  --developer-id 1234567890

# Preview changes
gpc users update user@example.com \
  --role VIEW_APP_INFORMATION \
  --developer-id 1234567890 \
  --dry-run

4. Users — remove

# Preview removal
gpc users remove user@example.com --developer-id 1234567890 --dry-run

# Remove
gpc users remove user@example.com --developer-id 1234567890

5. Testers — list

# List testers for a track
gpc testers list --track internal
gpc testers list --track alpha
gpc testers list --track beta

# JSON output
gpc testers list --track beta --json

6. Testers — add and remove

# Add individual testers (Google Group emails or individual emails)
gpc testers add tester1@gmail.com tester2@gmail.com --track internal

# Add a Google Group
gpc testers add testers-group@googlegroups.com --track beta

# Add testers without auto-submitting changes for review
gpc testers add tester1@gmail.com --track beta --changes-not-sent-for-review

# Fail if the app is currently in review or rejected before modifying testers
gpc testers add tester1@gmail.com --track beta --error-if-in-review

# Remove testers
gpc testers remove tester1@gmail.com --track internal

# Remove testers without auto-submitting changes for review
gpc testers remove tester1@gmail.com --track internal --changes-not-sent-for-review

# Preview changes
gpc testers add tester1@gmail.com --track beta --dry-run

7. Grants — standalone per-app permission management

gpc grants manages per-app permissions independently from user invitations. Use this when you need fine-grained control over what individual users can do on specific apps.

# List all grants for a user
gpc grants list user@example.com --developer-id 1234567890

# List grants for a specific app
gpc grants list user@example.com \
  --developer-id 1234567890 \
  --app com.example.app

# Create a new per-app grant
gpc grants create user@example.com \
  --app com.example.app \
  --permissions MANAGE_PRODUCTION_RELEASES VIEW_APP_INFORMATION \
  --developer-id 1234567890

# Update existing grant permissions
gpc grants patch user@example.com \
  --app com.example.app \
  --permissions VIEW_APP_INFORMATION \
  --developer-id 1234567890

# Remove a per-app grant (revokes app-specific access)
gpc grants delete user@example.com \
  --app com.example.app \
  --developer-id 1234567890

When to use `gpc grants` vs `gpc users update --grant`:

Use gpc grants for managing grants on existing users without modifying their developer-level role
Use gpc users invite --grant or gpc users update --grant when also changing the user's account-level permissions

Read: references/permissions.md for the full list of per-app permission constants.

8. Testers — bulk import from CSV

Import testers from a CSV file containing email addresses:

# Preview import
gpc testers import --track beta --file testers.csv --dry-run

# Import
gpc testers import --track beta --file testers.csv

CSV format — one email per line:

email
tester1@gmail.com
tester2@gmail.com
qa-team@googlegroups.com

Read: references/tester-workflows.md for common tester management patterns and Google Group best practices.

Verification

gpc users list --developer-id <id> returns current users with their permissions
gpc users get <email> --developer-id <id> shows the user's current role and grants
gpc testers list --track <track> returns testers for the specified track
All --dry-run commands show what would change without modifying data
JSON output works on all commands (--json flag)
Permission changes may take up to 48 hours to propagate

Failure modes / debugging

Symptom	Likely Cause	Fix
`DEVELOPER_ID_REQUIRED`	Missing `--developer-id` flag	Set `GPC_DEVELOPER_ID` env var or pass `--developer-id`
`PERMISSION_DENIED` on user commands	Service account lacks admin permissions	Service account needs "Admin" access in Play Console
`USER_NOT_FOUND`	Email not in the developer account	Check spelling; use `gpc users list` to verify
`INVALID_GRANT` format	Wrong `--grant` syntax	Format: `com.example.app:PERM1,PERM2` (colon between app and perms, commas between perms)
`INVALID_PERMISSION`	Unknown permission constant	Check `references/permissions.md` for valid constants
Permissions not taking effect	48-hour propagation delay	Wait; changes are eventual — verify after 48 hours
`TRACK_NOT_FOUND` for testers	Track doesn't exist or wrong name	Valid tracks: `internal`, `alpha`, `beta`, or custom track names
CSV import fails	Wrong CSV format or encoding	Ensure UTF-8, one email per line, header row with `email`
`TESTER_LIMIT_EXCEEDED`	Track has maximum tester count	Internal: 100, Alpha/Beta: no hard limit but Google Groups recommended for scale

Related skills

gpc-setup — authentication and developer account configuration
gpc-release-flow — releasing to testing tracks that testers access
gpc-ci-integration — automating tester management in CI/CD pipelines

{
  "skill_name": "gpc-user-management",
  "evals": [
    {
      "id": 1,
      "prompt": "We just hired a new QA engineer (qa@example.com) and need to give them access to our Play Console. They should be able to view app info and manage testing for all apps, plus manage production releases only for com.widgetco.app. They also need to be an internal tester. Our developer account ID is 9876543210.",
      "expected_output": "Shows how to invite with mixed developer-level and per-app permissions, then add as tester",
      "files": [],
      "expectations": [
        "Uses gpc users invite qa@example.com with --role VIEW_APP_INFORMATION MANAGE_TESTING",
        "Uses --grant com.widgetco.app:MANAGE_PRODUCTION_RELEASES for per-app permission",
        "Includes --developer-id 9876543210",
        "Shows gpc testers add qa@example.com --track internal",
        "Mentions the 48-hour propagation delay for permissions"
      ]
    },
    {
      "id": 2,
      "prompt": "We need to set up our beta testing program. We have a Google Group (beta@googlegroups.com) with about 200 members, plus a CSV file with 50 additional individual testers. How should we organize this?",
      "expected_output": "Shows how to add Google Group and import CSV testers to beta track",
      "files": [],
      "expectations": [
        "Shows gpc testers add beta@googlegroups.com --track beta",
        "Shows gpc testers import --track beta --file testers.csv",
        "Mentions --dry-run for previewing before applying",
        "Describes the CSV format (header row with email, one per line)",
        "Recommends Google Groups for scale over individual emails"
      ]
    },
    {
      "id": 3,
      "prompt": "An employee left the company last week. I need to fully remove their access — they were dev@example.com in our developer account (ID 1111111111) and also a tester on internal and beta tracks. Can you walk me through the offboarding?",
      "expected_output": "Shows complete offboarding: remove from testing tracks, then remove from developer account",
      "files": [],
      "expectations": [
        "Shows gpc testers remove dev@example.com --track internal",
        "Shows gpc testers remove dev@example.com --track beta",
        "Shows gpc users remove dev@example.com --developer-id 1111111111",
        "Suggests using --dry-run before the actual removal",
        "Recommends verifying removal with gpc users list or gpc testers list"
      ]
    }
  ]
}

Google Play Permission Constants

Reference for permission values used with gpc users invite and gpc users update.

Developer-level permissions (`--role`)

These apply across all apps in the developer account.

Permission	Description
`VIEW_APP_INFORMATION`	View app info, listings, and stats
`VIEW_FINANCIAL_DATA`	View financial reports, revenue, pricing
`MANAGE_ORDERS`	View and refund orders
`MANAGE_STORE_PRESENCE`	Edit store listings, graphics, descriptions
`MANAGE_PRODUCTION_RELEASES`	Create and manage production releases
`MANAGE_TESTING`	Manage testing tracks and testers
`MANAGE_POLICY_ISSUES`	View and respond to policy violations
`MANAGE_DEEP_LINKS`	Configure deep links and app links

Per-app permissions (`--grant`)

These are scoped to a specific app. Format: com.example.app:PERM1,PERM2.

Per-app grants use the same permission constants as developer-level roles, but apply only to the specified app.

Examples

# Developer-level: can view all apps' info
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION \
  --developer-id 1234567890

# Per-app: can manage releases only for com.example.app
gpc users invite user@example.com \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES,MANAGE_TESTING" \
  --developer-id 1234567890

# Mixed: view all apps, manage releases for one app
gpc users invite user@example.com \
  --role VIEW_APP_INFORMATION \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES" \
  --developer-id 1234567890

Multiple app grants

# Grant different permissions for different apps
gpc users invite user@example.com \
  --grant "com.example.app1:MANAGE_PRODUCTION_RELEASES" \
  --grant "com.example.app2:VIEW_APP_INFORMATION,MANAGE_TESTING" \
  --developer-id 1234567890

Common role patterns

Read-only reviewer

gpc users invite reviewer@example.com \
  --role VIEW_APP_INFORMATION \
  --developer-id 1234567890

Finance team

gpc users invite finance@example.com \
  --role VIEW_APP_INFORMATION VIEW_FINANCIAL_DATA MANAGE_ORDERS \
  --developer-id 1234567890

QA / Release engineer

gpc users invite qa@example.com \
  --role VIEW_APP_INFORMATION MANAGE_TESTING \
  --grant "com.example.app:MANAGE_PRODUCTION_RELEASES" \
  --developer-id 1234567890

Full app manager (single app)

gpc users invite manager@example.com \
  --grant "com.example.app:VIEW_APP_INFORMATION,VIEW_FINANCIAL_DATA,MANAGE_ORDERS,MANAGE_STORE_PRESENCE,MANAGE_PRODUCTION_RELEASES,MANAGE_TESTING" \
  --developer-id 1234567890

Propagation delay

Permission changes may take up to 48 hours to propagate across Google's systems. During this time:

The user's access may be inconsistent
API calls made by the user's credentials may intermittently fail
gpc users get will show the new permissions immediately, but enforcement is delayed

Service account requirements

To manage users, your service account needs Admin access in the Google Play Console. This is a developer account-level setting, not a per-app grant.

Tester Workflows

Common patterns for managing testers with GPC.

Track types

Track	Max testers	Use case
`internal`	100	Core team, QA — fastest approval, no review
`alpha`	No hard limit	Extended team, dogfooding
`beta`	No hard limit	External beta users, public testing

Adding individual testers

# Add to internal testing
gpc testers add dev1@gmail.com dev2@gmail.com --track internal

# Add to beta
gpc testers add beta-user@gmail.com --track beta

# Add without auto-submitting changes for review
gpc testers add beta-user@gmail.com --track beta --changes-not-sent-for-review

# Abort if the app is currently in review or rejected
gpc testers add beta-user@gmail.com --track beta --error-if-in-review

Using Google Groups

For large tester pools, use Google Groups instead of individual emails:

# Add a Google Group to beta
gpc testers add beta-testers@googlegroups.com --track beta

Benefits of Google Groups:

Manage membership in Google Workspace — no GPC/API calls needed
No per-track tester limits
Self-service join/leave via group settings
One API call to add/remove the group vs. N calls for individuals

Bulk import from CSV

# Create CSV file
cat > testers.csv << 'EOF'
email
tester1@gmail.com
tester2@gmail.com
tester3@gmail.com
qa-group@googlegroups.com
EOF

# Preview import
gpc testers import --track beta --file testers.csv --dry-run

# Import
gpc testers import --track beta --file testers.csv

CSV requirements

UTF-8 encoding
Header row with email column
One email per row
Supports individual emails and Google Group addresses

Audit current testers

# List testers per track
gpc testers list --track internal --json
gpc testers list --track alpha --json
gpc testers list --track beta --json

Remove testers

# Remove specific testers
gpc testers remove old-tester@gmail.com --track beta

# Remove multiple
gpc testers remove user1@gmail.com user2@gmail.com --track internal

# Remove without auto-submitting changes for review
gpc testers remove old-tester@gmail.com --track beta --changes-not-sent-for-review

Onboarding workflow

Typical team onboarding sequence:

# 1. Invite user to developer account with permissions
gpc users invite newdev@example.com \
  --role VIEW_APP_INFORMATION MANAGE_TESTING \
  --developer-id 1234567890

# 2. Add them as internal tester
gpc testers add newdev@gmail.com --track internal

# 3. Verify
gpc users get newdev@example.com --developer-id 1234567890
gpc testers list --track internal

Offboarding workflow

# 1. Remove from testing tracks
gpc testers remove olddev@gmail.com --track internal
gpc testers remove olddev@gmail.com --track beta

# 2. Remove from developer account
gpc users remove olddev@example.com --developer-id 1234567890

CI/CD automation

Automate tester management in your pipeline:

# GitHub Actions example — sync testers on PR merge
- name: Sync beta testers
  env:
    GPC_SERVICE_ACCOUNT: ${{ secrets.PLAY_SA_KEY }}
    GPC_APP: com.example.app
  run: |
    npx @gpc-cli/cli testers import --track beta --file testers.csv --dry-run
    npx @gpc-cli/cli testers import --track beta --file testers.csv

Keep testers.csv in your repo — PR reviews for tester changes, git history for audit trail.

#!/usr/bin/env node

/**
 * Detection script for GPC CLI.
 * Returns JSON with installation status, version, auth state, and config.
 * Used by Claude Code skill system for deterministic environment detection.
 *
 * Exit codes:
 *   0 — GPC detected (may or may not be authenticated)
 *   1 — GPC not found
 */

import { execSync } from "node:child_process";
import { existsSync } from "node:fs";
import { join } from "node:path";

function run(cmd) {
  try {
    return execSync(cmd, { encoding: "utf-8", timeout: 10000 }).trim();
  } catch {
    return null;
  }
}

const result = {
  installed: false,
  version: null,
  installMethod: null,
  authStatus: null,
  authMethod: null,
  profile: null,
  envAuth: false,
  defaultApp: null,
  configFile: null,
  nodeVersion: process.version,
};

// Check if gpc is installed globally
const versionOutput = run("gpc --version");
if (!versionOutput) {
  // Try npx
  const npxVersion = run("npx gpc --version 2>/dev/null");
  if (!npxVersion) {
    console.log(JSON.stringify(result, null, 2));
    process.exit(1);
  }
  result.version = npxVersion;
  result.installed = true;
  result.installMethod = "npx";
} else {
  result.version = versionOutput;
  result.installed = true;
  result.installMethod = "global";
}

// Check auth status
const authOutput = run("gpc auth status --json 2>/dev/null");
if (authOutput) {
  try {
    const auth = JSON.parse(authOutput);
    result.authStatus = auth.status || "unknown";
    result.authMethod = auth.method || null;
    result.profile = auth.profile || null;
  } catch {
    result.authStatus = "parse_error";
  }
}

// Check for env-based auth
if (process.env.GPC_SERVICE_ACCOUNT) {
  result.envAuth = true;
}

// Check default app
const configOutput = run("gpc config get app --json 2>/dev/null");
if (configOutput) {
  try {
    const config = JSON.parse(configOutput);
    result.defaultApp = config.value || config.app || null;
  } catch {
    result.defaultApp = configOutput || null;
  }
}

// Check for .gpcrc.json in current directory
const rcPath = join(process.cwd(), ".gpcrc.json");
if (existsSync(rcPath)) {
  result.configFile = rcPath;
}

console.log(JSON.stringify(result, null, 2));
process.exit(0);