uix

Structure et règles back-end NestJS (DDD + Clean Architecture). À utiliser pour créer ou modifier du code back-end — use-cases, controllers, repositories, services infra, mappers, errors — ou pour savoir dans quelle couche placer un fichier.

Simplifies code for clarity. Use when refactoring code for clarity without changing behavior. Use when code works but is harder to read, maintain, or extend than it should be. Use when reviewing code that has accumulated unnecessary complexity.

Guides systematic root-cause debugging. Use when tests fail, builds break, behavior doesn't match expectations, or you encounter any unexpected error. Use when you need a systematic approach to finding and fixing the root cause rather than guessing.

Builds production-quality UIs. Use when building or modifying user-facing interfaces. Use when creating components, implementing layouts, managing state, or when the output needs to look and feel production-quality rather than AI-generated.

Delivers changes incrementally. Use when implementing any feature or change that touches more than one file. Use when you're about to write a large amount of code at once, or when a task feels too big to land in one step.

Optimizes application performance. Use when performance requirements exist, when you suspect performance regressions, or when Core Web Vitals or load times need improvement. Use when profiling reveals bottlenecks that need fixing.

Breaks work into ordered tasks. Use when you have a spec or clear requirements and need to break work into implementable tasks. Use when a task feels too large to start, when you need to estimate scope, or when parallel work is possible.

Hardens code against vulnerabilities. Use when handling user input, authentication, data storage, or external integrations. Use when building any feature that accepts untrusted data, manages user sessions, or interacts with third-party services.

Manages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".

Grounds every implementation decision in official documentation. Use when you want authoritative, source-cited code free from outdated patterns. Use when building with any framework or library where correctness matters.

Revue de code multi-axes (correctness, lisibilité, architecture, sécurité, performance) contre les conventions Arolitec (back/front, SOLID, clean code, qualité TS, dépendances, Turborepo, Docker). À utiliser avant tout merge pour relire un diff, une PR ou des fichiers — qu'ils soient écrits par toi, un autre agent ou un humain. Déclencher sur "review", "relis", "vérifie les conventions", "code review".

Configs ESLint / Prettier / TypeScript / Vitest partagées du monorepo (approche Turborepo) et règles TypeScript transversales. À utiliser pour créer/modifier les configs lint, tsconfig ou vitest, ajouter un profil (nest/react/vite), ou vérifier le respect des règles TS (strict, pas de any/as/@ts-ignore, import type).

Gestion des dépendances du monorepo via le catalog pnpm (source de vérité unique des versions). À utiliser pour ajouter, mettre à jour ou auditer une dépendance, ou pour décider entre catalog et version locale dans un package.json.

Conventions Docker et Docker Compose du monorepo (images multi-stage légères et sécurisées, compose dev/staging, .env.example). À utiliser pour écrire ou réviser un Dockerfile, un docker-compose.yml ou un .dockerignore d'une app déployable.

Structure et règles front-end React + React Router v7 (architecture Feature-based). À utiliser pour créer ou modifier du code front — features, components, hooks, mappers, validators, et la couche servers (service/loader/action) — ou pour savoir où placer un fichier front.

Conventions de tests unitaires avec Vitest — tester le comportement (input → output) et non l'implémentation, couvrir cases / edge cases et toutes les branches, et co-localiser les tests dans des dossiers __tests__ miroir de la structure. À utiliser pour écrire, relire ou organiser des tests unitaires (.spec.ts) côté back (use-cases, mappers, validators) ou front.