Build a compound component that lets the consumer control markup, not just props

You are building a compound component — a family of subcomponents that share implicit state through context, so the consumer composes the markup directly while the state and behavior stay coordinated behind the scenes.

COMPONENT FAMILY
Tabs

SUBCOMPONENTS
Tabs.List, Tabs.Tab, Tabs.Panels, Tabs.Panel

SHARED STATE
Which tab is currently active, and whether the active tab was set by click versus keyboard arrow navigation.

CONSUMER CUSTOMIZATION NEEDS
Must be able to render tabs in any order, wrap an individual Tab in a custom badge component, and render panels lazily so an inactive panel is not mounted until first selected.

IMPLEMENTATION RULES
Create one context scoped exclusively to this component family — never reuse or extend an app-wide context for this — and provide it from the root component of the family, never from an individual subcomponent. Each subcomponent reads only the specific piece of the shared context it actually needs; do not have every subcomponent destructure the entire context value if only one field is relevant to it, since that couples subcomponents to internal shape changes they don't actually depend on. The consumer must be able to reorder, omit, or wrap individual subcomponents in their own markup without breaking the shared state — if a subcomponent's position or presence is hardcoded into the root component's own render logic instead of left to the consumer's JSX, that defeats the actual purpose of a compound component and should be flagged, not implemented that way. Throw a clear, descriptive error — not a silent undefined — if a subcomponent is rendered outside its required root component, so a consumer mistake fails loudly during development rather than producing a confusing runtime bug. Keep the context value stable across renders where possible — memoize the object passed to the provider so subcomponents that don't care about a particular state change don't re-render needlessly, especially since this is exactly the context re-render behavior that makes an unscoped, unmemoized context expensive at scale. Do not let this pattern quietly grow into project-wide global state — if a future feature needs data from outside this component family, that is a sign this state has outgrown the compound-component pattern and needs a different home, not a widened context. If the family needs to expose an imperative action to the consumer — programmatically opening a specific tab, or scrolling a specific accordion panel into view — prefer a controlled prop pattern (an activeTab plus onActiveTabChange pair the consumer can own) over reaching for useImperativeHandle and a ref, since a controlled prop keeps the family's state consistent with whatever the consumer's own state management expects, while an imperative ref-based API creates a second, parallel way to change the same state that can drift out of sync with the first.

OUTPUT FORMAT
1. The root component and its context provider, as real code.
2. Each subcomponent, showing exactly what slice of context it reads.
3. A usage example showing the consumer's actual JSX, demonstrating the customization named above.
4. The explicit error thrown for misuse, with its message text.