Browser Extension Builder

Problem it solves

Browser extension work often fails around practical engineering details: manifest.json permissions are too broad and trigger store friction; content scripts and background service workers blur responsibilities; fragile page selectors break quietly; user settings and state lack durable storage. This skill turns those constraints into a concrete architecture guide for building stable popup, content, background, and options surfaces.

How it works

It follows Manifest V3 (MV3) and maps a typical project layout: popup/ for interactive UI, content/content.js for page injection, background/service-worker.js for lifecycle-aware background logic, and options/ for configuration. It recommends durable state with chrome.storage.local or chrome.storage.sync, and wraps get and set in Promises so async reads and writes are easier to reason about. It also clarifies how permissions, content_scripts, and action relate: use activeTab only when the extension needs the current tab, introduce broader permissions only for cross-tab data, and keep the store publishing path in view. It calls out anti-patterns: avoid requesting every permission, avoid heavy blocking work in the worker, and avoid brittle selectors. Better defaults are optional permissions, alarms for scheduled tasks, stable selectors, and explicit error handling. Scope note: it targets browser extension architecture, not a full product backend, and cross-browser differences or store policies still need validation for your target platforms.