Adapt one Component across configured screen widths without creating separate Components. Build the base structure first, add only meaningful screen-specific overrides, then verify the Component inside realistic parent widths and inspect its exported container queries.
Coverage: UI + MCP.
Responsive screens are views of the same Component hierarchy. They can supply per-screen style and screen data, while the Component's Body and child identities remain shared.
This differs from variants:
a screen responds to container size;
a Component variant is a named choice supplied by a consumer;
a per-node style variant represents a selected or state-driven visual layer;
hover, focus, and active are interaction states.
Use a screen only for a size-driven difference.
Open the Component and select its default screen.
Make the base hierarchy and intrinsic sizing work without a screen-specific patch.
Identify an actual threshold where the layout needs to change.
Add or select the responsive screen representing that range.
Change only the properties that must differ: direction, gap, padding, alignment, sizing, visibility, typography, or another supported value.
Repeat for additional screens only when they solve a distinct layout problem.
Keeping most properties on the base layer makes the Component easier to reason about and reduces contradictory overrides.
Generated responsive behavior is container-oriented. A Component can look correct in an isolated frame but select a different screen when placed inside a narrow column, grid, drawer, or nested layout.
Verify:
just below and above every authored boundary;
the narrowest and widest expected parent sizes;
long text, missing content, and representative variants;
both isolated Preview and at least one real parent instance;
the generated container-query conditions and screen-specific classes.
In the
Websiteproject, inspect<component reference>, its current screens, base styles, and generated output. Preserve the shared hierarchy. At the existing<screen>only, change<specific responsive differences>and leave every other property inherited from base. Show the resolved base and screen layers, capture Preview screenshots immediately below and above the boundary, inspect the generated container query, and stop. Do not create a duplicate Component or convert the screen difference into a variant.
MCP screen tools discover and manage screens; style operations accept the relevant screen context. The agent should read current screens and use returned screen IDs rather than inferring a breakpoint from a display name.
Screen and per-screen style edits enter the design file's content history. UI and MCP share that history. Verify which screen layer changed before undoing one step.
Deleting a screen can remove several overrides at once. Read the current screen list and affected style layers before authorizing deletion.
A responsive screen does not create a separate hierarchy or Component API.
Hidden and skipped are different states; verify whether content should remain in runtime layout or be omitted.
Container-query behavior depends on the consuming layout and cannot be proven by one full-window screenshot.
Timelines can store a Separate screen mode, but current generated element animation targets are not scoped to the corresponding container-query breakpoint. Treat per-screen animation export as unfinished.