moai-platform-chrome-extension
The moai-platform-chrome-extension skill provides specialized guidance for developing Chrome extensions using Manifest V3, the latest extension platform standard. It covers service worker architecture, content script communication, security models, and declarative network filtering, with auto-detection of extension projects via manifest.json files and integration with Context7 documentation tools for current Chrome API references.
git clone --depth 1 https://github.com/modu-ai/moai-adk /tmp/moai-platform-chrome-extension && cp -r /tmp/moai-platform-chrome-extension/.moai/archive/skills/v2.16/moai-platform-chrome-extension ~/.claude/skills/moai-platform-chrome-extensionSKILL.md
# Chrome Extension Manifest V3 Development ## Quick Reference 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 ### Core Capabilities Manifest V3 Platform: - Service workers replace persistent background pages for event-driven architecture - Remote code execution removed for enhanced security - declarativeNetRequest replaces blocking webRequest for network filtering - Promise-based API methods across all chrome.* APIs - action API unifies browserAction and pageAction into single surface - Supported in Chrome 88 and later Process Architecture: - Service worker runs as single event-driven background script terminating when idle - Content scripts execute in web page context within isolated worlds - Popup and side panel provide dedicated UI surfaces - Options page provides extension settings interface - DevTools panel extends Chrome Developer Tools Communication Patterns: - One-time messages between service worker and content scripts via sendMessage - Long-lived connections via connect with port-based communication - Cross-extension messaging through externally_connectable declaration - Web page to extension messaging for verified origins Security Model: - Content Security Policy restricts script sources to self only - No inline scripts or remote code execution permitted - Permissions declare required API access at install time - Optional permissions allow runtime-requested access with user consent - Host permissions control web page access patterns ### Context7 Documentation Access 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". --- ## Module Index This skill uses progressive disclosure with specialized modules for detailed implementation patterns. ### Core Modules 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. --- ## Implementation Guide ### Manifest V3 Structure 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 Worker Architecture Service workers in Manifest V3 replace persistent background pages with an event-driv
Claude Code upstream change tracker -> moai-adk update plan + docs sync workflow (dev-only). Tracks new CC release notes, classifies changes by impact tier, cross-references official docs, generates update plan at .moai/research/ or .moai/specs/, and synchronizes docs-site 4-locale + README. NOT distributed to user projects.
GitHub Workflow - Manage issues and review PRs with Agent Teams (dev-only). NOT distributed to user projects.
MoAI-ADK production release via Enhanced GitHub Flow (CLAUDE.local.md §18). Creates release/vX.Y.Z branch, version bump, CHANGELOG (bilingual), PR to main, merge commit (NOT squash), then scripts/release.sh for tag + GoReleaser. Hotfix support via --hotfix flag. All git operations delegated to manager-git. Quality failures escalate to expert-debug. NOT distributed to user projects (dev-only).
Run the 7-phase /moai brain ideation workflow to convert ideas into validated proposals
Identify and safely remove dead code with test verification
Scan codebase and generate architecture documentation in codemaps/
Analyze test coverage, identify gaps, and generate missing tests
Hybrid design workflow — Claude Design import (path A) or code-based brand design (path B)