Claude Prompt to Build Framework-Agnostic Web Components

What this prompt does

This prompt builds a production-ready Web Component named [component_name] that works across [target_frameworks] with no framework dependencies. It walks the full Custom Element lifecycle (constructor, connectedCallback, disconnectedCallback, attributeChangedCallback, adoptedCallback), sets up a Shadow DOM in [shadow_mode] mode, defines the component's API, adds accessibility, dispatches custom events, optionally makes it form-associated, and registers it as a CDN-ready ES module. The lifecycle-first approach is what makes the element behave the same wherever it is dropped in.

The variables define the component's surface. [observed_attributes] and [attribute_count] set which attributes react via attribute-property reflection, while [css_parts] exposes ::part() styling hooks and [slot_count] enables content projection through named slots. [keyboard_interactions] and [aria_pattern] drive WAI-ARIA-compliant accessibility with proper roles and focus management, [custom_events] are dispatched with composed: true so they cross the Shadow DOM boundary and parent frameworks can listen, and [form_associated] decides whether the element participates in native forms with validity and state-restoration reporting. Getting these right is what makes one component behave identically across every framework that consumes it.

When to use it

• Building a widget that must work identically in React, Vue, Angular, and plain HTML.
• Shipping an embeddable component to third parties who use unknown frameworks.
• Needing strong style isolation via Shadow DOM so host-page CSS cannot leak in.
• Exposing controlled styling hooks through ::part() instead of leaking internals.
• Creating a form-associated element that reports value and validity to native forms.
• Distributing a component as a CDN-ready ES module that auto-registers on import.

Example output

You get a complete component implementation: a class extends HTMLElement with every lifecycle callback wired up, Shadow DOM in [shadow_mode] mode, [attribute_count] observed attributes implementing attribute-property reflection with JSON parsing for complex data, a template exposing [css_parts] parts and [slot_count] named slots, keyboard handling for [keyboard_interactions] following the [aria_pattern] pattern, [custom_events] dispatched with composed: true and bubbles: true, optional form-association code, and a customElements.define() registration plus a deferred-registration export.

Pro tips

• Use a hyphenated [component_name]; custom element names must contain a dash or registration fails silently.
• Default [shadow_mode] to open unless you have a strong reason; closed mode blocks legitimate external access and testing.
• Keep [observed_attributes] minimal and reflect only what genuinely drives rendering to avoid reflection loops.
• Expose styling through [css_parts] rather than letting consumers reach into the shadow tree, which keeps the API stable.
• Set composed: true on every event in [custom_events]; without it, events stop at the Shadow DOM boundary and parent frameworks never see them.
• Only set [form_associated] to yes when you actually need form participation; it adds real complexity around validity and state restoration.
• Ship both an auto-registering ES module and a deferred-registration export, so consumers who need to control customElements.define() timing can.