القائمة
Chrome Extension Manifest V3 development specialist covering service workers, content scripts, message passing, chrome.* APIs, side panel, declarativeNetRequest, and Chrome Web Store publishing. Use when building browser extensions.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | moai-platform-chrome-extension |
| description | Chrome Extension Manifest V3 development specialist covering service workers, content scripts, message passing, chrome.* APIs, side panel, declarativeNetRequest, and Chrome Web Store publishing. Use when building browser extensions. |
| license | Apache-2.0 |
| compatibility | Designed for Claude Code |
| allowed-tools | Read, Grep, Glob, Bash(npm:*), Bash(npx:*), Bash(node:*), WebFetch, WebSearch, mcp__context7__resolve-library-id, mcp__context7__get-library-docs |
| user-invocable | false |
| metadata | {"version":"1.0.0","category":"platform","status":"active","updated":"2026-02-01","modularized":"true","tags":"chrome-extension, manifest-v3, service-worker, content-script, messaging, chrome-api, browser-extension, web-store, side-panel, declarative-net-request","context7-libraries":"/nicedoc/chrome-extension-doc","related-skills":"moai-lang-typescript, moai-lang-javascript, moai-domain-frontend","aliases":"chrome-ext, browser-extension, crx"} |
| progressive_disclosure | {"enabled":true,"level1_tokens":120,"level2_tokens":8000} |
| triggers | {"keywords":["chrome extension","manifest v3","service worker","content script","chrome api","browser extension","popup","side panel","background script","web store","declarativeNetRequest","chrome.runtime","chrome.tabs","chrome.storage","chrome.scripting","chrome.action","manifest.json","crx"],"agents":["expert-frontend","expert-backend"],"phases":["plan","run"]} |
Chrome Extension Manifest V3 Development Specialist enables building modern browser extensions with the latest Chrome platform APIs.
Auto-Triggers: Chrome extension projects detected via manifest.json with manifest_version 3, service worker files, content script declarations, chrome API usage patterns
Manifest V3 Platform:
Process Architecture:
Communication Patterns:
Security Model:
For latest Chrome Extension API documentation, use the Context7 MCP tools:
Step 1 - Resolve library ID: Use mcp__context7__resolve-library-id with query "chrome extension" to get the Context7-compatible library ID.
Step 2 - Fetch documentation: Use mcp__context7__get-library-docs with the resolved library ID, specifying topic and token allocation.
Example topics include "manifest v3 configuration", "service worker lifecycle", "content scripts injection", "message passing patterns", "chrome.storage API", "side panel API", and "declarativeNetRequest rules".
This skill uses progressive disclosure with specialized modules for detailed implementation patterns.
manifest-v3-reference covers the complete manifest.json field reference for Manifest V3 extensions. Topics include required and optional fields, field types and constraints, permission declarations, MV2 to MV3 migration notes, and extension configuration best practices.
service-worker-patterns covers service worker lifecycle, event registration, state management, and debugging. Topics include event-driven architecture, top-level listener registration, state persistence with chrome.storage, keep-alive strategies, offscreen documents for DOM access, and debugging with chrome://extensions.
content-scripts-guide covers content script injection methods, isolated worlds, and communication. Topics include static declaration in manifest, dynamic registration with chrome.scripting, programmatic injection, isolated world architecture, DOM access patterns, and security considerations.
messaging-patterns covers message passing between extension components. Topics include one-time messages with sendMessage, long-lived connections with connect and ports, async response patterns, cross-extension messaging, web page messaging, and error handling strategies.
apis-quick-reference covers the major chrome.* APIs with method signatures and permission requirements. Topics include chrome.runtime, chrome.tabs, chrome.storage, chrome.action, chrome.scripting, chrome.alarms, chrome.notifications, chrome.contextMenus, chrome.sidePanel, chrome.declarativeNetRequest, chrome.offscreen, chrome.identity, and chrome.commands.
ui-components covers popup, side panel, options page, DevTools panel, and content script UI. Topics include popup HTML and lifecycle, side panel configuration and API, options page patterns, DevTools extension integration, and injected UI from content scripts.
security-csp covers Content Security Policy, permissions model, and secure coding practices. Topics include CSP configuration for extension pages, minimum privilege permissions, input validation, XSS prevention, secure messaging patterns, and HTTPS enforcement.
publishing-guide covers Chrome Web Store submission and distribution. Topics include developer account setup, extension packaging, privacy policy requirements, review process, update mechanisms, and self-hosted distribution.
Every Chrome extension requires a manifest.json file at the project root. Three fields are mandatory: manifest_version set to integer 3, name as the extension display name with maximum 75 characters, and version as a semver-compatible string.
The description field provides a summary shown in Chrome Web Store with maximum 132 characters. The icons object specifies PNG icons at 16, 32, 48, and 128 pixel sizes for various Chrome UI contexts.
For background processing, declare a service_worker field inside the background object as a single string path pointing to the service worker file. Set type to module when using ES module imports. The service worker path must be a single string, not an array.
Content scripts are declared as an array of objects, each specifying matches patterns for URL matching, js array for JavaScript files, optional css array for stylesheets, and run_at to control injection timing with values document_start, document_end, or document_idle.
For detailed field reference and migration guidance, see modules/manifest-v3-reference.md.
Service workers in Manifest V3 replace persistent background pages with an event-driven model. The service worker runs only when responding to events and terminates when idle, reducing memory and CPU consumption.
All event listeners must be registered at the top level of the service worker script. Listeners registered inside callbacks, promises, or async functions will not persist across service worker restarts.
Since service workers have no DOM access, no window object, and no localStorage, use chrome.storage API for persistent state. Use the Alarms API for scheduled tasks instead of setTimeout or setInterval, as these timers do not survive service worker termination. Use fetch for network requests instead of XMLHttpRequest.
For long-running operations that require DOM access, use the Offscreen Documents API via chrome.offscreen.createDocument to create a hidden document with DOM capabilities.
For complete service worker patterns and debugging guidance, see modules/service-worker-patterns.md.
Content scripts execute JavaScript and CSS in the context of web pages. They run in isolated worlds, meaning they share DOM access with the host page but have separate JavaScript execution environments, preventing variable and function conflicts.
Three injection methods exist. Static injection declares scripts in the manifest content_scripts array with URL match patterns. Dynamic injection uses chrome.scripting.registerContentScripts for runtime registration. Programmatic injection uses chrome.scripting.executeScript to inject on demand, requiring either host_permissions or activeTab permission.
Content scripts have limited direct chrome API access: only dom, i18n, storage, and specific runtime methods including connect, sendMessage, onMessage, onConnect, getManifest, getURL, and id. All other API calls must go through message passing to the service worker.
For injection patterns, isolated world details, and security considerations, see modules/content-scripts-guide.md.
Extensions communicate between components using Chrome message passing. One-time messages use chrome.runtime.sendMessage to reach the service worker and chrome.tabs.sendMessage to reach content scripts. Each message receives a single response through a callback or Promise.
Long-lived connections use chrome.runtime.connect or chrome.tabs.connect to establish ports. Ports remain open until either side calls disconnect, a listener is removed, or the containing tab unloads. Ports support ongoing bidirectional communication.
For async responses in one-time messaging, the onMessage listener must either return true to indicate an async sendResponse call, or return a Promise directly starting from Chrome 144.
All messages use JSON serialization with a maximum size of 64 MiB. Never trust message content from content scripts as the host page context could be compromised.
For complete messaging patterns including cross-extension and web page communication, see modules/messaging-patterns.md.
The chrome.runtime API provides extension lifecycle management, messaging, and manifest access. It handles installation, update, and suspend events, and provides methods for getting extension URLs and platform information.
The chrome.tabs API manages browser tabs with methods for querying, creating, updating, and removing tabs. The chrome.storage API provides three storage areas: local with 10 MB capacity, sync with 100 KB that synchronizes across signed-in devices, and session for in-memory storage that clears on browser restart.
The chrome.action API controls the toolbar button including badge text, icon, popup, and click handlers. The chrome.scripting API provides programmatic script and CSS injection into web pages.
The chrome.sidePanel API manages the extension side panel, a persistent UI surface alongside web content. The chrome.declarativeNetRequest API provides network request filtering using static and dynamic rules without blocking webRequest.
For complete API method signatures and permission requirements, see modules/apis-quick-reference.md.
Extensions support multiple UI surfaces. The popup is configured via action.default_popup in the manifest and displays as a standard HTML page when the toolbar button is clicked. Popups close when they lose focus and should load quickly.
The side panel is configured via side_panel.default_path in the manifest and provides a persistent panel alongside web content. The chrome.sidePanel API controls panel behavior, enabling per-tab or global panels.
The options page is configured via options_ui.page in the manifest and opens within chrome://extensions for extension settings. The DevTools panel extends Chrome Developer Tools using the devtools_page manifest field.
Content scripts can inject UI elements directly into web pages using DOM manipulation, applying custom CSS for styling.
For detailed UI implementation patterns, see modules/ui-components.md.
Permissions fall into four categories. Standard permissions declare API access requirements such as storage, tabs, activeTab, contextMenus, notifications, scripting, alarms, sidePanel, declarativeNetRequest, identity, and offscreen. These are granted at install time.
Host permissions specify URL patterns for web page access using patterns like https://.example.com/. Optional permissions and optional host permissions allow runtime requests through chrome.permissions.request, reducing the install-time permission prompt.
Prefer activeTab over broad host permissions to minimize permission warnings. Request only the minimum permissions necessary for extension functionality.
For detailed permission strategies and security guidance, see modules/security-csp.md.
The Content Security Policy for Manifest V3 restricts script-src to self and wasm-unsafe-eval only. Inline scripts, eval, and remote code loading are prohibited. All JavaScript must be bundled within the extension package.
Content scripts run in isolated worlds but should be treated as potentially compromised since the host page can manipulate the shared DOM. Always validate and sanitize data received from content scripts in the service worker. Never use eval, document.write, or innerHTML with untrusted data. Use HTTPS for all external network requests.
For comprehensive security patterns and CSP configuration, see modules/security-csp.md.
For detailed implementation guidance on advanced topics, see the modules directory:
Manifest V3 Migration:
Complex Service Worker Patterns:
Advanced Content Script Patterns:
Cross-Context Communication:
Storage Synchronization:
Common Issues and Solutions:
Service Worker Not Registering:
Verify the background.service_worker field in manifest.json is a single string path, not an array. Ensure the service worker file exists at the declared path. Check chrome://extensions for error messages on the extension card. Inspect the service worker console by clicking the service worker link on the extension details page.
Content Script Not Injecting:
Confirm the matches patterns in manifest.json correctly target the desired URLs. Verify run_at timing is appropriate for the page content being accessed. Check that the extension has the necessary host permissions. Inspect the target page console for content script errors.
Message Passing Failures:
Ensure channel names and message structures match between sender and receiver. Verify the receiving listener is registered before messages are sent. Check that sendResponse is called before the listener returns, or return true for async responses. Verify the target tab exists when using chrome.tabs.sendMessage.
Permission Denied Errors:
Confirm all required permissions are declared in manifest.json. For programmatic injection, verify either host_permissions or activeTab permission is granted. Check chrome://extensions for any permission warnings or disabled states. Use chrome.permissions.contains to verify runtime permissions.
Extension Not Appearing in Chrome Web Store:
Ensure manifest.json passes validation with no errors. Verify all declared resources including icons, HTML files, and scripts exist in the package. Check that the description does not exceed 132 characters. Review the developer dashboard for submission errors.
Debug Commands:
Open chrome://extensions to view all installed extensions and their status. Enable developer mode to access extension details and error logs. Click the service worker link to open its dedicated DevTools console. Use chrome://inspect to debug content scripts in page context.
For detailed implementation patterns, see the modules directory:
For latest documentation, use Context7 to query:
For official Chrome documentation, use WebFetch with:
Status: Production Ready Generated with: MoAI-ADK Skill Factory v1.0 Last Updated: 2026-02-01 Version: 1.0.0 (Initial Release) Coverage: Manifest V3, Service Workers, Content Scripts, Messaging, Chrome APIs, UI, Security, Publishing
| Rationalization | Reality |
|---|---|
| "I will request broad permissions and narrow them later" | Users see permissions at install time. Broad permissions deter installation and may trigger Chrome Web Store rejection. |
| "Content scripts can access everything on the page, so security is the page's problem" | Content scripts run in the user's context. Injecting untrusted content via a content script is an XSS vector in the extension. |
| "Manifest V2 still works, I do not need to migrate" | Chrome Web Store no longer accepts MV2 submissions. MV2 extensions will be disabled in future Chrome releases. |
| "Service workers are the same as background pages" | Service workers are event-driven and terminate when idle. Persistent state must use chrome.storage, not global variables. |
| "I will add CSP later, it is just a security header" | Missing CSP in manifest.json allows inline scripts and eval(), which are the primary extension exploit vectors. |
<all_urls> or *://*/* host permission without justificationIntent-First design craft specialist covering design direction, domain vocabulary, design memory, and post-build critique. Use when establishing design intent or auditing code against design principles.
Design tool integration specialist covering Figma MCP, Pencil renderer, and Pencil-to-code export. Use when fetching design context from Figma, rendering Pencil designs, or exporting to React/Tailwind code.
Documentation generation patterns for technical specs, API docs, user guides, and knowledge bases using real tools like Sphinx, MkDocs, TypeDoc, and Nextra. Use when creating docs from code, building doc sites, or automating documentation workflows.
Backend development specialist covering API design, database integration, microservices architecture, and modern backend patterns. Use when designing APIs, implementing server logic, authentication, or authorization.
Brand-aligned visual design system specialist for web projects. Enforces hero-first layout chaining, WCAG 2.1 AA accessibility, Lighthouse >= 80, and design token extraction from brand identity files. Covers color palettes, typography, spacing, and component specifications.
Brand-aligned copywriting specialist for marketing and product text. Enforces brand voice, anti-AI-slop rules, concrete numbers, and JSON section structure for downstream agent consumption. Covers hero, features, social_proof, cta, and footer sections with A/B variant output.