Three-Tier Shell Navigation Prompt

What this is

A working prompt that asks an LLM (Cursor, Copilot, v0, Lovable, anything that codes) to scaffold the three-tier shell most enterprise apps end up with: a thin app-level rail, a section-level collapsible nav, a top bar, and a content area — plus the mobile overlay transformation. Paste it as-is or tune the values inline.

The reason this exists as a prompt and not a component library: every team ends up with their own tokens, their own router, their own component primitives. What’s reusable is the structure — the layout regions, the breakpoint behavior, and the mobile collapse rules. Hand the LLM the structure; let it adapt to your stack.

When to use it

• You’re starting a new prototype and want the shell out of the way in an hour
• You’re inheriting an app without a shell and want a clean baseline
• You’re moving from a single-pane layout to a sectioned app and need the bones
• You want a fluency test for an AI coding tool — this prompt exercises layout, state, hooks, responsive, and accessibility in one shot

The prompt

Copy from here. Adjust the bold values in the first section to match your project. Leave the structural rules alone unless you have a reason.

You are scaffolding the application shell for a multi-page enterprise
web app. Use the following stack and conventions.

STACK
- Framework: <React 19 + TypeScript + Vite | Next.js App Router | etc.>
- Routing: <React Router 7 | Next.js routing | TanStack Router>
- Component library: <component library of choice>
- Styling: <CSS-in-JS | CSS Modules | Tailwind>
- Icons: <icon set of choice>

LAYOUT REGIONS

The shell is composed of four regions, stacked as follows:

  +----------------------------------------------------------+
  |  TopBar     (full width, fixed height ~48px)             |
  +-----+----------------+-----------------------------------+
  |     |                |                                   |
  | App | Section nav    | Main content                      |
  | rail| (collapsible)  | (rounded card, scrollable)        |
  |     |                |                                   |
  +-----+----------------+-----------------------------------+

- App rail (L1): fixed ~68px wide. Holds app-level destinations.
- Section nav (L2): 240px expanded / 48px collapsed. Holds the nav
  for the currently active L1 app. Collapsible via a hamburger.
- TopBar: 48px. Holds brand mark on the left, icon actions on the
  right.
- Main: fills the remaining space. Content sits on a rounded card
  with the top corners rounded.

BREAKPOINT BEHAVIOR

There is exactly ONE structural breakpoint at 900px.

- Above 900px: all three navigation regions visible. Section nav
  can be toggled between 240px expanded and 48px collapsed by the
  user via a hamburger.
- Below 900px:
  - Section nav is display: none.
  - A hamburger is rendered inside the main content card.
  - Clicking the hamburger opens an overlay panel using
    position: absolute, z-index above content, sliding in from
    under the app rail (left offset = app rail width).
  - The overlay panel reuses the same nav-item rendering as the
    desktop section nav.
  - A semi-transparent backdrop sits behind the overlay panel.
  - Clicking the backdrop, selecting a nav item, or pressing
    Escape closes the overlay.

A single resize listener auto-collapses the section nav and closes
the overlay when the viewport crosses 900px in either direction.

ACCESSIBILITY (NON-NEGOTIABLE)

- Skip-to-content link is the first tabbable element. Visually
  hidden until focused. Target: an element with id="main-content".
- <main id="main-content" tabIndex={-1}> exactly once in the tree.
- The overlay panel is role="dialog", aria-modal="true", with an
  aria-label such as "Section navigation".
- Hamburger buttons carry an aria-label ("Open navigation",
  "Close navigation").
- Focus moves into the overlay panel when it opens and returns to
  the hamburger trigger on close.
- Escape closes the overlay.
- All horizontal scroll at the page level is prevented:
  overflow-x: hidden on both the outer wrapper and the main
  content container. (Data tables may scroll horizontally WITHIN
  their own container.)

OUTPUT

Generate the following files. Use the stack listed above; do not
mix in other libraries.

1. The shell component as a single file, including the layout,
   the resize listener, the mobile overlay, and the skip link.
2. The app rail as its own component.
3. The section nav as its own component, with an exported version
   of its nav-item list suitable for reuse inside the mobile
   overlay. Do not duplicate the nav-item rendering.
4. The top bar as its own component.
5. A short README describing the breakpoint behavior, the four
   regions, and how to add a new top-level destination.

Each component should be self-contained and runnable with the
stack listed above.

End of prompt. Paste, adjust the bracketed values, run.

What you should expect from a good output

• One structural breakpoint, not five
• A single resize listener, not one per region
• The mobile overlay reuses the section-nav’s nav-item rendering — no duplicated list
• Skip link present and tabIndex working
• overflow-x: hidden on the outer wrapper and main
• Hamburger has an aria-label and Escape closes the overlay

If the output skips the skip link, hardcodes a second breakpoint, or duplicates the nav-item rendering, send back this follow-up:

You skipped one or more of the non-negotiables:

- skip-to-content link as the first tabbable element
- single 900px structural breakpoint (no others)
- mobile overlay reuses the same nav-item rendering, no duplicate list
- overflow-x: hidden on outer wrapper AND main
- overlay has role="dialog", aria-modal, Escape handler, focus restore

List which ones are missing and fix only those. Do not rewrite
anything else.

Why the prompt looks like this

• Stack section first. LLMs hallucinate the wrong library if you bury the stack mid-prompt.
• ASCII layout. A diagram in monospace beats prose for spatial layout — the model lays it out the same way.
• One breakpoint stated explicitly. Otherwise you get four.
• A11y as “NON-NEGOTIABLE.” Models reliably skip a11y when it’s stated as preference. Stating it as a constraint costs nothing and changes the output.
• The follow-up prompt. Pre-writing the “fix only the misses” reply is what separates a working prompt from a half-working one.

Companion playbooks

This prompt produces the shell. To make it feel like a real app:

• The Enterprise Reflow Playbook for the breakpoint and breadcrumb behavior the section nav doesn’t cover
• The Sticky View State Playbook for keeping section state across navigation
• The Accessibility Compliance Baseline Playbook for everything the skip link and live region don’t reach

---

Public-safe review (verified before publish)

• No employer or client product names, codenames, or org names
• No customer or segment data
• No real route paths, package names, or component names
• No real brand hex values or class hashes
• All structural decisions stated generically and would apply to any enterprise app shell
• A peer outside any employer could read this and learn nothing proprietary