- Home
- Skills
- Xenitv1
- Claude Code Maestro
- Browser Extension
browser-extension_skill
- JavaScript
202
GitHub Stars
1
Bundled Files
2 months ago
Catalog Refreshed
4 months ago
First Indexed
Readme & install
Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.
Installation
Preview and clipboard use veilstrat where the catalogue uses aiagentskills.
npx veilstrat add skill xenitv1/claude-code-maestro --skill browser-extension- SKILL.md4.6 KB
Overview
This skill is a masterclass for building production-ready browser extensions in 2025/2026, centered on Manifest V3, reliable Service Worker patterns, Side Panel API, and cross-browser compatibility. It enforces a persistence-first mindset so extensions remain robust despite service worker termination and strict platform security. The guidance combines concrete architecture rules, runtime persistence techniques, and an audit cycle for repeatable, secure builds.
How this skill works
The skill inspects extension manifests, background/service worker code, and runtime persistence to ensure no volatile in-memory state is relied upon. It validates MV3 constraints (no remote code, least-privilege permissions), implements Alarm-based heartbeats, and recommends Offscreen documents for DOM work or heavier tasks. It also enforces Side Panel integration and runs script-level audits for manifest, persistence, and assets before test runs.
When to use it
- When building any new Chrome-compatible extension that must be durable across service worker restarts.
- When migrating legacy MV2 extensions to Manifest V3 with correct persistence and security.
- When implementing background sync, scheduled work, or periodic tasks that must survive worker termination.
- When you need a non-intrusive UI using the Side Panel or need consistent cross-browser behavior.
Best practices
- Always use Manifest V3 with a service_worker background; never assume SW persistence—persist state immediately to chrome.storage or IndexedDB.
- Use chrome.alarms to wake the service worker every 1–5 minutes for sync/housekeeping; use offscreen documents for DOM parsing or heavy CPU work.
- Follow Principle of Least Privilege: request minimal runtime permissions and prefer optional_permissions when feasible.
- Sanitize all data from content scripts before sending to the service worker; treat content scripts as untrusted.
- Use declarativeNetRequest for request blocking/modification; fall back to webRequest only where Firefox requires it.
Example use cases
- A note-taking side panel that saves every edit to IndexedDB to prevent loss when the service worker sleeps.
- A cross-tab sync agent that uses chrome.alarms as a heartbeat and chrome.storage.session for transient auth tokens.
- An enterprise privacy extension that applies declarativeNetRequest rules and validates them through the manifest auditor.
- A background scraper that spawns an offscreen document for DOM parsing and stores results in chrome.storage.local.
FAQ
Persist every state change immediately to chrome.storage.local or IndexedDB; on activation, reload state from storage. Do not use globals.
How often should I schedule alarms?
Use a 1–5 minute window for regular heartbeats; adjust based on battery/network impact and only run expensive tasks when necessary.