expo-project-structure — Claude Code skill: what it does
Sets up a starter folder layout for a new Expo Router project. Helps place routes, screen bodies, and server files where they belong.
npx skills add expo/skills --skill expo-project-structure -a claude-codeWhat expo-project-structure does
The skill outlines an opinionated directory skeleton for clean Expo Router setups. All application code lives inside src/. The src/app directory is strictly reserved for routing: every file inside becomes an active route. To prevent routing clutter, full screen implementations live under src/screens, shared UI elements stay in src/components, and server helpers go to src/server.
Server endpoints using the +api suffix are grouped directly under src/app/api/. These run in a Node-like environment with access to private environment variables. Styles remain inside component files via StyleSheet.create, while unit tests sit right next to their source files.
Apply this layout only to fresh projects. Restructuring an existing repository to match these conventions will break existing import paths.
What it helps with
- separate Expo Router route files from complex screen bodies
- isolate server API endpoints and private environment variables
- organize platform-specific variants across native and web
- colocate tests and styles directly beside component files
Example prompts for the agent
- Scaffold the folder structure for a new Expo Router app
- Where should I place a server-side auth route in this Expo project?
- Create a settings screen and split its body into the screens directory
How to install expo-project-structure
1Skills CLI (Vercel)
npx skills add expo/skills --skill expo-project-structure -a claude-code2Manually: put the files in place
~/.claude/skills/expo-project-structure/SKILL.mdCopy the whole skill folder; for one project use .claude/skills/expo-project-structure/
1Skills CLI (Vercel)
npx skills add expo/skills --skill expo-project-structure -a codex2Manually: put the files in place
.agents/skills/expo-project-structure/SKILL.mdFor all projects use ~/.agents/skills/
1Skills CLI (Vercel)
npx skills add expo/skills --skill expo-project-structure -a cursor2Manually: put the files in place
.cursor/skills/expo-project-structure/SKILL.mdCursor also reads .agents/skills/ and .claude/skills/
1GitHub CLI
gh skill install expo/skills expo-project-structure2Manually: put the files in place
.github/skills/expo-project-structure/SKILL.md1Skills CLI (Vercel)
npx skills add expo/skills --skill expo-project-structure -a gemini-cli2Platform CLI
gemini skills install https://github.com/expo/skills --path plugins/expo/skills/expo-project-structureManually: put the files in place
.devin/skills/expo-project-structure/SKILL.mdThe legacy .windsurf/skills/ path still works
Skills CLI (Vercel)
npx skills add expo/skills --skill expo-project-structure -a opencodeClaude.ai
Zip the folder and upload it in Settings → Capabilities → Skills
From the same set20
The whole set →Similar
Questions about expo-project-structure
How to install expo-project-structure in Claude Code?
Run npx skills add expo/skills --skill expo-project-structure -a claude-code. This installs the skill files into your agent directory.
What does the expo-project-structure skill do?
It provides an architectural skeleton for Expo Router projects, defining locations for routes, screens, shared components, and server endpoints.
Can I use this skill to reorganize an existing app?
No. The rules explicitly instruct the agent never to restructure an existing codebase, as it is strictly meant for fresh projects.
Source text
SKILL.md · MIT
---
name: expo-project-structure
description: Folder structure for a new Expo app. Use when scaffolding or laying out a new Expo project with Expo Router, or deciding where a file should live in one. For new projects only — never restructure an existing app to match.
version: 1.0.0
license: MIT
---
# Expo Project Structure
A starting skeleton for a **new** Expo app — one with no committed folder structure yet.
**Apply only to new projects.** If the app already has a layout, follow its existing conventions and leave files where they are — a default to start from, never a standard to enforce or migrate toward. When unsure whether a project is new, ask before moving anything.
The whole layout, assembled from the rules below:
```
├── assets/
├── scripts/
├── src/
│ ├── app/ # Expo Router routes ONLY — every file is a route
│ │ ├── api/ # server API routes, grouped here
│ │ │ ├── user+api.ts
│ │ │ └── settings+api.ts
│ │ ├── _layout.tsx
│ │ ├── _layout.web.tsx # platform-specific layout
│ │ ├── index.tsx
│ │ └── settings.tsx
│ ├── components/ # reusable UI: button, card, table…
│ │ ├── table/ # complex component → folder + index.tsx
│ │ │ ├── cell.tsx
│ │ │ └── index.tsx
│ │ ├── bar-chart.tsx
│ │ ├── bar-chart.web.tsx # platform-specific variant
│ │ └── button.tsx
│ ├── screens/ # screen bodies that route files render
│ │ ├── home/
│ │ │ ├── card.tsx # used only by Home — not shared
│ │ │ └── index.tsx # rendered by src/app/index.tsx
│ │ └── settings.tsx
│ ├── server/ # server-only helpers used by app/api
│ │ ├── auth.ts
│ │ └── db.ts
│ ├── utils/ # standalone helpers + colocated tests
│ │ ├── format-date.ts
│ │ └── format-date.test.ts
│ ├── hooks/ # reusable hooks: use-theme.ts…
│ ├── constants.ts
│ └── theme.ts
├── app.json
├── eas.json
└── package.json
```
## `src/` and `src/app`
Keep app code under `src/` to separate it from config files. Expo Router supports both `app/` and `src/app/` out of the box — to switch, move the folder and restart the bundler. The default template aliases `@/*` to `./src/*` in `tsconfig.json`.
`src/app` is **routes-only**: every file there becomes a route, so nothing else belongs in it. Everything below lives in sibling folders.
## components/ — reusable UI
Generic, reused UI (button, card, table) with one named export each. Name files in **kebab-case** (`bar-chart.tsx`), matching the default `create-expo-app` template. When a component grows, give it its own folder with the root in `index.tsx` and **colocate** its private sub-components beside it — the import path (`@/components/table`) stays unchanged.
## screens/ — screen bodies
Because `app/` files must be routes, complex screen UI that isn't reused has no home there. Once a screen grows big enough to need breaking out to separate components, put it in `screens/` and let each route just render its screen:
```tsx
import { Home } from "@/screens/home";
export default function HomeScreen() {
// route-specific concerns only — e.g. read url params here
return <Home />;
}
```
**Colocate** a screen's private components inside its folder (`screens/home/components/`). A bonus: the same screen can render under multiple routes.
## server/ + app/api/ — separate server code
Appending `+api` to a file in `app/` makes it a server **API route**. Server code is different from frontend code — it runs in a Node-like server environment (deployed with EAS Hosting or on [third-party services](https://docs.expo.dev/router/web/api-routes/#hosting-on-third-party-services)) and can read secret env vars (`process.env.X`, not just `EXPO_PUBLIC_*`). Keep it apart:
- Group all routes under `app/api/` → `/api/user`, `/api/settings`. This colocates them and avoids collisions (e.g. a `/user` screen and a `/user` route).
- Put shared server-only helpers in `src/server/`.
- Consider ESLint rules that fence `+api` files and `server/` off from frontend-only checks.
## Platform-specific code
Small differences: use `Platform.select` / `Platform.OS`. For larger ones, split into platform files instead of inline `if/else` — `bar-chart.tsx` + `bar-chart.web.tsx`, imported extension-free (`@/components/bar-chart`); Metro picks the right file per target.
- Props must be identical across variants.
- A default file (no platform extension) is always required — make it a no-op if the component is single-platform.
- Supported extensions: `.ios`, `.android`, `.native`, `.web`.
## Colocate styles and tests
- **Styles:** keep the `StyleSheet.create({ ... })` object at the bottom of the component file rather than in a separate `.styles` file.
- **Tests:** put `format-date.test.ts` next to `format-date.ts` (preferred over a separate `__tests__/` folder) so tested files are obvious at a glance.
## AI and config files
Agent instructions live at the repo root — `AGENTS.md` / `CLAUDE.md`, with project skills under `.claude/`. Other config and assets stay outside `src/`: `app.json` / `app.config.ts`, `eas.json`, `package.json`, `assets/`, and `scripts/`.
---
Based on [Expo app folder structure best practices](https://expo.dev/blog/expo-app-folder-structure-best-practices) by Kadi Kraman. For `src/` precedence and alias mechanics, see the [Expo docs](https://docs.expo.dev/router/reference/src-directory/).
## Submitting Feedback
If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:
```bash
npx --yes @expo/agent-cli@latest feedback --category skills --subject "expo-project-structure" "<actionable feedback>"
```
Only submit when you have something specific and actionable to report. Include as much relevant context as possible.
If an agent repeatedly fails at an Expo task or the user has to step in, submit a brief report of the task, expected result, and what went wrong using `--category evals` and the relevant Expo package or command as `--subject`.
© expo · MIT · expo/skills