Chrome Web Store Listing

Scope

This skill handles the store submission package: listing copy, privacy disclosures, the privacy policy page, promo graphics, and the review/publish process.

It does not handle:

• Extension engineering (manifest, content scripts, background worker) → chrome-extension-dev
• OAuth/sign-in flows and their redirect URIs → chrome-extension-auth
• Backend deploy, CORS allowlists, CI/CD → chrome-extension-deploy
• Payment/billing integration → chrome-extension-payments

This skill reads the manifest and codebase to write accurate copy; it does not build or deploy the extension or its backend. When the first store upload assigns an item ID, hand the ID off to chrome-extension-auth (OAuth redirect URI) and chrome-extension-deploy (CORS allowlist) — don't try to edit those systems from here.

Ground rule: derive facts, never invent them

Every claim in the listing, the privacy practices tab, and the privacy policy must trace back to something real in the codebase:

• Permissions and optional_permissions → read the manifest (or wxt.config.ts / manifest.json source) directly.
• Features and pricing → read the actual UI/pricing code, not assumptions.
• Data that "leaves the device" → read the actual network calls (API client, background worker fetches), not what would be convenient to disclose.

If the user asks for copy about a feature you cannot find in the code, say so and ask, instead of writing it anyway. If permissions change, the listing description, the privacy practices tab, and the privacy policy must all be updated together — treat them as one synchronized document, not three independent ones.

Workflow

1. Inventory the facts first. Find the manifest (permissions, optional_permissions, name, description, host permissions), the pricing/plan definitions, and any outbound network calls (what data actually leaves the device, and to whom). This is the source of truth for every later step.
2. Write the listing copy. Follow references/listing-copy.md for the title/summary (summary = manifest description, ≤132 chars), the description structure (hook → how it works → features → privacy → free vs pro → pricing → support), category/language choice, and keyword guidance that stays inside the Store's no-keyword-stuffing policy.
3. Fill the Privacy practices tab. Follow references/privacy-practices-and-permissions.md: one single-purpose sentence, one justification per permission (use the template library — do not reuse another extension's wording verbatim, adapt it to what this extension actually does), "remote code: No" unless the code truly fetches and executes remote code, the data-usage disclosure table (tick only what actually leaves the device), and the three certifications.
4. Write or update the privacy policy page. Follow references/privacy-policy-template.md. Every tick in step 3's disclosure table must have a matching sentence in the policy, and vice versa — cross-check them side by side before moving on.
5. Produce the graphics. Follow references/graphics-specs-and-recipe.md for exact specs (icon, screenshots, small tile, marquee) and the capture-then-compose recipe: capture real UI with Playwright against the unpacked build (mocked network, seed/demo data — never a real user's data), then render branded HTML frames around those captures at the exact final pixel size with scripts/render-store-assets.mjs and assets/slide-template.html. Render the store icon from the brand SVG the same way.
6. Walk the submission checklist. Follow references/submission-and-review.md: developer registration fee, first-upload item ID hand-off, zip packaging (no manifest key), versioning, common rejection reasons, review times, and how to respond to a rejection.

Quick reference index

Running the render script

node scripts/render-store-assets.mjs <slides.json> --out <output-dir> [--playwright-cwd <dir-with-playwright-installed>]

--playwright-cwd should point at a project whose node_modules already has playwright or @playwright/test (for example the extension app itself) so the skill doesn't need its own copy. If omitted, the script tries to import('playwright') from its own resolution scope. See references/graphics-specs-and-recipe.md for the slide JSON schema and assets/example-slides.json for a worked example. Always write output outside the extension repo's tracked docs/ folder until reviewed, then move the final files in.

Verify-on-dashboard flags

A few Chrome Web Store specifics change without notice. Anything marked "verify on the dashboard" in the reference files should be re-checked against the live Developer Dashboard before submission — do not treat those numbers as permanently fixed.