Skills / Browser extension
Browser extension
Build a small browser extension for their own browsing problem. Manifest, content script, storage, loaded unpacked and used in their daily browser. Use when they complain about a website's behavior, want to change how a page looks or works, or ask "how are extensions made".
Use this skill. Nothing to install.
Don't have an agent? · Raw file: skills/browser-extension.md
Watch the first two minutes
This is how a session goes, including the part everyone is afraid of. Click through it.
Scripted example of a real session.
Don't extensions need the Chrome Web Store's approval?
Only published ones. Yours loads unpacked in developer mode and runs in your daily browser from day one; the store, its developer fee, and its review queue never enter the picture. Success is measured a week later, when the extension is still installed because it earns its place on a site you actually use. If you later decide to publish, that's its own project with its own rules, and the extension is complete either way.
What you end up with
A folder in a repo that changes a page you visit every day. Here is the whole skeleton for the recipe fix, and it barely grows from here.
{
"manifest_version": 3,
"name": "Recipe First",
"version": "1.0",
"content_scripts": [{
"matches": ["*://recipes.example.com/*"],
"js": ["content.js"]
}],
"icons": { "128": "icon.png" }
}
const card = document.querySelector(".recipe-card");
if (card) {
card.scrollIntoView();
document.querySelectorAll(".life-story, .ad-slot")
.forEach((el) => el.remove());
}
// no .recipe-card (logged out, index page):
// do nothing, never break the site
matches recipes.example.com only: the extension has no reason to see any other site, so it can't.
- The match pattern is the security story. One site, argued for in the
README.
<all_urls>never goes in without a fight. - The quiet failure is deliberate. On pages where the markup differs, the script checks and does nothing. Tested on three real pages of the site, plus logged out.
- This is the whole codebase. A manifest, a content script, an icon. Every line is yours to read, which is why it stays fixable when the site changes.
Questions people actually ask
Do I need to publish to the Chrome Web Store?
No. The extension loads unpacked in developer mode and works in your daily browser indefinitely. Store submission is a separate decision with its own review process, out of scope for this session and unnecessary for a tool you built for yourself.
Can my extension see my passwords and other sites?
Only what its permissions grant, which is why the skill fights for narrow ones. A content script matched to one site sees that site's pages and nothing else. Every permission in your manifest gets a one-line justification in the README, so the answer is auditable.
Will it break when the site updates?
Eventually, and that's manageable: the script checks for its selectors before acting and fails quietly when they're missing, so the site keeps working even when the extension doesn't. Then you update one selector, reload, done.
Does this work in Firefox or Edge?
Edge and other Chromium browsers load the same unpacked folder. Firefox supports Manifest V3 with small differences, and the agent can walk you through them if Firefox is your daily browser. The skill targets whatever browser you actually use.
Is changing a website's pages even allowed?
Restyling and hiding things in your own browser is yours to do. The line the skill holds is about actions: anything that automates clicks on someone else's site stays within that site's terms and your own account.
Where to go from here
Ship it, then feed it:
An extension for an annoyance you can name
Ship on GitHub: give it a repo
Use an API: pull in outside data
Ideas to use it on
- A browser extension for an annoyance you can name — There is a site you use every day with one thing that drives you up the wall: autoplaying videos, a hidden per-unit price, a sidebar that eats half the screen, a timer the page does not show.
Curious? Read the full skill — the exact instructions your agent gets
--- name: browser-extension category: code description: Build a small browser extension for their own browsing problem. Manifest, content script, storage, loaded unpacked and used in their daily browser. Use when they complain about a website's behavior, want to change how a page looks or works, or ask "how are extensions made". --- # browser-extension Build a browser extension with someone, aimed at a genuine irritation in their own browsing: a site element they always hide, a word count they always want, a page they visit daily that is missing one thing. Success is measured a week later, when the extension is still installed because it earns its place. ## Ground rules - The problem comes from their actual browsing. Ask what annoys them on sites they use every day, or what they repeatedly do by hand on a page. Blockers of specific clutter, small overlays of extra info, auto-fillers of tedious forms on their own accounts, restylers of a site they read a lot: all good first extensions. - Manifest V3, plain JavaScript, no build step, no framework. An extension is a folder with a manifest.json and a couple of scripts; keep it exactly that legible. - Narrow permissions, argued for one at a time. Match only the site it needs (`*://example.com/*`; require a documented reason before `<all_urls>`), and each permission in the manifest gets a one-line justification as a comment in the README. This is the security habit worth more than the extension. - Loaded unpacked in their own browser, in developer mode. No store submission in this session; publishing is a separate decision with its own review process, and the extension is complete without it. - Respect the sites it touches. Read and restyle freely; anything that automates actions on someone else's site stays within that site's terms and their own account. ## The path 1. Name the irritation precisely: which site, which page, what should be different. Open dev tools together and find the selectors for the elements involved; that inspection is half the build. 2. Skeleton loads: manifest.json with name, version, and the matched site, one content script that logs a line. Load it unpacked, see the log on the target page, and now every later change is a reload away. 3. The core behavior: hide, inject, restyle, or compute whatever the irritation demands. Test on three real pages of the site, not one. 4. State where needed: an options toggle or remembered preference in `chrome.storage`, so their choice survives a browser restart. 5. Fit and finish: an icon (any 128px image of theirs), a sensible name, and behavior checked when the site's markup differs (logged out, empty page) so it fails quietly instead of breaking the site. 6. Live with it: they browse normally for the rest of the session with the extension on, and anything that annoys them about their own tool gets fixed on the spot. ## Done - An extension folder in a repo: manifest, content script, icon - Loaded unpacked in their daily browser and doing its job on the real site - Permissions minimal, each justified in the README - A preference that survives restart, if the extension has one - They can explain what a content script can and cannot see Then: ship-on-github for the repo if it lacks one, or use-an-api if the extension should pull in outside data.