epic-routing
Master file-based routing and navigation patterns within the Epic Stack ecosystem.
Install
mkdir -p .claude/skills/epic-routing && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4565" && unzip -o skill.zip -d .claude/skills/epic-routing && rm skill.zipInstalls to .claude/skills/epic-routing
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guide on routing with React Router and react-router-auto-routes for Epic StackKey capabilities
- →Implement file-based routing using react-router-auto-routes
- →Configure nested layouts via _layout.tsx files
- →Define resource routes for APIs and webhooks
- →Manage route parameters with $ syntax
- →Implement data loaders and actions for route logic
How it works
The skill utilizes react-router-auto-routes to map the file system to application routes. It enforces co-location of server utilities and UI components while using _layout.tsx for shared layout logic.
Inputs & outputs
When to use epic-routing
- →Create new pages or routes
- →Implement nested layouts
- →Configure resource routes
- →Handle route parameters and loaders
About this skill
Epic Stack: Routing
When to use this skill
Use this skill when you need to:
- Create new routes or pages in an Epic Stack application
- Implement nested layouts
- Configure resource routes (routes without UI)
- Work with route parameters and search params
- Understand Epic Stack's file-based routing conventions
- Implement loaders and actions in routes
Patterns and conventions
Routing Philosophy
Following Epic Web principles:
Do as little as possible - Keep your route structure simple. Don't create complex nested routes unless you actually need them. Start simple and add complexity only when there's a clear benefit.
Avoid over-engineering - Don't create abstractions or complex route structures "just in case". Use the simplest structure that works for your current needs.
Example - Simple route structure:
// ✅ Good - Simple, straightforward route
// app/routes/users/$username.tsx
export async function loader({ params }: Route.LoaderArgs) {
const user = await prisma.user.findUnique({
where: { username: params.username },
select: { id: true, username: true, name: true },
})
return { user }
}
export default function UserRoute({ loaderData }: Route.ComponentProps) {
return <div>{loaderData.user.name}</div>
}
// ❌ Avoid - Over-engineered route structure
// app/routes/users/$username/_layout.tsx
// app/routes/users/$username/index.tsx
// app/routes/users/$username/_components/UserHeader.tsx
// app/routes/users/$username/_components/UserDetails.tsx
// Unnecessary complexity for a simple user page
Example - Add complexity only when needed:
// ✅ Good - Add nested routes only when you actually need them
// If you have user notes, then nested routes make sense:
// app/routes/users/$username/notes/_layout.tsx
// app/routes/users/$username/notes/index.tsx
// app/routes/users/$username/notes/$noteId.tsx
// ❌ Avoid - Creating nested routes "just in case"
// Don't create complex structures before you need them
File-based routing with react-router-auto-routes
Epic Stack uses react-router-auto-routes instead of React Router's standard
convention. This enables better organization and code co-location.
Basic structure:
app/routes/
├── _layout.tsx # Layout for child routes
├── index.tsx # Root route (/)
├── about.tsx # Route /about
└── users/
├── _layout.tsx # Layout for user routes
├── index.tsx # Route /users
└── $username/
└── index.tsx # Route /users/:username
Configuration in app/routes.ts:
import { type RouteConfig } from '@react-router/dev/routes'
import { autoRoutes } from 'react-router-auto-routes'
export default autoRoutes({
ignoredRouteFiles: [
'.*',
'**/*.css',
'**/*.test.{js,jsx,ts,tsx}',
'**/__*.*',
'**/*.server.*', // Co-located server utilities
'**/*.client.*', // Co-located client utilities
],
}) satisfies RouteConfig
Route Groups
Route groups are folders that start with _ and don't affect the URL but help
organize related code.
Common examples:
_auth/- Authentication routes (login, signup, etc.)_marketing/- Marketing pages (home, about, etc.)_seo/- SEO routes (sitemap, robots.txt)
Example:
app/routes/
├── _auth/
│ ├── login.tsx # URL: /login
│ ├── signup.tsx # URL: /signup
│ └── forgot-password.tsx # URL: /forgot-password
└── _marketing/
├── index.tsx # URL: /
└── about.tsx # URL: /about
Route Parameters
Use $ to indicate route parameters:
Syntax:
$param.tsx→:paramin URL$username.tsx→:usernamein URL
Example route with parameter:
// app/routes/users/$username/index.tsx
export async function loader({ params }: Route.LoaderArgs) {
const username = params.username // Type-safe!
const user = await prisma.user.findUnique({
where: { username },
})
return { user }
}
Nested Layouts with _layout.tsx
Use _layout.tsx to create shared layouts for child routes.
Example:
// app/routes/users/$username/notes/_layout.tsx
export async function loader({ params }: Route.LoaderArgs) {
const owner = await prisma.user.findFirst({
where: { username: params.username },
})
return { owner }
}
export default function NotesLayout({ loaderData }: Route.ComponentProps) {
return (
<main className="container">
<h1>{loaderData.owner.name}'s Notes</h1>
<Outlet /> {/* Child routes render here */}
</main>
)
}
Child routes ($noteId.tsx, index.tsx, etc.) will render where <Outlet />
is.
Resource Routes (Routes without UI)
Resource routes don't render UI; they only return data or perform actions.
Characteristics:
- Don't export a
defaultcomponent - Export
loaderoractionor both - Useful for APIs, downloads, webhooks, etc.
Example:
// app/routes/resources/healthcheck.tsx
export async function loader({ request }: Route.LoaderArgs) {
// Check application health
const host =
request.headers.get('X-Forwarded-Host') ?? request.headers.get('host')
try {
await Promise.all([
prisma.$queryRaw`SELECT 1`, // Check DB
fetch(`${new URL(request.url).protocol}${host}`, {
method: 'HEAD',
headers: { 'X-Healthcheck': 'true' },
}),
])
return new Response('OK')
} catch (error) {
return new Response('ERROR', { status: 500 })
}
}
Loaders and Actions
Loaders - Load data before rendering (GET requests) Actions - Handle data mutations (POST, PUT, DELETE)
Loader pattern:
export async function loader({ request, params }: Route.LoaderArgs) {
const userId = await requireUserId(request)
const data = await prisma.something.findMany({
where: { userId },
})
return { data }
}
export default function RouteComponent({ loaderData }: Route.ComponentProps) {
return <div>{/* Use loaderData.data */}</div>
}
Action pattern:
export async function action({ request }: Route.ActionArgs) {
const userId = await requireUserId(request)
const formData = await request.formData()
// Validate and process data
await prisma.something.create({
data: { /* ... */ },
})
return redirect('/success')
}
export default function RouteComponent() {
return (
<Form method="POST">
{/* Form fields */}
</Form>
)
}
Search Params
Access query parameters using useSearchParams:
import { useSearchParams } from 'react-router'
export default function SearchPage() {
const [searchParams, setSearchParams] = useSearchParams()
const query = searchParams.get('q') || ''
const page = Number(searchParams.get('page') || '1')
return (
<div>
<input
value={query}
onChange={(e) => setSearchParams({ q: e.target.value })}
/>
{/* Results */}
</div>
)
}
Code Co-location
Epic Stack encourages placing related code close to where it's used.
Typical structure:
app/routes/users/$username/notes/
├── _layout.tsx # Layout with loader
├── index.tsx # Notes list
├── $noteId.tsx # Note view
├── $noteId_.edit.tsx # Edit note
├── +shared/ # Code shared between routes
│ └── note-editor.tsx # Shared editor
└── $noteId.server.ts # Server-side utilities
The + prefix indicates co-located modules that are not routes.
Naming Conventions
_layout.tsx- Layout for child routesindex.tsx- Root route of the segment$param.tsx- Route parameter$param_.action.tsx- Route with parameter + action (using_)[.]ext.tsx- Resource route (e.g.,robots[.]txt.ts)
Common examples
Example 1: Create a basic route with layout
// app/routes/products/_layout.tsx
export async function loader({ request }: Route.LoaderArgs) {
const categories = await prisma.category.findMany()
return { categories }
}
export default function ProductsLayout({ loaderData }: Route.ComponentProps) {
return (
<div>
<nav>
{loaderData.categories.map(cat => (
<Link key={cat.id} to={`/products/${cat.slug}`}>
{cat.name}
</Link>
))}
</nav>
<Outlet />
</div>
)
}
// app/routes/products/index.tsx
export default function ProductsIndex() {
return <div>Products list</div>
}
Example 2: Route with dynamic parameter
// app/routes/products/$slug.tsx
export async function loader({ params }: Route.LoaderArgs) {
const product = await prisma.product.findUnique({
where: { slug: params.slug },
})
if (!product) {
throw new Response('Not Found', { status: 404 })
}
return { product }
}
export default function ProductPage({ loaderData }: Route.ComponentProps) {
return (
<div>
<h1>{loaderData.product.name}</h1>
<p>{loaderData.product.description}</p>
</div>
)
}
export function ErrorBoundary() {
return (
<GeneralErrorBoundary
statusHandlers={{
404: ({ params }) => (
<p>Product "{params.slug}" not found</p>
),
}}
/>
)
}
Example 3: Resource route for download
// app/routes/resources/download-report.tsx
export async function loader({ request }: Route.LoaderArgs) {
const userId = await requireUserId(request)
const report = await generateReport(userId)
return new Response(report, {
headers: {
'Content-Type': 'application/pdf',
'Content-Disposition': 'attachment; filename="report.pdf"',
},
})
}
Example 4: Route with multiple nested parameters
// app/routes/users/$username/posts/$postId/comments/$commentId.tsx
export async function loader({ params }: Route.LoaderArgs) {
// params contains: { username, postId, commentId }
const comment = await prisma.comment.findUnique({
where: { id: params.commentId },
include: {
post: {
include: { author: true },
},
},
})
return { comment }
}
Common mistakes to avoid
- ❌ Over-engineering route structure: Keep routes
Content truncated.
When not to use it
- →Creating complex nested routes without a clear benefit
- →Using standard React Router conventions instead of auto-routes
- →Exporting default components in resource routes
Prerequisites
Limitations
- →Route groups starting with _ do not affect the URL structure
- →Resource routes must not export a default component
How it compares
Unlike standard React Router configurations, this approach relies on file-based auto-routing to organize code and minimize manual route definitions.
Compared to similar skills
epic-routing side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| epic-routing (this skill) | 1 | 6mo | No flags | Intermediate |
| nextjs-best-practices | 31 | 6mo | No flags | Intermediate |
| app-specific-patterns | 4 | 2mo | No flags | Intermediate |
| javascript-typescript-typescript-scaffold | 3 | 4mo | Review | Beginner |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by epicweb-dev
View all by epicweb-dev →You might also like
nextjs-best-practices
davila7
Next.js App Router principles. Server Components, data fetching, routing patterns.
app-specific-patterns
growilabs
GROWI main application (apps/app) specific patterns for Next.js, Jotai, SWR, and testing. Auto-invoked when working in apps/app.
javascript-typescript-typescript-scaffold
sickn33
You are a TypeScript project architecture expert specializing in scaffolding production-ready Node.js and frontend applications. Generate complete project structures with modern tooling (pnpm, Vite, N
server-components
davepoon
This skill should be used when the user asks about "Server Components", "Client Components", "'use client' directive", "when to use server vs client", "RSC patterns", "component composition", "data fetching in components", or needs guidance on React Server Components architecture in Next.js.
web-frameworks
mrgoonie
Build modern full-stack web applications with Next.js (App Router, Server Components, RSC, PPR, SSR, SSG, ISR), Turborepo (monorepo management, task pipelines, remote caching, parallel execution), and RemixIcon (3100+ SVG icons in outlined/filled styles). Use when creating React applications, implementing server-side rendering, setting up monorepos with multiple packages, optimizing build performance and caching strategies, adding icon libraries, managing shared dependencies, or working with TypeScript full-stack projects.
frontend-structure
Kwondongkyun
Next.js App Router 프로젝트 구조 설정 시 사용. app(페이지), components(UI), features(도메인), lib(유틸), hooks 폴더 구조.