Chrome Extension Maintainer#

Goal#

Operate on Chrome extensions as small regulated products: a browser runtime, a permissions contract, a privacy promise, a public listing, a support surface, and a release history.

This skill is an operating workflow and review rubric. It does not bundle a Playwright harness, Chrome Web Store uploader, analytics connector, or package builder. Use repo-local scripts and installed tools when they exist, and report any missing tool as a release-evidence gap rather than inventing proof.

When To Use#

• A Chrome extension needs release readiness review, packaging, or a publish/no-publish decision.
• Store analytics, Search Console, GA, reviews, or support messages suggest weak growth or high uninstall risk.
• Manifest permissions, MV3 service-worker behavior, content scripts, host access, CSP, or privacy claims need review.
• Public surfaces need alignment: Chrome Web Store listing, landing page, support page, privacy page, screenshots, sitemap, or llms.txt.
• A Codex or ClawHub skill companion for Chrome extension maintenance needs validation before publication.

Operating Order#

1. Identify the target extension, release channel, and irreversible action.
   • Separate local Codex install, ClawHub registry publish, GitHub release, Chrome Web Store upload, submit, unpublish, rollback, and public promotion.
   • Do not perform any external upload, submit, registry publish, unpublish, rollback, deletion, or broad public promotion without explicit user approval.
2. Read the extension manifest, package scripts, listing copy, privacy/support pages, landing pages, and previous review artifacts.
3. If policy, Chrome versions, competitor claims, store requirements, or search behavior matter, verify current sources before deciding.
4. Document data flow:
   • browser-visible input
   • local extension storage
   • background/service-worker behavior
   • backend calls
   • third-party APIs or models
   • retention and deletion path
5. Check permissions:
   • prefer activeTab plus click-triggered scripting
   • justify every API and host permission
   • flag new warning surfaces before publish
6. Run the local gates that exist in the repo:
   • manifest/package validation
   • unit tests
   • Playwright/Puppeteer E2E with the unpacked extension
   • service-worker termination/restart tests when relevant
   • localization key/placeholder checks
   • accessibility and responsive layout checks
   • leak/secret scans when publishing public code or skills
7. Use real-user reviewer personas for at least the primary flow:
   • first-time user
   • privacy reviewer
   • Chrome Web Store reviewer
   • power user
   • localization reviewer
   • portfolio reviewer
8. Align public surfaces:
   • CWS title, summary, description, screenshots, privacy declarations, support URL, and reviewer notes
   • landing page, support page, privacy page, sitemap, robots, and llms.txt if present
   • Codex/ClawHub skill metadata when shipping a skill companion
9. Package and inspect the exact artifact intended for release.
10. Produce a green/yellow/red ship recommendation.

Required Reference#

Read references/chrome-extension-maintenance-playbook.md when the task involves release readiness, growth diagnosis, public listing/landing work, privacy claims, permissions, MV3 service workers, i18n, packaging, browser E2E evidence, or portfolio decisions.

Validation Commands#

Use the project’s own commands first. If the repo has no equivalent command, say that the evidence is missing.

For Chrome extension repos, typical gates are:

bash

npm run check
npm test
npm run check:cws
npm run check:extension-locales
npm run e2e
npm run package

For Codex/ClawHub skill packages, use commands like:

bash

python3 ~/.codex/skills/.system/skill-creator/scripts/quick_validate.py <skill-dir>
clawhub whoami --no-input
clawhub inspect <slug> --no-input
find <skill-dir> -maxdepth 3 -type f -print | sort

Before publishing a skill package, confirm:

• SKILL.md is valid and has concrete workflow, rules, and validation guidance.
• agents/openai.yaml matches the skill’s actual scope.
• .clawhubignore excludes generated local state such as .clawpatch/, .git/, .codex-run/, node_modules/, dist/, logs, and cache files.
• no generated review state, local absolute paths, secrets, or private artifacts are in the package.
• ClawPatch or an equivalent review has either zero findings or documented non-applicability.

Green/Yellow/Red#

Green:

• primary browser flow works in real E2E evidence
• privacy and permission story matches code and public copy
• package/version identity is clear
• no untriaged P0/P1 findings remain

Yellow:

• usable for quiet test, beta, or local publication
• evidence or copy still has gaps
• do not broadly promote

Red:

• primary flow broken
• promise mismatch
• privacy ambiguity
• missing real browser evidence
• unresolved release blocker

Review Output#

Lead with critical findings. Then report:

• tests and commands run
• user flows verified
• files changed
• release artifacts created
• remaining blockers
• rollback or recovery path
• final green/yellow/red decision

Rules#

• Prefer fixes that reduce permission, privacy, and support risk.
• Treat installs as weak evidence; prioritize retained weekly users, uninstall ratio, conversion, support themes, and actual repeated use.
• Do not let listing or landing copy claim official affiliation, background crawling, unlimited use, hidden safety, or broad privacy promises unless the implementation proves it.
• For i18n, require default_locale, complete locale keys, placeholder parity, and RTL smoke coverage when /_locales exists.
• For MV3, assume service workers can terminate and require durable state for long work.
• For public skill publication, validate SKILL.md, agents/openai.yaml, references/scripts, leak risk, and registry auth before publishing.