agentleFS
mahik504mahik504/orchestra-workflow/skills/expo-project-structure/SKILL.md

expo-project-structure

Skill1 starsChanged 18 days agoMITView on GitHub

Framework (OSS). 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.

  • Reads credentials

6 other projects use a version of this, 4 of them edited; 1 new project in the last 4 weeks, against 1 the 4 before.

Adopted by

Steady: 1 new project took it in the last 4 weeks, 1× the 4 weeks before.thin data

Week of Sep 13: 0 new projectsWeek of Sep 20: 0 new projectsWeek of Sep 27: 0 new projectsWeek of Oct 4: 1 new projectWeek of Oct 11: 1 new projectWeek of Oct 18: 0 new projectsWeek of Oct 25: 0 new projectsWeek of Nov 1: 0 new projects
Sep 2026Oct 2026Nov 2026
New projects taking a version of this file each week, over the 8 weeks our latest run read: only 2 in all, so this is a hint, not a trend.

Most recently taken up by

Used with

Projects with it also use expo-overview and frontend-design.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • deonmenezesSkill

    expo-overview

    Entry point and router for every Expo or EAS task. Load this skill first — before writing code and before choosing another expo-* / eas-* skill — when the request, PRD, or spec mentions Expo, EAS, Expo Go, or an expo-* package, or the project has an `expo` dependency in `package.json`. Within that gate it also covers app specs and designs to implement (tabs, stacks, maps, lists, navigation, building from a screenshot), and phrasings like 'implement a mobile app', 'make my app look native', 'add navigation', 'fetch some data', 'upgrade my SDK', 'add Expo to my existing native app', 'ship to the App Store', or 'I'm new to Expo, where do I start'. A fully specified request (SDK pinned, libraries named, layout given) still routes through here — the shared setup rules still apply. Do NOT load it when neither signal is present: a bare React Native project with no `expo` dependency is not Expo work. Detects the real goal, routes to the right expo-* / eas-* skill, and owns the shared setup rules.

    Also in 4 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

8 rules. 2 are common, 1 is distinctive, and 5 are very specific to this project.

  • 2

    Common

    Most of the 4 edited versions we read keep these.

  • 1

    Distinctive

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Keep app code under src/ to separate it from config files.

    line 56
  2. Very specific:

    Put shared server-only helpers in src/server/.

    line 84
  3. Very specific:

    Consider ESLint rules that fence +api files and server/ off from frontend-only checks.

    line 85
  4. Very specific:

    Styles: keep the StyleSheet.create({ ...

    line 97
  5. Very specific:

    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.

    line 98
  6. Common:

    If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:

    line 109
  7. Common:

    Only submit when you have something specific and actionable to report.

    line 113
  8. Distinctive:

    If an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its …

    line 114

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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:

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) 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 by Kadi Kraman. For src/ precedence and alias mechanics, see the Expo docs.

Submitting Feedback

If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:

npx --yes submit-expo-feedback@latest --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 AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.