frontend-architecture-review

Solid

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).

Web & Frontend 6 stars 0 forks Updated 5 days ago MIT

Install

View on GitHub

Quality Score: 81/100

Stars 20%
28
Recency 20%
100
Frontmatter 20%
70
Documentation 15%
100
Issue Health 10%
80
License 10%
100
Description 5%
100

Skill Content

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): <!-- shared:mandatory-context-bootstrap --> - 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...

Details

Author
Mozurok
Repository
Mozurok/fhorja.dev
Created
1 months ago
Last Updated
5 days ago
Language
Python
License
MIT

Integrates with

Similar Skills

Semantically similar based on skill content — not just same category

Web & Frontend Solid

frontend-system-design

Produce a staff-grade frontend system-design RFC for the active task: a 12-section design document (problem, requirements, architecture, data model, API and interface contract, rendering and delivery, state management, performance budget, accessibility, security, rollout, trade-offs) covering web and mobile, persisted as FRONTEND_SYSTEM_DESIGN.md. The default mode writes the design doc for real work; an --interview mode reframes the same structure for a frontend system-design interview round (RADIO-aligned). Capability-routed, not React-specific. Use when a frontend feature or surface needs an architecture-level design before planning and slicing, or when preparing a system-design interview artifact. Do not use to frame whether the problem is right (use problem-framing), to slice an already-designed change (use implementation-plan), to analyze blast radius (use impact-analysis), to review an API contract in isolation (use api-contract-review), or with no active task folder (run task-init first).

6 Updated 5 days ago
Mozurok
API & Backend Solid

graphql-contract-review

Review a GraphQL schema and a Backend-for-Frontend (BFF) contract BEFORE implementation, against a GraphQL-specific checklist: schema shape and nullability (null-bubbling), errors-as-data unions, N+1 and DataLoader, query cost and depth limits, cursor-connection pagination, federation entity ownership, breaking-change gate (schema checks), auth layering and BFF token posture, BFF thinness, and partial-failure degradation. Distinct from api-contract-review (REST and HTTP) and review-hard (post-implementation risk). Capability-routed, not stack-locked. Use when designing a new GraphQL schema, a federated subgraph, or a BFF contract, or modifying an existing one. Do not use for a REST contract (use api-contract-review), when the schema is already implemented (use review-hard or repo-consistency-sweep), or with no active task folder (run task-init first).

6 Updated 5 days ago
Mozurok
Code & Development Listed

frontend-code-review

Review frontend / client-side code (Next.js App Router, React, TypeScript, Tailwind + shadcn/ui, axios + Zod + TanStack Query + RHF) for correctness, component duplication, API-binding conformance, convention adherence, accessibility, and performance. Use whenever the user asks to review, audit, critique, or sanity-check frontend code — "review this component", "code review the products binding", "review my changes / this PR / the diff", "is this screen production-ready", "check this React code for issues". It reads the frontend ARCHITECTURE.md + MODULE_REGISTRY.md so it reviews against THIS project's conventions and flags components/hooks/utils that duplicate existing shared pieces or registry entries (DRY), plus bindings that bypass the BFF/axios/Zod/Query standard. Standalone and read-only — run anytime, never auto-chained, and it does not modify source unless explicitly asked to apply fixes. Tuned for frontend; NOT for backend/Express/Mongoose review (that is backend-code-review). This is static code revi

0 Updated 2 weeks ago
vipincode