What problem does it solve? Next.js App Router route groups (folders named (name)) affect layout and convention scope but not URLs, so teams often create them prematurely, name them inconsistently, or mix public and authenticated routes in ways that break layout-level auth enforcement. This Skill provides a decision framework for when a route group is justified, what to name it, and how to structure layouts across groups. ## Core Features & Use Cases - Three-condition gate: A new group requires a distinct shared layout, a distinct trust posture or rendering model, and at least two routes. - Trust-boundary convention: Groups routes by trust boundary and rendering model — (api|actions) for Server Actions and route handlers, (marketing) for public static pages, (app) for authenticated routes behind a layout auth gate. - Layout guidance: Rules for the root app/layout.tsx (html/body tags, global providers only) and options for sharing headers across sibling groups. - Use Case: When adding a new admin section to a Next.js app, use this Skill to decide whether it warrants an (admin) group with its own auth-checking layout or belongs inside the existing (app) group. ## Quick Start Ask the agent to decide where new routes in the app directory should live and whether a new route group is justified.
