agentsclimarketplace

Browser extension

Skill Skryx-L-A/project-kit/skills/browser-extension

Say "new project" → get a perfectly-prepared project folder. A Claude Code bootstrap kit that grills the plan to a Definition of Ready, then auto-scaffolds files, memory, project sub-agents & tooling — routing to type-specific sub-skills (website, api, data/ml, quant, SaaS, CLI, app, game-mod, research, OSS… + a 7-day build-business ultraskill).

Install
npx -y skills add Skryx-L-A/project-kit --skill browser-extension

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Build/set up a browser-extension project — a Chrome/Firefox/Edge add-on with content scripts, a background service worker, and a popup/options UI — from the user's grilled answers. Project-kit sub-skill loaded by new-project routing whenever someone wants to build a browser extension, add-on, Chrome/Firefox plugin, or web-page-injecting tool. Defaults to Manifest V3, minimal permissions, and a store-ready listing; can drive claude-in-chrome/playwright to test the loaded extension live.

SKILL.md

6.4 KB, as published. Nobody here has run it

browser-extension — the add-on builder sub-skill

What this sub-skill is for

Standing up a real, installable browser extension: a Chrome/Firefox/Edge add-on built on Manifest V3, with content scripts, a background service worker, and a popup/options UI. It covers the bits that make an extension actually shippable — permission minimisation, cross-browser packaging, and store-listing assets. Loaded by new-project routing for add-on/plugin requests.

Mandatory grill-questions (fold into the Definition of Ready)

Lock these before scaffolding — they decide manifest, permissions, and store fit:

  • Core job — what does it do on which pages? In-page UI, background processing, or both?
  • Target browsers — Chrome only, or Chrome + Firefox (+ Edge)? (Affects manifest quirks + packaging.)
  • Host permissions — which sites/origins does it touch? Push toward activeTab/optional permissions over broad <all_urls>.
  • Permissions list — storage, scripting, tabs, alarms, notifications, etc. — justify each; drop anything not strictly needed.
  • Data & network — does it call an external API or backend? Where does user data go? Any auth/keys?
  • UI surfaces — popup, options page, side panel, injected overlay, context menu? Which are needed?
  • Storage — chrome.storage.local vs .sync; what's persisted and is any of it sensitive?
  • Distribution — Chrome Web Store, Firefox AMO, both, or unlisted/self-hosted? (Sets the listing + review burden.)
  • Privacy posture — what the privacy policy must state; whether a remote-code/CSP review applies.

Project sub-agents to generate (into .claude/agents/)

  • manifest-permissions-auditor (delegate-by-default) — reviews manifest.json on every change: minimises permissions/host access, validates MV3 structure, flags anything a store reviewer would reject.
  • content-script-builder (delegate-by-default) — writes content scripts + DOM injection/overlay UI safely (isolated world, no clobbering host pages, idempotent injection).
  • background-worker-builder (delegate-by-default) — owns the MV3 service worker: event-driven, no long-lived state assumptions, message passing, alarms.
  • extension-test-driver — loads the unpacked extension and exercises it live via claude-in-chrome/playwright; checks popup, injection, and message flow.
  • store-listing-author — drafts Web Store / AMO listing copy, permission justifications, screenshots checklist, and the privacy policy.

Tools / CLIs / MCP / skills needed

Check in environment-readiness; offer install, never auto-install:

  • Node 20+ / package manager; a bundler tuned for extensions (Vite + CRXJS, or wxt/webextension-polyfill for cross-browser).
  • web-ext (npm i -g web-ext) for Firefox run/lint/sign; Chrome for chrome://extensions unpacked loading.
  • MCP: claude-in-chrome (load + drive the real extension in the user's Chrome — invoke the claude-in-chrome skill first) and/or playwright for automated flow tests; magic (21st.dev) for popup/options UI.
  • CHAIN global skills: frontend-design for the popup/options/overlay UI; web-aeo only if a marketing landing page is wanted; code-review + verify before packaging.

File / asset nudges (on top of the base set)

Beyond CLAUDE.md, PROJEKT_<NAME>.md, TASKS.md, DONE.md, README, .claude/:

  • src/manifest.json (or a manifest generator) — MV3, with Chrome/Firefox variants if cross-browser.
  • src/content/, src/background/, src/popup/, src/options/ — the standard surfaces.
  • src/lib/messaging.ts — typed runtime message contracts between worker/content/popup.
  • icons/ — 16/32/48/128 px icon set (no emoji; typographic/drawn marks only).
  • store/ — listing copy, permission justifications, screenshots, promo tiles, PRIVACY.md.
  • PERMISSIONS.md — every permission + host with a one-line "why we need it".
  • dist/ build output + a package script that zips the store-ready artifact.

Stack defaults & done-bar

Default stack: Manifest V3, TypeScript, Vite + CRXJS (or wxt), webextension-polyfill for cross-browser, chrome.storage for state, web-ext for Firefox tooling. Minimal-permission manifest by default — start from activeTab and add only what the grilled scope proves necessary.

"Finished/working" means (checkable bar):

  • Loads as an unpacked extension in Chrome with no manifest/console errors, and (if targeted) in Firefox via web-ext run.
  • The core job works live on a real target page — content injection, popup, and background message flow all verified (driven via claude-in-chrome/playwright).
  • Permissions are minimal — every entry in the manifest is justified in PERMISSIONS.md; no unused or over-broad host access.
  • web-ext lint (Firefox) passes; the MV3 structure passes a store-reviewer sanity check.
  • A store-ready zip builds, and the listing assets + privacy policy + permission justifications exist.
  • State persists/clears as designed; no secrets baked into the bundle.

Guardrails

  • Permission minimisation is mandatory — prefer activeTab + optional permissions; broad <all_urls>/host access must be explicitly justified or removed. Stores reject over-asking.
  • No remote code execution — MV3 forbids it; bundle all logic, don't eval or load remote scripts.
  • Content scripts must not break host pages — isolated world, namespaced, idempotent injection, clean teardown.
  • Privacy honesty: the privacy policy must truthfully state what data is collected and where it goes; no silent exfiltration of page content or PII.
  • Never invent or commit credentials/API keys — user pastes them; keys stay out of the bundle and git.
  • No emojis in the UI — typographic symbols or drawn marks only (user's standing rule).
  • Commits under the user's name only (Skryx-L-A); never add Claude as co-author.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.