Chrome Web Store Listing

---
name: chrome-web-store-listing
description: Use whenever the user needs a Chrome Web Store submission ready — listing copy, permission justifications, Privacy practices tab, privacy policy page, store screenshots, or promo tiles. Triggers: "chrome web store listing", "store screenshots", "promo tile", "permission justification", "privacy practices", "single purpose", "publish extension", "submit to the store", "extension rejected", "store icon", "marquee tile". Covers manifest-derived title/summary/description copy (never invented features), a justification template for every common MV3 permission (storage, activeTab, tabs, scripting, host permissions/<all_urls>, identity, clipboard, notifications, alarms), the data-usage table plus certifications, a privacy-policy template synced with those disclosures, exact graphics specs (icon, screenshots, small tile, marquee) with a Playwright capture-and-compose script at exact pixel sizes, and the submission workflow (dev fee, item ID hand-off, zip packaging, rejections, review times).
license: MIT
---

# 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

| Need | File |
|---|---|
| Title, summary, description, category, SEO | `references/listing-copy.md` |
| Single purpose + permission justifications + data usage table | `references/privacy-practices-and-permissions.md` |
| Privacy policy page copy | `references/privacy-policy-template.md` |
| Icon/screenshot/promo tile specs + Playwright recipe | `references/graphics-specs-and-recipe.md` |
| Dev account, upload, rejections, review times | `references/submission-and-review.md` |
| Render promo screenshots/tiles/icon | `scripts/render-store-assets.mjs` + `assets/slide-template.html` + `assets/example-slides.json` |

## Running the render script

```bash
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.