القائمة
React and Next.js App Router architecture for AFENDA-HYBRID: Server vs Client Components, composition, state placement, package layering (ui-core → view-engine → erp-view-pack → apps/web). Use when designing components, fixing import/layer violations, or RSC boundaries.
Accessibility for React UIs in AFENDA-HYBRID: semantic HTML, ARIA, keyboard support, focus management, and testing. Use for grids, dialogs, bulk selection, notifications, and command surfaces.
Implementation patterns for AFENDA-HYBRID React code: custom hooks, compound components, error boundaries / error.tsx, forms, server actions, and optimistic updates.
React performance for AFENDA-HYBRID: runtime rendering (re-renders, keys, virtualization) and build-time delivery (bundles, tree-shaking, code splitting, compiler directives). Use when fixing slow lists, grids, or large client bundles.
Meta-skill: React Quality Orchestrator for AFENDA-HYBRID. Coordinates architecture, performance, accessibility, and design-pattern skills for audits, scoring (Component Quality Index), and confidence-tiered refactors. Use for full-route reviews, legacy refactors, and governance checks.
Official Storybook AI workflow — MCP server, manifests, MCP toolsets (development, docs, testing), and documentation best practices. Use when writing or fixing stories, connecting agents to Storybook, using design-system components without guessing props, or running Storybook tests from an agent. Sources are linked inline.
Vitest (Vite-powered) testing — Jest-compatible API, vi mocks, coverage, environments, projects/workspaces. Use when writing or fixing tests, vitest.config.ts, coverage, or monorepo test commands in AFENDA-HYBRID (@afenda/db, @afenda/ui-core, view-engine, erp-view-pack). Prefer https://vitest.dev for Vitest 4.x when reference snippets disagree.
| name | react-architecture |
| description | React and Next.js App Router architecture for AFENDA-HYBRID: Server vs Client Components, composition, state placement, package layering (ui-core → view-engine → erp-view-pack → apps/web). Use when designing components, fixing import/layer violations, or RSC boundaries. |
| metadata | {"author":"AFENDA team","version":"2026.03.23","source":"React docs + AFENDA-HYBRID codebase analysis","official_docs":"https://react.dev"} |
React architecture in this monorepo is governance-first: correct boundaries make performance, a11y, and testing predictable. Prefer Rules of React (purity, hooks, React owns invocation).
Key ideas
apps/web; "use client" only where browser APIs, local state, or event handlers require it.@afenda/ui-core → @afenda/view-engine → @afenda/erp-view-pack → app — no upward imports.Provenance: see GENERATION.md.
Version alignment: React 19 peers in UI packages; Next.js in apps/web when present. Confirm framework-specific APIs against current Next.js docs.
| Topic | Description | Reference |
|---|---|---|
| Server Components | RSC data fetching, streaming, Suspense | server-components |
| Composition | Slots, children, delegation | composition-patterns |
| State | Where state lives: server vs client, URL, stores | state-management |
| Package layering | What belongs in each package | package-layering |
| RSC pitfalls | Client/server boundary mistakes | client-server-boundary-anti-patterns |
This skill does not:
| Area | Enforce |
|---|---|
| ui-core | Client-safe primitives/patterns; no server-only imports; no app-specific routes; avoid global client stores (e.g. Zustand) in this layer |
| view-engine | Metadata and registry APIs stay framework-agnostic where possible; interactive renderers/widgets are "use client"; depend only on ui-core + metadata types |
| erp-view-pack | ERP chrome and selection/bulk patterns; Zustand and client-only stores live here; follow packages/erp-view-pack/src/patterns/_CONVENTIONS.md |
| apps/web | Compose packages; Server Components default; colocate "use client" at leaves; server actions and route handlers own I/O boundaries |