Enforce portable, module-based frontend architecture across React projects

A portable, framework-agnostic frontend architecture skill for React and React Native, mapping the same module/page/state model onto Next.js (App Router), React + Vite (SPA), Remix, and Expo/React Native, working with any state-management or styling stack. It rests on five core ideas: feature modules own their world (each modules/{feature}/ folder is self-contained with pages, components, hooks, state, types, and one public barrel); pages/screens are always directories, never loose files, co-locating their component, styles, and page-only sub-components/hooks; state is split by origin - server data lives in a query/cache layer (TanStack Query, RTK Query, SWR, Apollo), UI/client state lives in a store (Zustand, Redux Toolkit, MobX, Jotai, Valtio, or Context), and the two never mix; cross-module imports go only through a module's index.ts barrel, never into internals; and code starts as local as possible, promoted outward only when a second consumer appears. Hard state rules: never mirror server responses into the client store, never fetch inside components (they read via data hooks and store selectors), never drive continuous values (scroll, drag) through render state, and each module owns exactly one store unit accessed via its barrel. State interfaces use an I-prefix convention (IFeatureUiState); server-state access goes through one typed API client plus a hierarchical query-key factory per module for consistent cache invalidation. Styling is co-located per page/component in a {name}.styles.ts (or equivalent) file, never inline in JSX - the specific syntax (Tailwind+cn()/cva, CSS Modules, styled-components, Tamagui for shared web+native, or React Native StyleSheet/Nativewind) is the team's choice, but the co-location rule is constant. Naming conventions cover interfaces (I-prefix), PascalCase components, kebab-case page directories, useCamelCase hooks, {feature}.store.ts/.slice.ts/.atoms.ts store files, and index.ts barrels throughout. Framework adapters keep pages in modules/ with only a thin routing layer differing per framework - Next.js App Router route files import and render a page component from a module barrel, defaulting to Server Components with "use client" marking only interactive leaves and provider boundaries.

Use it when architecting or refactoring a React or React Native frontend that needs a consistent, scalable module structure - deciding where code lives, what's allowed to import what, and whether a given piece of state is server or UI state. It's deliberately not a component library, state library, or visual design system - pair it with a separate design/component skill for visual styling decisions.

Given a new feature or a refactoring target, it produces a directory structure (modules/{feature}/ with pages, components, hooks, stores, services, types) plus concrete guidance on which state library pattern and styling approach to apply consistently, following the naming conventions throughout.

Framework-agnostic: works with Next.js App Router, React + Vite SPA, Remix, and Expo/React Native, and is state-library and styling-library agnostic (Zustand/Redux Toolkit/MobX/Jotai for state; Tailwind/CSS Modules/styled-components/Tamagui/React Native StyleSheet for styling).

Frontend teams who want a portable, non-negotiable structure so any contributor can answer "where does this code live," "what can import what," and "is this server or UI state" without asking - readable by Claude Code, OpenCode, Codex, Cursor, Windsurf, and other AI coding tools.