TL;DR: Chrome extension development is death by a thousand papercuts — scattered docs, cryptic permission warnings, multi-context debugging, and a Web Store review process that rejects you for reasons it won't explain. I installed 8 open-source AI agent skills that turn Claude Code, Cursor, Copilot, and friends into an actual extension expert. One
npxcommand. MIT licensed. Below is the full breakdown.
The 2 a.m. moment that made me try this
Picture it: my extension is done. It works locally. I'm proud. I zip it, upload it to the Chrome Web Store, and hit submit.
Rejected. "Single purpose violation." No line number. No example. Just vibes.
I fix it. Resubmit. Rejected. "Excessive permissions." I had <all_urls> because some Stack Overflow answer from 2019 told me to.
Resubmit. Rejected. Missing permission justification.
If you've ever built a Chrome extension, you know this dance. The actual coding is maybe 30% of the job. The other 70% is fighting Manifest V3 quirks, permission archaeology, multi-context debugging (service worker? content script? popup? all of them?), and the opaque black box that is Chrome Web Store review.
I'm already using an AI coding agent for everything else. So why was it so bad at this?
Because a general-purpose AI agent doesn't know Chrome's rules. It hallucinates chrome.tabs.executeScript() (removed in MV3). It puts host_permissions inside permissions (wrong array). It suggests eval() (instant rejection). It's confident and wrong — the worst combination.
The fix wasn't a better model. It was giving the model the right playbook.
What are "AI Agent Skills" (and why they're a 2026 superpower)
If you haven't run into them yet: Agent Skills are specialized instruction sets that turn a general AI coding agent into a domain expert.
Each skill is basically a SKILL.md file — a focused playbook of APIs, patterns, gotchas, and workflows for one specific domain. They use a progressive disclosure pattern:
- A concise
SKILL.md(under ~150 lines) loads automatically when the skill activates. - Detailed reference docs load on-demand, only when the agent needs deeper context.
Translation: your agent gets deep expertise without blowing up your token budget on context you don't need. This is the same pattern Anthropic uses for its official skills, and the broader ecosystem has exploded past 1,000+ community skills in 2026.
The set I'm about to walk through — Browser Extension Skills by Extension Booster — is purpose-built for Chrome extensions, and it works across basically every agent you'd actually use:
✅ Claude Code · Cursor · Windsurf · GitHub Copilot · Cline · Aider · Continue · Roo Code · Augment Code · Amazon Q Developer
One repo. MIT license. Eight skills. Let's go.
Install in 10 seconds
# Install all skills to your current project
npx skills add quangpl/browser-extension-skills
# ...or globally, available in every project
npx skills add quangpl/browser-extension-skills -g
# ...or cherry-pick just what you need
npx skills add quangpl/browser-extension-skills -s extension-create,extension-dev
That's it. No config. The skills activate automatically based on what you ask your agent to do. You just describe the goal in plain English — the right skill wakes up.
The 8 skills, and the exact pain each one kills
Here's the lineup. Think of it as the full extension lifecycle, from empty folder to live on the Web Store.
| Skill | What it does | When it fires |
|---|---|---|
extension-create |
Scaffolds a complete extension with the WXT framework | Starting a new project |
extension-dev |
Detects your stack, implements features, debugs every context | Building & debugging |
extension-manifest |
Generates manifest.json with minimum permissions from your code |
Setting up the manifest |
extension-analyze |
Security + CWS compliance audit before you submit | Pre-submission review |
extension-test |
Unit, integration & E2E testing (Jest + Puppeteer) | Writing tests |
extension-assets |
Generates icons + Web Store listing images | Prepping visuals |
extension-publish |
Web Store submission, listing optimization, CI/CD | Shipping & updates |
extension-migration |
Step-by-step MV2 → MV3 upgrade | Modernizing legacy code |
Now the good part — what they actually do for you.
1. extension-create — from "I have an idea" to a running extension in seconds
You say:
Create a Chrome extension that highlights all links on a page
The agent activates extension-create, scaffolds a project with WXT (the modern extension framework), wires up your entrypoints, and configures the manifest. Supports React, Vue, Svelte, Solid, Vanilla, and TypeScript.
npx wxt@latest init my-extension --template react
cd my-extension
pnpm install
pnpm dev # hot reload 🔥
pnpm build # production build
pnpm zip # store-ready zip
No more copy-pasting a half-broken boilerplate from a 3-year-old repo.
2. extension-dev — it finally knows the Chrome API
This is the one that ended my hallucination nightmares. It auto-detects your framework (WXT? Plasmo? CRXJS? Vanilla?) and pulls the right docs, then implements features with correct API usage.
It ships with a quick reference for the top 20 chrome.* APIs and — crucially — the right message-passing pattern, which everyone gets wrong:
// Popup → Service Worker (one-time message)
const response = await chrome.runtime.sendMessage({ type: 'GET_DATA' });
// Service Worker listener
chrome.runtime.onMessage.addListener((msg, sender, reply) => {
if (msg.type === 'GET_DATA') {
reply({ data: '...' });
return true; // ← the line 90% of tutorials forget
}
});
It even knows how to debug each context (service worker via chrome://extensions → "inspect", popup via right-click → Inspect, etc.). That alone has saved me hours of "why is my console.log going nowhere."
3. extension-manifest — minimum permissions, automatically
Remember my <all_urls> rejection? This skill reads your code, maps your actual Chrome API usage to the minimum required permissions, and generates a clean MV3 manifest.
It catches the classics that get extensions rejected:
| Mistake | Fix |
|---|---|
host_permissions inside permissions
|
Move to its own array |
Using <all_urls>
|
Narrow to specific domains |
tabs permission overuse |
Use activeTab instead |
| CSP as a string | Must be an object |
Fewer permissions = fewer scary install warnings = higher install conversion. This is free trust.
4. extension-analyze — the security audit that saves your submission
Before you submit, this skill scans permissions, CSP, message handlers, storage, XSS vectors, dependencies, and CWS compliance. It surfaces the top 10 issues that actually get extensions killed, ranked by severity:
- 🔴 Critical:
unsafe-eval/unsafe-inlinein CSP, hardcoded API keys,eval()/new Function(), remote script loading (an MV3 violation) - 🟠 High:
innerHTMLwith page-sourced data (XSS),onMessagewithout a sender-origin check, HTTP instead of HTTPS - 🟡 Medium: unnecessary
<all_urls>, syncing sensitive data, unrestrictedweb_accessible_resources
Run it before every submission and you stop finding out about these from a rejection email.
5. extension-test — yes, you can actually test extensions
Testing extensions is notoriously painful because extensions can't run headless. This skill sets up the whole pyramid:
-
Unit (Jest +
jest-chromemocks) — isolated logic - Integration (Jest) — message passing between services
- E2E (Puppeteer) — a real Chrome with your extension loaded
And it knows the gotcha that breaks everyone's first E2E attempt:
const browser = await puppeteer.launch({
headless: false, // ← extensions REQUIRE this
args: [
`--disable-extensions-except=${path.resolve('dist')}`,
`--load-extension=${path.resolve('dist')}`,
],
});
6. extension-assets — every icon and store image, generated
The Web Store demands a small museum of assets and rejects you if any are missing or the wrong size. This skill generates them all:
- Icons: 16, 32, 48, 128px
- Listing: 1280×800 screenshots, 440×280 small tile, 920×680 large tile, 1400×560 marquee
Generation via ImageMagick CLI, the Gemini API for AI-generated visuals, or prompt templates for any image tool. No more "rejected: missing 128px icon" at 1 a.m.
7. extension-publish — the Web Store playbook, decoded
This is the skill that would've saved me three rejections. It knows the top 10 rejection reasons (single-purpose violations, excessive permissions, missing privacy policy, keyword spam, remote code…) and exactly how to avoid each. Plus listing optimization that actually moves installs:
- Title: action verb + benefit, ≤45 chars, no keyword stuffing
- Description: the first 150 chars show in search — make them count
- Screenshots: annotated, real UI, 1280×800 convert best
It'll even wire up CI/CD so future updates publish automatically.
8. extension-migration — drag your MV2 extension into 2026
Still got a Manifest V2 extension on borrowed time? This skill walks the migration with a full breaking-changes map and API translation table:
chrome.extension.getURL() → chrome.runtime.getURL()
chrome.tabs.executeScript() → chrome.scripting.executeScript({ func })
chrome.browserAction.* → chrome.action.*
webRequest (blocking) → declarativeNetRequest
localStorage → chrome.storage.local
setInterval (background) → chrome.alarms
background.scripts becomes a service_worker. CSP becomes an object. Host permissions move out. It handles the whole list so you don't miss the one change that silently breaks production.
The actual workflow: idea → live, narrated by your agent
Here's what a full build looks like once the skills are installed. You're just talking:
You: Create a Chrome extension that highlights all links on a page
🤖 → extension-create scaffolds with WXT, sets up entrypoints, configs manifest
You: Add a popup that shows the link count and a toggle
🤖 → extension-dev detects WXT + React, implements the popup with chrome.tabs
You: Generate all icons and store screenshots
🤖 → extension-assets creates 16/32/48/128 icons + listing images
You: Analyze for security issues and publish to the Web Store
🤖 → extension-analyze scans → extension-publish validates listing → submits
Four sentences. The skills handle the framework choice, the API correctness, the permission minimization, the asset sizes, the security scan, and the submission checklist. You stay in plain English; the agent stays in Chrome's rulebook.
Why this beats "just ask ChatGPT"
A raw model gives you plausible answers. Plausible is exactly what gets you rejected. The difference is grounding:
| Without skills | With skills |
|---|---|
| Hallucinates removed MV3 APIs | Uses current chrome.scripting.*
|
<all_urls> by default |
Minimum permissions from real usage |
| "Looks fine" pre-submission | Severity-ranked security audit |
| You discover rules via rejection | Rules baked in before you submit |
| Generic boilerplate | WXT scaffold + framework detection |
It's the difference between an intern who's heard of Chrome extensions and a senior dev who's shipped fifty of them.
Get it (it's free and open source)
The skills are MIT licensed and live in one repo:
- 🧩 Skills page + full docs: extensionbooster.net/skills
- ⭐ GitHub:
quangpl/browser-extension-skills - ⚡ Install:
npx skills add quangpl/browser-extension-skills
And if you want the rest of the extension toolkit — an icon generator, an MV2→MV3 converter, screenshot/tile tools, and competitor download/review lookups — that's all part of Extension Booster, which is the team behind these skills.
My honest take
I'm not going to pretend an AI agent ships a flawless extension while you sip coffee. You still own the architecture, the UX, and the judgment calls. But the soul-crushing parts — the permission archaeology, the MV3 trivia, the "which array does this go in," the Web Store rejection roulette — those are exactly the parts skills are built to absorb.
If you build Chrome extensions and you're using Claude Code, Cursor, Copilot, or any modern agent, spend the 10 seconds to install these. Worst case, you ignore them. Best case, you get your weekends back.
What would you build if Chrome extensions were finally easy? Drop it in the comments — I'm genuinely curious. 👇
Already tried agent skills for another stack? I'd love to hear which ones actually earned a permanent spot in your setup.
Top comments (0)