Chrome Extension Publish

Use this skill to ship Chrome extensions with minimal review risk and fast iteration.

Full Pipeline (Recommended)

Run one command to execute the end-to-end release flow (baseline files, permission audit, packaging, assets, and bilingual listing draft):

python3 scripts/run_full_release_pipeline.py \
  --root /abs/path/to/extension \
  --icon-source /abs/path/to/icon.png \
  --include-marquee

Behavior note:

• If --inputs is not provided, the pipeline auto-captures screenshots first (Playwright).
• Use --no-auto-capture-if-no-inputs to disable this default.
• Use --headless only when you explicitly want headless capture mode.

Outputs:

• release/chrome-webstore.zip
• release/permission-audit.md
• release/store-assets/*
• release/cws-listing.zh-en.md
• release/full-release-summary.md
• release/cws-submit-proof.png (only when --submit-playwright is enabled)

Optional submit automation (Playwright, human-in-the-loop safe default):

python3 scripts/run_full_release_pipeline.py \
  --root /abs/path/to/extension \
  --icon-source /abs/path/to/icon.png \
  --include-marquee \
  --submit-playwright \
  --submit-item-id <CWS_ITEM_ID> \
  --submit-locale zh

If item id is unknown, fallback to name-based auto-selection from dashboard:

python3 scripts/run_full_release_pipeline.py \
  --root /abs/path/to/extension \
  --submit-playwright \
  --submit-item-name "Image Compressor"

Execute final submission click only when explicitly requested:

python3 scripts/run_full_release_pipeline.py \
  --root /abs/path/to/extension \
  --submit-playwright \
  --submit-item-id <CWS_ITEM_ID> \
  --submit-for-review

Workflow

1. Confirm release intent.

• Confirm whether this is first publish or update.
• Confirm target version and primary change summary.

2. Audit manifest.json for least privilege.

• Keep only actually used permissions.
• Remove unused host permissions and broad match patterns.
• Treat content_scripts.matches as host-match scope for CWS host-permission review.
• Generate permission audit evidence report:

python3 scripts/audit_permissions.py \
  --root . \
  --out release/permission-audit.md

3. Build upload ZIP from source files only.

• Include: manifest.json, runtime code, icons, needed assets.
• Exclude: .git, screenshots, local notes, test artifacts.
• Before packaging, ensure release artifacts are git-ignored to avoid noisy commits.
• Treat release/ as generated output only. Do not keep canonical docs only in release/ if that folder is ignored.
• Canonical privacy policy file must be root-level privacy-policy.md (fixed filename).
• Generate baseline files before packaging:

python3 scripts/prepare_publish_basics.py --root .

• This command ensures:
  • privacy-policy.md exists at project root.
  • .gitignore includes release/, __pycache__/, *.py[cod].
• Prefer deterministic packaging script:

python3 scripts/package_extension.py \
  --root . \
  --mode manifest \
  --out release/chrome-webstore.zip

• --mode manifest now includes manifest-declared files plus transitive local dependencies (for example popup script src, link href, and ES module imports).

4. Prepare store listing graphic assets (required before submit).

• Follow current CWS image specs:
  • Store icon: 128x128 (PNG).
  • Screenshots: at least 1, up to 5, use 1280x800 (preferred) or 640x400.
  • Small promo tile: 440x280.
  • Marquee promo tile: 1400x560 (optional).
• Generate assets from one or more source images:

python3 scripts/generate_store_assets.py \
  --inputs /abs/path/source-1.png /abs/path/source-2.jpg \
  --icon-source /abs/path/icon.png \
  --root release/store-assets \
  --include-marquee

• In run_full_release_pipeline.py, when --inputs is omitted, screenshot capture is triggered automatically before asset generation.
• For manual capture or debugging, use $chrome-webstore-image-generator (scripts/capture_extension_screenshots.py). Preinstall dependency once:

python3 -m pip install playwright
python3 -m playwright install chromium

• The generator auto-picks an icon source from icon/logo-like names or near-square images.
• If icon inference is ambiguous (for example, screenshot-like inputs), generation fails fast. Set --icon-source explicitly to avoid screenshot-derived icons.
• Screenshot files append by default (keep existing screenshots and continue numbering). Use --overwrite-screenshots when you need deterministic replacement from screenshot-1-*.
• Use --allow-icon-fallback only when you intentionally want legacy single-input fallback behavior.
• Use the naming convention in references/cws-publish-templates.md.
• Validate asset dimensions/count:

python3 scripts/validate_store_assets.py --root release/store-assets

5. Prepare store listing content.

• Write short summary and detailed description focused on user value.
• Always draft a Single Purpose statement for CWS (concise, concrete, feature-linked).
• State non-advisory nature for finance-related extensions.
• Produce paired Chinese and English versions for all listing text blocks (short summary, long description, single purpose, permissions rationale, remote code answer, data use disclosure, reviewer notes), unless user explicitly requests single-language output.
• Ensure host match rationale exists for CWS when any host_permissions or content_scripts.matches is declared.
• Prefer automatic draft generation:

python3 scripts/generate_publish_docs.py \
  --root . \
  --out release/cws-listing.zh-en.md \
  --privacy-policy privacy-policy.md

• For custom wording, load references/cws-publish-templates.md.

6. Fill sensitive CWS forms correctly.

• Permissions rationale: explain each permission with concrete feature linkage.
• Remote code: answer "No" unless extension executes remote JS/Wasm/eval/new Function.
• Data use: if no personal data collection, select none and keep policy consistent.
• Privacy policy: provide public URL and ensure wording matches actual behavior.
• Privacy policy file location: always privacy-policy.md at extension root, not release/privacy-policy.md.
• Privacy policy maintenance on every release/update:
  • Run a policy drift check against current code and manifest changes.
  • If behavior changed (permissions, host permissions, external endpoints, data storage keys, data flow, user-visible features), update policy text and Last updated date.
  • Keep CWS Data Use answers and privacy policy wording strictly consistent.
  • If no behavior changed, explicitly record "policy update not required" with reason.

7. Submit and track.

• Upload ZIP.
• Add review notes describing test path and why permissions are required.
• Keep a changelog entry for each submitted version.
• For dashboard automation, use Playwright submit helper:

python3 scripts/submit_cws_playwright.py \
  --root . \
  --item-id <CWS_ITEM_ID> \
  --locale zh \
  --privacy-policy-url https://example.com/privacy

• Safe default: helper does not click final submit unless --submit-for-review is passed.
• Keep --headless off for login/2FA unless you already have a valid persisted session.

Decision Rules

Remote Code

Answer "No remote code" when all executable JS/Wasm is packaged in extension files and network requests are data-only (JSON/HTML/text).

Data Disclosure

Do not declare user data collection when extension only fetches public market data and stores cache locally without account identifiers.

Privacy Policy Update Trigger

Update the privacy policy when any of the following changes:

• manifest.json permissions or host permissions.
• New or removed external data endpoints.
• New local storage keys/categories or changed retention/usage.
• New user data categories, analytics, auth/account linkage, or data sharing behavior.
• New feature flows that change what data is processed. If none of the above changed, keep existing policy text but still refresh the release note with an explicit "no policy change" decision.

Permission Rationale Quality Bar

For every permission:

• Mention exact feature.
• Mention scope and limits.
• Mention no personal data transfer when applicable.

Single Purpose Quality Bar

• Must describe one core purpose in one short paragraph.
• Must map major features back to that same single purpose.
• Must explicitly state no unrelated functionality.

Language Completeness

• Default output is bilingual (ZH + EN) for all CWS text content.
• Chinese and English versions must be semantically aligned, with no policy or feature mismatch.

Rejection Triage

When CWS rejects:

1. Extract the exact rejection category and quote.
2. Map it to manifest fields and code paths.
3. Propose smallest fix first (remove permission, tighten host, correct image asset size, adjust wording).
4. Resubmit with explicit reviewer note on what changed.

Output Contract

When assisting a publish task, return:

1. Release readiness checklist (pass/fail).
2. Required manifest changes (if any).
3. Graphic asset checklist (required/optional, size, status).
4. Permission audit summary with report path (release/permission-audit.md) and required fixes.
5. Privacy policy decision for this release (update required / not required) with concrete reason.
6. Ready-to-paste bilingual (ZH/EN) CWS text blocks (short summary, long description, single purpose, permissions, remote code, data use, review notes) and canonical privacy-policy file path (privacy-policy.md at extension root).
7. Final packaging command and ZIP path.
8. Full-pipeline command and summary path (release/full-release-summary.md).

Templates

Single Purpose (ZH) Template

该扩展的单一用途是帮助用户管理和维护浏览器书签。它会扫描书签链接状态、识别无效或重复书签，并提供按域名整理、重试检测与删除无效项等能力。以上功能均服务于“书签清理与组织”这一唯一目的，不包含与书签管理无关的功能。

Single Purpose (EN) Template

The extension has a single purpose: helping users maintain and organize browser bookmarks. It checks bookmark link health, identifies invalid or duplicate bookmarks, and provides domain-based organization, retry checks, and invalid-bookmark removal. All features support this single bookmark-management purpose and do not provide unrelated functionality.