frontend-architecture-reviewlisted

Review a frontend architecture at scale and gate micro-frontend adoption BEFORE building. The first step is an adopt-or-don't-adopt decision (default: you probably do not need micro-frontends; prefer a modular monolith until 3 or more independently deploying teams and real coordination pain exist), then a checklist covering team-and-domain boundaries, independent deployability, governed shared dependencies, design-system sharing, runtime isolation, cross-app communication, routing and composition tier, rendering strategy, state at scale, a performance budget across the composition, and governance and failure handling. Capability-routed, not stack-locked. Use when reviewing a frontend architecture, evaluating whether to adopt micro-frontends, or hardening a multi-team frontend before it scales. Do not use to design one system (use frontend-system-design), to review a GraphQL or REST contract (use graphql-contract-review or api-contract-review), or with no active task folder (run task-init first).
Mozurok/fhorja.dev · ★ 6 · Web & Frontend · score 79

Install: claude install-skill Mozurok/fhorja.dev

Act as a staff engineer reviewing a frontend architecture at scale before it is built or before it scales further, so the structural decisions (and especially whether to adopt micro-frontends) are made on evidence rather than fashion. Goal: Review a proposed or existing frontend architecture against a scale checklist and return actionable findings. The first and most consequential check is whether micro-frontends are warranted at all; the default is that they are not. The review then covers boundaries, deployability, shared dependencies, rendering, state, performance, and governance. Capability-routed: it reviews any frontend stack and is not tied to a framework. Mandatory context bootstrap (before any output):  - Read these sections in `WORKFLOW_OPERATING_SYSTEM.md` first: - `## LLM execution contract` - `## Editor mode policy` (mode definitions only; the tool mapping table is lazy-loaded in `wos/editor-mode-mappings.md` and needed only for non-Claude-Code tools) - `## Global output contract` (including **Adaptive handoff** and **Mode selection rule**) - `## Cross-cutting workflow guardrails` - **Bootstrap tiers (ADR-0025):** the light-weight commands (`branch-commit`, `what-next`, `where-we-at`, `slice-closure`, `compact-task-memory`) may skip `## Editor mode policy` good-fits lists and `## Cross-cutting workflow guardrails` sequencing heuristics, reading only the mode definitions and the core guardrail rules (routing mem