agentleFS
htmujahidhtmujahid/project-structure-skills/skills/react-layered-architecture/SKILL.md

react-layered-architecture

Skill0 starsChanged 16 days agoMITView on GitHub

Use when creating, moving, or naming files in a plain React app (Vite or similar SPA, no Next.js/Remix) organized by technical layer (pages, components, hooks, queries). Best for small to mid-size apps. Covers layout, naming, import direction, config, tests, and when to move to react-domain-architecture.

  • Reads credentials

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. About 0 are common, 4 are distinctive, and 15 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 15

    Very specific

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

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

    Read src/ before creating files.

    line 17
  2. Distinctive:

    Read references/full-tree.md when you need the expanded tree with every subfolder.

    line 38
  3. Very specific:

    Put unit and component tests next to the file: button.tsx, button.test.tsx.

    line 77
  4. Very specific:

    Put test setup and shared helpers in src/test/.

    line 78
  5. Very specific:

    Put end-to-end tests in e2e/ at the repo root.

    line 79
  6. Distinctive:

    Read references/growth-stages.md when deciding whether to restructure.

    line 83
  7. Very specific:

    Use main.tsx, app.tsx, and components/.

    line 87
  8. Very specific:

    Use the default layout above.

    line 92
  9. Distinctive:

    Read references/anti-patterns.md when reviewing a layout or before moving files.

    line 101
  10. Very specific:

    Do not call fetch or an API client inside a component.

    line 103
  11. Very specific:

    Do not write query keys inline.

    line 104
  12. Very specific:

    Do not import React components in queries/ or utils/.

    line 105
  13. Very specific:

    Do not import pages/ from components/.

    line 106
  14. Very specific:

    Do not put a component in components/ if only one page uses it.

    line 107
  15. Very specific:

    Do not create a common/, misc/, or helpers/ folder.

    line 108
  16. Very specific:

    Do not add an index.ts barrel to every folder.

    line 109
  17. Very specific:

    Do not copy query data into useState or store/.

    line 110
  18. Very specific:

    Do not use deep relative imports.

    line 111
  19. Distinctive:

    Do not use PascalCase or camelCase file names, or rename a file only to change its case.

    line 112

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “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

React layered architecture

Plain React single-page app, grouped by technical role. Server data is handled with TanStack Query (or a similar query client) in queries/. Use for small to mid-size projects.

Target version

Written for React 19 with TypeScript and Vite on 2026-10-29. Applies to any client-only React setup. Not for meta-frameworks (Next.js, Remix), which have their own routing layout.

Follow the repo first

Read src/ before creating files. If the project already has conventions (folder names, casing, import alias), use them. Check tsconfig.json for path aliases and the lint config for import rules.

Default directory layout

src/
  main.tsx        # entry: mounts <App />
  app.tsx         # providers and router
  pages/          # one component per route
  components/     # shared UI used by 2+ pages
    ui/           # generic primitives (Button, Modal)
  hooks/          # shared custom hooks
  queries/        # query and mutation hooks, query keys, request functions
  store/          # global client state
  utils/          # pure helper functions
  types/          # shared types
  config/         # env parsing and constants
  styles/         # global CSS and tokens
  test/           # test setup and shared test helpers

Read references/full-tree.md when you need the expanded tree with every subfolder.

Naming conventions

  • Files and folders: kebab-case for everything, such as user-card.tsx and use-users.ts. Do not mix casing.
  • Exports: use named exports. Avoid default exports.
  • Components: one component per file. The export is PascalCase and the file is its kebab-case form: UserCard in user-card.tsx.
  • Hooks: use-thing.ts, exporting useThing.
  • Queries: user.queries.ts, one per backend resource. Exports hooks (useUsers, useCreateUser) and a key factory (userKeys).
  • Types: user.types.ts.
  • Routes: pages are user-list-page.tsx. URL paths are kebab-case.
  • Tests: user-card.test.tsx next to the file under test.
  • Imports: use the @/ alias for src/. Never import with ../../...

Dependency direction

Higher layers may import lower layers. Lower layers never import higher ones.

pages -> components -> queries, hooks -> utils -> types
  • pages import from any layer below.
  • components import queries, hooks, utils, types, and other components. Never pages.
  • queries import utils, types, config, and queries/api-client.ts. Never components, pages, or store.
  • hooks hold UI and generic logic. They may import queries, store, utils, types.
  • utils and types import nothing from the app.

Where things live

  • Config: src/config/. Read import.meta.env only in config/env.ts.
  • Env vars: prefix with VITE_. List every var in .env.example at the repo root.
  • Shared types: src/types/. Keep a type next to its only user until a second file needs it.
  • Global state: src/store/. Keep server data in the query cache, not in store/. Keep UI state local.
  • Query client: create it in src/config/query-client.ts. Mount the provider in app.tsx.
  • HTTP client: src/queries/api-client.ts. Only queries/ files call it.

Tests

  • Put unit and component tests next to the file: button.tsx, button.test.tsx.
  • Put test setup and shared helpers in src/test/.
  • Put end-to-end tests in e2e/ at the repo root.

Structure at three sizes

Read references/growth-stages.md when deciding whether to restructure.

Prototype

Use main.tsx, app.tsx, and components/. Add hooks/ and queries/ on first use. Signal to move up: a second page, or an API call.

Mid-size

Use the default layout above. Add subfolders inside a layer when it passes about 10 files, for example components/forms/. Signal to move up: components/ or hooks/ passes about 30 files, one feature change touches 4+ top-level folders, or several people collide in the same folders.

Large

Switch to the react-domain-architecture skill. Move one feature at a time. Do not rewrite.

Anti-patterns

Read references/anti-patterns.md when reviewing a layout or before moving files.

  • Do not call fetch or an API client inside a component. Use a hook from queries/.
  • Do not write query keys inline. Use the key factory from the resource's queries/ file.
  • Do not import React components in queries/ or utils/.
  • Do not import pages/ from components/.
  • Do not put a component in components/ if only one page uses it. Keep it next to that page.
  • Do not create a common/, misc/, or helpers/ folder.
  • Do not add an index.ts barrel to every folder.
  • Do not copy query data into useState or store/.
  • Do not use deep relative imports. Use @/.
  • Do not use PascalCase or camelCase file names, or rename a file only to change its case.

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.