Chrome Web Store Featured Badge Audit
Audit a Chrome extension codebase + store listing against Google's published
criteria for the Featured badge (manually reviewed by the CWS team) and the
Established Publisher badge (granted on publisher standing), then produce a
report with a prioritized fix plan.
Two facts shape every audit:
- Badges cannot be bought or expedited. The only lever is genuinely meeting
the criteria. Never suggest gaming tactics (incentivized reviews, keyword
stuffing); these violate program policies and disqualify the extension.
- Featured is a human review. The reviewer checks best-practice adherence,
UX quality, modern platform APIs, privacy respect, and listing quality. The
audit must therefore judge quality, not just tick boxes — "has screenshots"
passes a checklist; "screenshots are clear, uncluttered, and show real
functionality" passes a review.
Workflow
1. Gather evidence
Collect before judging. From the codebase (ask the user for the repo path if
not obvious):
manifest.json — manifest version, permissions, host permissions, name,
description, icons- Privacy policy file/URL and what data the code actually collects (search for
network calls, analytics, storage of user data)
- Onboarding surfaces: first-install pages, popup, options page
- Test setup (E2E tests count toward the "tested across environments" practice)
- bfcache hazards:
unload handlers, WebSocket/WebRTC in content scripts
- Store assets: icon sizes, screenshots, promo tile (440×280), marquee
(1400×560), listing copy if checked into the repo
From the user (these live in the CWS dashboard and usually aren't in the repo):
publisher verification status, account standing, current listing text/category,
rating and review count, whether core features need login/payment. If the
extension is published, fetch its public listing page to assess copy,
screenshots, rating, and category directly. Don't guess at dashboard-only
facts — mark them "needs manual check" instead.
2. Audit against the criteria
Read references/audit-checklist.md and work through every item. For each,
record status — ✅ pass / ⚠️ partial / ❌ fail / ❓ needs manual check — with
evidence (file:line, asset path, or fetched listing content), never bare
assertions. The checklist covers seven areas:
- Eligibility gates (the nomination preconditions — any ❌ here blocks everything)
- Policy & security compliance
- Technical best practices (MV3, permissions minimization, performance, bfcache)
- Privacy (disclosures match actual behavior)
- User experience (onboarding, intuitive use, clear purpose)
- Store listing quality (copy, images, category, branding)
- Established Publisher prerequisites
references/badge-criteria.md holds the verbatim source criteria with URLs —
cite it when the user questions why an item matters.
3. Report
ALWAYS use this structure:
# CWS Badge Readiness — <extension name> v<version>
## Verdict
One paragraph: ready to nominate / nearly ready / not ready, and the single
biggest blocker.
## Scorecard
| # | Area | Status | Evidence |
(one row per checklist item, grouped by the seven areas)
## Blockers (must fix before nominating)
Numbered, each with: what fails, why it matters to the reviewer, concrete fix.
## High-impact improvements (won't block, but reviewers look here)
Same format. Quality-of-listing and UX-polish items usually land here.
## Needs manual check
Dashboard-only items the user must verify, each with exact steps (where to
click in the CWS Developer Dashboard).
## Nomination
If ready: link to the nomination steps in references/badge-criteria.md.
If not: the shortest path to ready, as an ordered task list.
4. Offer to fix
After the report, offer to implement code-side fixes (listing copy drafts,
manifest changes, bfcache fixes, onboarding improvements). Don't start fixing
without a go-ahead — the user may only want the assessment.
Judgment calls
- Severity honesty: an item is ❌ only if it clearly fails the published
criterion. Style opinions go to "high-impact improvements", not blockers.
- The criteria say "among other things" — Google's review isn't exhaustive
in public docs. When the extension does something the docs don't address,
judge it by the review's stated values: enjoyable, intuitive, modern APIs,
privacy-respecting. Say so explicitly when you're extrapolating.
- Listings rot: if listing copy in the repo differs from the live listing,
the live listing is what the reviewer sees — flag the drift.
1---2name: cws-featured-badge3description: Audit any Chrome extension against Chrome Web Store Featured-badge and Established Publisher badge criteria, and produce a prioritized fix plan to qualify. Use this whenever the user mentions the Chrome Web Store Featured badge, getting an extension featured, CWS badges, store listing quality review, badge readiness, extension discoverability, or asks "is my extension ready for the Web Store" — even if they don't say the word "badge". Also use it before any Chrome Web Store submission or major listing update to catch disqualifying issues early.4---56# Chrome Web Store Featured Badge Audit78Audit a Chrome extension codebase + store listing against Google's published9criteria for the **Featured badge** (manually reviewed by the CWS team) and the10**Established Publisher badge** (granted on publisher standing), then produce a11report with a prioritized fix plan.1213Two facts shape every audit:141. **Badges cannot be bought or expedited.** The only lever is genuinely meeting15 the criteria. Never suggest gaming tactics (incentivized reviews, keyword16 stuffing); these violate program policies and disqualify the extension.172. **Featured is a human review.** The reviewer checks best-practice adherence,18 UX quality, modern platform APIs, privacy respect, and listing quality. The19 audit must therefore judge *quality*, not just tick boxes — "has screenshots"20 passes a checklist; "screenshots are clear, uncluttered, and show real21 functionality" passes a review.2223## Workflow2425### 1. Gather evidence2627Collect before judging. From the codebase (ask the user for the repo path if28not obvious):2930- `manifest.json` — manifest version, permissions, host permissions, name,31 description, icons32- Privacy policy file/URL and what data the code actually collects (search for33 network calls, analytics, storage of user data)34- Onboarding surfaces: first-install pages, popup, options page35- Test setup (E2E tests count toward the "tested across environments" practice)36- bfcache hazards: `unload` handlers, WebSocket/WebRTC in content scripts37- Store assets: icon sizes, screenshots, promo tile (440×280), marquee38 (1400×560), listing copy if checked into the repo3940From the user (these live in the CWS dashboard and usually aren't in the repo):41publisher verification status, account standing, current listing text/category,42rating and review count, whether core features need login/payment. If the43extension is published, fetch its public listing page to assess copy,44screenshots, rating, and category directly. Don't guess at dashboard-only45facts — mark them "needs manual check" instead.4647### 2. Audit against the criteria4849Read `references/audit-checklist.md` and work through every item. For each,50record status — ✅ pass / ⚠️ partial / ❌ fail / ❓ needs manual check — with51**evidence** (file:line, asset path, or fetched listing content), never bare52assertions. The checklist covers seven areas:53541. Eligibility gates (the nomination preconditions — any ❌ here blocks everything)552. Policy & security compliance563. Technical best practices (MV3, permissions minimization, performance, bfcache)574. Privacy (disclosures match actual behavior)585. User experience (onboarding, intuitive use, clear purpose)596. Store listing quality (copy, images, category, branding)607. Established Publisher prerequisites6162`references/badge-criteria.md` holds the verbatim source criteria with URLs —63cite it when the user questions why an item matters.6465### 3. Report6667ALWAYS use this structure:6869```70# CWS Badge Readiness — <extension name> v<version>7172## Verdict73One paragraph: ready to nominate / nearly ready / not ready, and the single74biggest blocker.7576## Scorecard77| # | Area | Status | Evidence |78(one row per checklist item, grouped by the seven areas)7980## Blockers (must fix before nominating)81Numbered, each with: what fails, why it matters to the reviewer, concrete fix.8283## High-impact improvements (won't block, but reviewers look here)84Same format. Quality-of-listing and UX-polish items usually land here.8586## Needs manual check87Dashboard-only items the user must verify, each with exact steps (where to88click in the CWS Developer Dashboard).8990## Nomination91If ready: link to the nomination steps in references/badge-criteria.md.92If not: the shortest path to ready, as an ordered task list.93```9495### 4. Offer to fix9697After the report, offer to implement code-side fixes (listing copy drafts,98manifest changes, bfcache fixes, onboarding improvements). Don't start fixing99without a go-ahead — the user may only want the assessment.100101## Judgment calls102103- **Severity honesty**: an item is ❌ only if it clearly fails the published104 criterion. Style opinions go to "high-impact improvements", not blockers.105- **The criteria say "among other things"** — Google's review isn't exhaustive106 in public docs. When the extension does something the docs don't address,107 judge it by the review's stated values: enjoyable, intuitive, modern APIs,108 privacy-respecting. Say so explicitly when you're extrapolating.109- **Listings rot**: if listing copy in the repo differs from the live listing,110 the live listing is what the reviewer sees — flag the drift.
divyamrastogi