/solid-react

name: solid-react
description: Use when applying SOLID principles to React architecture — file-size limits, hook separation, src/interfaces/, JSDoc.
version: 1.0.0
user-invocable: true
references: references/solid-principles.md, references/single-responsibility.md, references/open-closed.md, references/liskov-substitution.md, references/interface-segregation.md, references/dependency-inversion.md, references/architecture-patterns.md, references/templates/component.md, references/templates/hook.md, references/templates/service.md, references/templates/store.md, references/templates/interface.md, references/templates/validator.md, references/templates/factory.md, references/templates/adapter.md, references/templates/error.md, references/templates/test.md

<objective> Enforces SOLID and DRY architecture on React 19 projects: source files within `FUSE_SOLID_MAX_LINES` and split by responsibility when cohesion drops, types isolated in `modules/[feature]/src/interfaces/` (never in component files), mandatory JSDoc on exports, no class components, and mandatory grepping for existing logic/utilities before writing new code (with `jscpd` duplication checks).

Provides a dedicated reference guide per SOLID letter (SRP file-splitting, OCP composition/render-props, LSP contract compliance, ISP role-based props/context, DIP constructor injection via Context) plus 10 ready-to-copy templates covering components, hooks, services, stores, validators, factories, and tests. This is a cross-cutting code-quality skill, not a feature skill — for the React APIs themselves see react-19, react-state, react-forms, and react-tanstack-router. </objective>

SOLID React - Component Architecture

Codebase Analysis (MANDATORY)

**Before ANY implementation:** 1. Explore project structure to understand architecture 2. Read existing related files to follow established patterns 3. Identify naming conventions, coding style, and patterns used 4. Understand data flow and dependencies

DRY - Reuse or Create Shared (MANDATORY)

**Before writing ANY new code:** 1. **Grep the codebase** for similar function names, patterns, or logic 2. Check shared locations: `modules/cores/lib/`, `modules/cores/components/`, `modules/cores/hooks/` 3. If similar code exists → extend/reuse instead of duplicate 4. If code will be used by 2+ features → create it in `modules/cores/` directly 5. Extract repeated logic (3+ occurrences) into shared helpers 6. Run `npx jscpd ./src --threshold 3` after creating new files

---

Agent Workflow (MANDATORY)

Before ANY implementation, spawn 3 agents in parallel, one `Agent` call each with a `name`:

1. **fuse-ai-pilot:explore-codebase** - Analyze project structure and existing patterns 2. **fuse-ai-pilot:research-expert** - Verify latest docs for all stack technologies 3. **mcp__context7__query-docs** - Check integration compatibility

After implementation, run **fuse-ai-pilot:sniper** for validation.

---

Absolute Rules (MANDATORY)

1. Source-file size ceiling

• Source files must not exceed `FUSE_SOLID_MAX_LINES` - the hook's ceiling is the only authority
• Split by responsibility when cohesion drops (components via composition, hooks, services)

2. Modular Architecture

See `references/architecture-patterns.md` for complete structure with feature modules and cores directory.

3. JSDoc Mandatory

/**
 * Fetch user by ID from API.
 *
 * @param id - User unique identifier
 * @returns User object or null if not found
 */
export async function getUserById(id: string): Promise<User | null>

4. Interfaces Separated

modules/[feature]/src/interfaces/
├── user.interface.ts
├── post.interface.ts
└── api.interface.ts

**NEVER put interfaces in component files.**

---

SOLID Principles (Detailed Guides)

Each SOLID principle has a dedicated reference guide:

1. **`references/single-responsibility.md`** - One function = one reason to change

• Responsibility-based splitting within `FUSE_SOLID_MAX_LINES`
• Component composition patterns
• Split strategy

2. **`references/open-closed.md`** - Extend via composition, not modification

• Plugin architecture patterns
• Render props and slots
• Strategy patterns

3. **`references/liskov-substitution.md`** - Contract compliance & behavioral subtyping

• Interface contracts
• Swappable implementations
• Testing compliance

4. **`references/interface-segregation.md`** - Many focused interfaces beat one fat interface

• Role-based interfaces
• Props segregation
• Context splitting

5. **`references/dependency-inversion.md`** - Depend on abstractions, not implementations

• Constructor injection patterns
• Factory patterns
• Context for DI

See `references/solid-principles.md` for overview and quick reference.

---

Code Templates

Ready-to-copy code in `references/templates/`:

| Template | Usage | |----------|-------| | `component.md` | React functional component | | `hook.md` | Custom hook with TanStack Query | | `service.md` | Service with dependency injection | | `store.md` | Zustand store with persistence (max 40 lines, owner rule) | | `interface.md` | TypeScript interfaces | | `validator.md` | Zod validation schemas | | `factory.md` | Factory pattern | | `adapter.md` | Adapter pattern | | `error.md` | Custom error classes | | `test.md` | Vitest + Testing Library |

Every template stays within `FUSE_SOLID_MAX_LINES`.

---

Response Guidelines

1. **Research first** - MANDATORY: Search Context7 + Exa before ANY code 2. **Show complete code** - Working examples, not snippets 3. **Explain decisions** - Why this pattern over alternatives 4. **Include tests** - Always suggest test cases 5. **Handle errors** - Never ignore, use error boundaries 6. **Type everything** - Full TypeScript, no `any` 7. **Document code** - JSDoc for complex functions

---

Forbidden

• Coding without researching docs first (ALWAYS research)
• Using outdated APIs without checking curre