/chrome-webstore-release-blueprint

name: chrome-webstore-release-blueprint
description: Guide a user end-to-end through setting up Chrome Web Store API release automation in any repository. Use when asked to walk someone through OAuth/CWS credential setup, refresh token creation, local/CI secret setup, version-based publish automation, and submission status checks.

Chrome Web Store Release Blueprint

Use this skill as a hands-on setup guide. The agent should lead the user step-by-step, ask for confirmations, and only automate the parts that can be done locally/in CI.

What This Skill Is For

• Helping a user set up Chrome Web Store release automation from scratch.
• Giving clear manual instructions for Google/CWS dashboard steps.
• Implementing repo-side scripts/workflows after the user provides credentials.
• Verifying submission state (`PUBLISHED`, `PENDING_REVIEW`, etc.).

Agent Behavior Rules

• Treat dashboard/OAuth tasks as user-driven; do not imply you performed them.
• Give one clear step at a time and wait for confirmation before moving on.
• Ask for exact values only when needed, and tell user where each value comes from.
• Mask secrets in logs and never commit secret values to git.
• If `gh` is available, offer secret upload automation; if not, provide manual fallback.

Step 1: Project Discovery (Before Any Credential Work)

Collect these inputs:

• manifest path containing extension version
• build command
• zip/package command and output file name/path
• CI platform (GitHub Actions by default)
• release branch policy (`main`, tags, or manual dispatch)
• local secret file convention (`.env`, `.env.local`, etc.)

Ask explicitly:

• "Do you want CI to publish only when version changes?"
• "Do you want me to wire GitHub secret upload via `gh`?"

Step 2: Detailed Credential Walkthrough (User + Agent)

2.1 Enable API in Google Cloud

Tell user to open:

• `https://console.cloud.google.com/apis/library/chromewebstore.googleapis.com`

User actions: 1. Select the intended Google Cloud project. 2. Click `Enable` for Chrome Web Store API.

Agent prompt example:

• "When Chrome Web Store API shows as Enabled, tell me and I will move to OAuth setup."

2.2 Configure OAuth Consent Screen

Tell user to open one of:

• `https://console.cloud.google.com/apis/credentials/consent`
• If UI redirects, continue in Google Auth Platform consent screen pages.

User actions: 1. Choose `External` user type (for non-Workspace internal apps). 2. Fill app name, support email, developer contact email. 3. Save and continue through scopes unless custom scopes are required. 4. Add your own Google account as a test user if app is in Testing mode. 5. Save.

Agent guidance:

• If user wants stable long-lived refresh token behavior, recommend moving consent screen to Production when ready.

2.3 Create OAuth Client

Tell user to open:

• `https://console.cloud.google.com/apis/credentials`

User actions: 1. Click `Create Credentials` -> `OAuth client ID`. 2. Choose application type `Web application`. 3. Add authorized redirect URI exactly:

• `https://developers.google.com/oauthplayground`

4. Create client.

Capture values:

• `CWS_CLIENT_ID`
• `CWS_CLIENT_SECRET`

Agent prompt example:

• "Paste `CWS_CLIENT_ID` and `CWS_CLIENT_SECRET` when ready (I will treat them as secrets)."

2.4 Generate Refresh Token (OAuth Playground)

Tell user to open:

• `https://developers.google.com/oauthplayground/`

User actions: 1. Click the settings gear icon. 2. Enable `Use your own OAuth credentials`. 3. Paste `CWS_CLIENT_ID` and `CWS_CLIENT_SECRET`. 4. In Step 1, enter scope:

• `https://www.googleapis.com/auth/chromewebstore`

5. Click `Authorize APIs`. 6. Sign in with the same Google account that owns/publishes the extension. 7. Click `Exchange authorization code for tokens`. 8. Copy refresh token.

Capture value:

• `CWS_REFRESH_TOKEN`

Agent prompt example:

• "Paste `CWS_REFRESH_TOKEN` now. I will only place it in local secret storage/CI secrets."

2.5 Capture Store IDs

Capture:

• `CWS_EXTENSION_ID` (the extension item ID from store/developer listing URL)
• `CWS_PUBLISHER_ID` (developer/publisher ID from Chrome Web Store developer account context)

Agent instruction:

• If user is unsure, ask them to open the Chrome Web Store Developer Dashboard and copy IDs from item/account URLs or account details.

2.6 Credential Checklist

Do not proceed until all five exist:

• `CWS_CLIENT_ID`
• `CWS_CLIENT_SECRET`
• `CWS_REFRESH_TOKEN`
• `CWS_PUBLISHER_ID`
• `CWS_EXTENSION_ID`

Step 3: Local Secret File and CI Secret Setup

Create a local template file (no real values committed):

CWS_CLIENT_ID=
CWS_CLIENT_SECRET=
CWS_REFRESH_TOKEN=
CWS_PUBLISHER_ID=
CWS_EXTENSION_ID=

Ensure real secret file path is gitignored.

If using GitHub Actions, ask user if `gh` automation is desired.

If yes, verify:

gh --version
gh auth status

If `gh` auth is missing, tell user to run:

• `gh auth login`

Then implement a helper script that:

• reads secret values from local env file
• validates all required keys are present
• supports `--dry-run`
• masks values in dry-run output
• uploads with `gh secret set ... --repo ...`
• fails fast on missing keys/auth

If user declines `gh`, provide manual secret entry checklist for repository settings.

Step 4: Release Workflow Blueprint (Version-Triggered)

Design the CI workflow around this logic:

1. Read local manifest version. 2. Optionally compare with a secondary version file and fail on mismatch. 3. Exchange refresh token for access token:

• `POST https://oauth2.googleapis.com/token`

4. Fetch CWS status:

• `GET https://chromewebstore.googleapis.com/v2/publishers/<publisherId>/items/<extensionId>:fetchStatus`

5. Extract current published version from:

• `publishedItemRevisionStatus.distributionChannels[0].crxVersion`

6. If local version == published version, skip publish. 7. If version changed:

• build package zip
• upload zip:

`POST https://chromewebstore.googleapis.com/upload/v2/p