Inertia Rails Architecture

This is the entry point for any Inertia Rails project. It's a decision matrix that stops you from reaching for SPA patterns that break Inertia's server-driven model. The core insight is simple: the server owns routing, data, and auth; React just renders. So no useEffect fetching, no React Query, no client-side routing. Instead you get a lookup table for common needs (forms, navigation, data refresh) and which Inertia primitive solves each one. Load this first when building features, then it routes you to the specific skill you need. The rules section is worth scanning even if you've used Inertia before, especially the bit about why fetch breaks CSRF and error handling that the Form component handles automatically.

skills.sh installs: 545
GitHub stars: 70
last updated: Aug 21, 2026

View on GitHub

Install

$ npx -y skills add inertia-rails/skills --skill inertia-rails-architecture --agent claude-code

Installs into .claude/skills of the current project.

Files

Inertia Rails Architecture

Server-driven architecture for Rails + Inertia.js + React when building pages, forms, navigation, or data refresh. Inertia is NOT a traditional SPA — the server owns routing, data, and auth. React handles rendering only.

The Core Mental Model

The server is the source of truth. React receives data as props and renders UI. There is no client-side router, no global state store, no API layer.

Before building any feature, ask:

Where does the data come from? → If server: controller prop. If user interaction: useState.
Who owns this state? → If it's in the URL or DB: server owns it (use props). If it's ephemeral UI: React owns it.
Am I reaching for a React/SPA pattern? → Check the decision matrix below first — Inertia likely has a server-driven equivalent.