Frontend Layered Architecture

Overview

Frontend directory structures should not be split into only “pages and everything else.” “Everything else” means a state where type-revealing but role-ambiguous folders such as components, hooks, models, utils, and shared absorb all code. This skill does not exist to force a large architecture. It exists to prevent product policy, API contracts, URL state, and query logic from unconsciously leaking into those leftover directories during implementation.

Code should be separated by role, dependency constraints, external data boundaries, and orchestration responsibility. Lower-level code must not be made aware of higher-level context. Experienced frontend developers can practice clean code even in a “pages and everything else” structure, but in large teams, large projects, and coding-agent workflows, you cannot assume those principles will hold automatically.

This skill does not enforce a specific methodology such as Feature-Sliced Design or Vertical Slice Architecture. Type-based, feature-based, domain-driven, and other directory structures can all be valid. What matters is whether roles and dependency direction are clear within the structure the project has chosen, whether external data contracts are isolated, and whether code responsibilities and frontend-owned domain logic are managed effectively.

When to Use

Use when: