From frontend
ACTIVATE when creating or modifying frontend features in projects with domain/infrastructure layered architecture. ACTIVATE for 'frontend architecture', 'domain layer', 'hexagonal frontend', 'features/ folder', 'repository interface', 'mapper'. Covers: features/<feature>/domain + infrastructure structure, strict dependency direction (domain never imports infrastructure), domain models/repositories/services/referentials, API repositories, mappers, hooks as orchestrators. DO NOT use for: projects without this architecture (ask user first), general React patterns (see frontend-component-patterns).
How this skill is triggered — by the user, by Claude, or both
Slash command
/frontend:frontend-clean-architectureThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Apply only on projects that already have a `features/<feature>/domain/` + `infrastructure/` structure. If the project does not use this architecture, ask the user before applying these patterns.
Apply only on projects that already have a features/<feature>/domain/ + infrastructure/ structure. If the project does not use this architecture, ask the user before applying these patterns.
src/
├── features/
│ └── <feature>/
│ ├── domain/ ← PURE: no React/Astro/fetch imports
│ │ ├── <feature>.model.ts types/interfaces for the domain
│ │ ├── <feature>.repository.ts SPI (interface) for data access
│ │ ├── <feature>.service.ts pure business logic (validation, calculations)
│ │ └── referentials/ constants and option lists
│ └── infrastructure/ ← IMPURE: external dependencies
│ ├── api/ repository implementations (fetch)
│ ├── mappers/ API ↔ domain transformations
│ ├── hooks/ React orchestration (state + side-effects)
│ └── components/ React components (Container + Presentation)
├── shared/
│ ├── domain/ cross-cutting types and errors (ApiError)
│ └── infrastructure/
│ └── components/ reusable UI components (Button, Input, Select)
├── pages/ Astro pages
├── layouts/ Astro layouts
└── styles/ global CSS + tokens
domain/ NEVER imports from infrastructure/, React, Astro, or any external libraryinfrastructure/ CAN import from domain/shared/domain/ NEVER imports from infrastructure/domain/)<feature>.model.ts): TypeScript types and interfaces describing domain concepts. No classes, no decorators, no framework types.<feature>.repository.ts): SPI (Service Provider Interface) — the domain defines WHAT data access it needs, not HOW. Uses Promise (standard JS, not a framework dependency).<feature>.service.ts): Pure functions only. No fetch, no useState, no side-effects. Input → output. Testable without mocks.referentials/*.referentials.ts): Constants and generator functions for option lists. NEVER hardcode values that will become obsolete (e.g., years). Use generator functions like getYearOptions() instead.infrastructure/)api/<feature>.api-repository.ts): Implements the repository interface from domain. Contains fetch calls, error handling, HTTP concerns.mappers/<feature>.mapper.ts): The ONLY place where API types ↔ domain types transformation happens. Never transform inline in components or hooks.hooks/use<Feature>.ts): Orchestrate React state + domain services + repository calls. This is the "glue" between pure domain and impure React.components/): Follow Container/Presentation pattern (see frontend-component-patterns skill).| File | Pattern | Example |
|---|---|---|
| Model | <feature>.model.ts | receipt-form.model.ts |
| Repository interface | <feature>.repository.ts | receipt.repository.ts |
| Service | <concern>.service.ts | period.service.ts |
| Referential | <concern>.referentials.ts | payment.referentials.ts |
| API repository | <feature>.api-repository.ts | receipt.api-repository.ts |
| Mapper | <feature>.mapper.ts | receipt.mapper.ts |
| Hook | use<Feature>.ts | useReceiptForm.ts |
fetch() in a component → move to api/ repositoryparseFloat() or formatting logic inline in JSX → move to domain serviceYEARS = [2026, 2025, 2024] → use getYearOptions() generatornpx claudepluginhub fabiensalles/claude-marketplace --plugin frontendFramework-agnostic frontend architecture guidance on state management, component organization, and data fetching patterns. Useful when structuring UI code or choosing state boundaries.
Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.