What problem does it solve? Building a Manifest V3 extension that ships to both Chromium and Firefox from one codebase involves platform constraints that are expensive to rediscover by trial: who can open the side panel versus the sidebar, how content-script injection differs on Firefox for Android, and how to keep one view implementation across multiple hosts. This Skill encodes those hard-won platform truths and the framing questions to settle before writing any extension UI code. ## Core Features & Use Cases - Surface decision framing: Five scoping questions to answer before building any UI surface (HUD, popup, side panel, drawer), enforcing consistency across entry points and a stay-in-the-reading-page principle. - Platform truth table: Documents exact gesture and messaging rules for chrome.sidePanel.open versus sidebarAction.open, activeTab-first injection on Chromium, and static content_scripts on Firefox including GeckoView/Android limitations. - One-impl-N-hosts pattern: Reuses single view builders (mountReview, mountStats, mountSettings) across the side panel and in-page drawer, with closed shadow DOM, design tokens, and double-init guards. - Use Case: Before adding a stats view that opens from both the in-page HUD and the toolbar popup, consult this Skill to learn that Firefox requires the in-page drawer while Chromium can use the Side Panel, then reuse the existing mountStats builder in both hosts. ## Quick Start Ask the assistant to apply the browser-extension-architecture rules before building a new popup, side panel, or in-page drawer surface in the extension.