Elevation Layer Map
Decide once what covers what, so overlays stop appearing behind the page.
What it adds
A documented ordering of the app's overlay layers — sticky chrome, menus, popovers, dialogs, notifications — and the rules for how they interact.
What your agent is told to do
5
What your agent is told to do
5-
1
List every element in the app that can overlap something else: sticky headers, bottom navigation, drawers, dropdown menus, popovers, tooltips, dialogs, toasts, and the command palette. Order them by what must always win when two are on screen together.
-
2
Write down the interaction rules alongside the order, not just the order itself: which layers may open while another is open, which dismiss the layer below, and which trap focus. An ordering without those rules only fixes the paint, not the behaviour.
-
3
Handle nesting explicitly. A popover opened from inside a dialog must render above that dialog, and closing the dialog must close it, so nested overlays need to know the layer of their opener rather than assuming a global value.
-
4
Decide how each layer interacts with persistent navigation. A drawer that slides under a fixed sidebar and a toast that lands beneath the mobile tab bar are both the same unspecified overlap, and both need an answer written down.
-
5
The numeric values themselves belong to Z-Index Registry; this feature owns the ordering and the behaviour, that one owns the tokens and enforcement. Do not define a second set of numbers here.
Edge cases it handles
7
Edge cases it handles
7- Any ancestor with a transform, filter, opacity below one, or a containment property creates a local stacking context, and a child inside it cannot escape upward no matter how high its value goes. Those ancestors have to be found and either removed or the overlay rendered outside them.
- Nested overlays — a menu inside a popover inside a dialog — must stack in the order they were opened and unwind in reverse, or dismissing the outer one strands the inner one on screen with no way to close it.
- Persistent navigation is the most common collision. Toasts landing under a mobile tab bar, drawers sliding beneath a fixed sidebar, and sticky action bars fighting a cookie banner all need a stated winner for the edge they share.
- Overlays rendered into a portal at the end of the document leave the DOM order, so keyboard focus and screen reader order must be restored deliberately rather than left to the browser.
- Fullscreen modes, whether the app's own focus layout or the browser's native fullscreen, change what the top layer even is. Anything that must remain reachable in fullscreen has to be rendered inside the fullscreen element.
- Native top-layer elements such as dialogs and popovers ignore the ordering entirely and always paint above everything, which will surprise anyone assuming the map governs all layers.
- Two toasts and a dialog opening in the same frame must not race — the ordering has to be deterministic regardless of which mounted first.
Definition of done
8
Definition of done
8- There is a single written ordering covering every overlapping surface in the app.
- Each layer's rules state what it may open over, what it dismisses, and whether it traps focus.
- A popover opened from within a dialog renders above it and closes with it.
- No overlay is clipped or hidden by a local stacking context.
- Every collision with persistent navigation has a documented winner.
- Numeric values come from Z-Index Registry rather than being redefined here.
- The feature matches the existing design system.
- No existing functionality is broken.
Related features
Semantic Color Tokens
Semantic Color Tokens
Name colours by the job they do, so changing a theme is one edit rather than a sweep.
What it does
A vocabulary of role-named colour tokens — surface, text, border, accent, danger, success — that components reference instead of literal values.
How it works
- 1 Inventory every literal colour value in the codebase and group them by the job they are doing rather than by the shade they happen to be. Two different greys used as card backgrounds are one role; the same grey used as a background and as a border is two.
- 2 Define the role names once and map each role to a value per theme. A role may resolve to a light grey in one theme and a near-black in another; what must not change is which components reference it.
- 3 Stop shared components accepting raw colour values. A primitive that takes a hex string as a prop guarantees that some product screen will hardcode a colour the themes never learn about.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/semantic-color-tokens
Motion Token System
Motion Token System
Give the app one shared vocabulary of durations and easing curves instead of ad hoc numbers.
What it does
A named set of durations and easing curves, each tied to a category of motion, replacing the timing values scattered through the app's components.
How it works
- 1 Inventory every duration and easing value currently written into the app and group them by what they do: something entering, something leaving, something being emphasised, and something changing size or position.
- 2 Name a small set of durations — roughly instant, quick, standard, and deliberate — and a small set of curves, then map each motion category to a pairing. Four or five of each is enough for an entire product.
- 3 Give entrances and exits different treatment. Something arriving should decelerate into place; something leaving should accelerate away and take less time, because nobody wants to wait for a dismissal.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/motion-token-system
Container Width System
Container Width System
Give pages a few defined widths instead of a different max-width on every screen.
What it does
A small set of named page widths — narrow, standard, wide, and full-bleed — applied consistently across the app.
How it works
- 1 Measure the max-width used on every top-level page and group them. Settings forms, prose, dashboards, and data tables usually want three or four distinct widths between them, not the eleven the codebase currently has.
- 2 Pick each width from the content it holds. A reading column is bounded by comfortable line length, a settings form by field width, and a table by the number of columns that must stay visible.
- 3 Make horizontal page padding part of the container rather than something each page adds, so content never touches the viewport edge on a narrow screen even at the widest setting.
Copy the prompt
No account needed
Add this feature to my app:
https://addthisfeature.com/x/container-width-system
How it works
-
1
Copy the link
Grab the Markdown instruction URL for this feature.
-
2
Give it to your AI
Paste it into Claude Code, Cursor, v0, Lovable — whatever you build with.
-
3
It inspects, then implements
Your agent reads your existing app first, then adds the feature to fit it.
Works with your stack
These instructions are written to adapt. They tell the agent to detect your framework, match your existing design system, and reuse what you already have — rather than assuming a particular stack.
Need it tighter than that? Customize the feature and tell it exactly what you're running.