How I Build a Chrome Extension with AI, From Idea to the Web Store

AI has made the coding part of a Chrome extension much faster. What it has not done is turn one prompt into a published extension. Having shipped eight of them, the split is clearer to me than it was at the start: there is a part I can hand over, and a part that stays with me.

This is the order I work in, from the first idea to a listing on the Chrome Web Store. The tools I use are ChatGPT for shaping what to build and Claude Code for the implementation, with the project open in front of it.

The shape of it

name the annoyance
 ↓
cut the scope
 ↓
decide the structure
 ↓
have AI build it in pieces
 ↓
load it in Chrome and use it
 ↓
check permissions, network, storage
 ↓
prepare the store listing
 ↓
submit for review
 ↓
fix, then publish

Of those nine, AI does most of the fourth. The rest I either decide or check.

1. Say the annoyance in one sentence

The first task is not writing code. It is writing one sentence.

I want to collect selected passages from several web pages and copy them all at once at the end.

That sentence became Copy & Prep. Starting the other way round did not work:

I want to build a powerful extension for gathering information.

Asked like that, an AI will offer tags, cloud sync, AI summaries, accounts, history. None of those suggestions is wrong on its own. But every feature I did not ask for is one more thing I have to keep track of later. Defining the problem narrowly is the actual first job.

2. Decide what it will not do

Once the sentence is settled, I have the AI draft a spec. The half I pin down first is the right-hand column.

Writing the exclusions down means I do not have to settle them again every time the suggestion comes back around. Copy & Prep shipped as the left column and nothing more. It does tidy text, but it shows the before and after side by side before applying anything — I did not want a tool that quietly rewrites what you collected. The job that opening sentence was pointing at is written up in collecting text from several web pages and copying it at once.

3. Know the structure before you ask

Before saying "build me a Chrome extension," it helps to know which parts you need. Not in detail. This much is enough:

manifest.json
    ↓
content script ←→ web page
    ↓
popup / side panel
    ↓
background / service worker
    ↓
chrome.storage.local

Deciding where things belong up front is what lets you notice when the AI puts something somewhere else. I wrote about what each part actually does in How a Chrome Extension Works.

4. Do not ask for the whole thing at once

I break the build up:

1. Capture the selected text
2. Save it to storage
3. Show the list
4. Reorder
5. Copy everything out

Context windows have grown, but they are not unlimited. The longer a project runs, the more there is to carry: files, spec, earlier decisions, dependencies. Hand over a wide slice in one go and the individual edits can all work while the whole drifts out of shape.

What makes extensions suit this way of working is that the working set stays small. Few files, clear boundaries between the parts, usually no server. That keeps the whole thing within reach — for the AI, and for me.

5. Load it in Chrome early

Open chrome://extensions, turn on Developer mode, and use Load unpacked to point at the folder.

I do this well before anything is finished, then keep doing it.

build a little → try it in Chrome → notice what feels off → have AI fix it

The problems that surface here do not show up in a code review. Where the button sits. How long the confirmation takes to appear. How tiring the flow gets on the fifth repetition. All of it behaves correctly, so nothing fails.

6. Working and publishable are not the same thing

This is the part I most wanted to write down. The fact that an AI produced working code is not a reason to keep its design. Once a piece is done, I read through:

• permissions — anything in there that is no longer used
• host_permissions — wider than what the feature needs
• Any network calls that appeared
• What gets stored, and where
• How much of the page is being read
• How far the code reaches into input fields
• Libraries that came along and stayed

Permissions are not an implementation detail. They are shown to the user, in their own words, at the moment of installing. I looked at what that screen actually says in Reading Chrome Extension Permissions. From the building side, that wording is the plain-language summary of your design.

7. Passing tests is not the same as being usable

I check the ordinary path, no data, a lot of data, navigating away, restarting the browser, changing settings, and permissions being denied. Playwright is useful here.

But a green test run says nothing about whether the thing is pleasant to use. That part I have to do by hand.

8. Then the non-code work starts

What the store asks for is not code:

a name, an icon, screenshots, a short description, a detailed description, a privacy declaration, a justification for each permission, a website, a support page.

AI helps a lot with the writing and the assets. The constraint is that the declaration has to match the implementation. Left entirely to the AI, the copy comes out slightly broader and slightly more accommodating than what the code does. So the declaration is the one thing I check line by line against manifest.json.

Description writing can also get you rejected. Mine was: a keyword-heavy listing came back as keyword spam. The code never changed. I rewrote the text and it went through.

9. Submitting

Build the ZIP, submit from the Developer Dashboard. What review cares about is not whether AI wrote it, but what the extension actually does. Being asked to change something is a normal outcome, not a failure.

The submission flow also contains decisions that have nothing to do with code. I got one of them wrong in the trader declaration, and my home address went up on the listing. An AI is not looking at that screen with you.

10. Publishing is not the end

After it goes live there is a different set of questions. Did anyone install it. Did they use it. Is anything broken. Did the description convey what it does. Then fix, and submit again.

AI lowered the cost of building. What is left over is now the heavier half: deciding what to build, deciding whether it should be published, and finding out whether anyone uses it.

AI does not build the extension for you. You define a small problem, and the two of you turn it into a tool over short cycles. So far that is the loop that has kept working.