Bricks Intel MCP — Annuaire dynamique du monorepo¶

Un MCP server bricks-intel est disponible. Il indexe le monorepo et expose des tools pour savoir ce qui existe dans la codebase.

Les conventions (quoi faire / ne pas faire) sont dans les cursor rules — front (front-conventions.mdc, front-domain-map.mdc), back (api-conventions.mdc, domain-map.mdc), et cross-cutting (generic-monorepo-rules.mdc). Bricks-intel sert a verifier ce qui existe avant de creer quelque chose de nouveau — composant, hook, store, endpoint, module.

Reflexe : verifier avant de creer¶

Quand tu dois creer un composant, un hook, un store ou un endpoint → appelle bricks-intel d'abord pour verifier qu'il n'existe pas deja ou qu'un equivalent existe.

Quand utiliser quel tool¶

Avant d'utiliser un composant uimmo¶

→ bricks-intel:get-component-usage("NomDuComposant") pour vérifier : - S'il est deprecated → ne JAMAIS utiliser, suivre deprecationNote - Combien de fois il est utilisé (indication de maturité) - Des fichiers exemples

Avant de créer un hook ou un service¶

→ bricks-intel:get-hooks() pour lister tous les hooks existants → bricks-intel:get-hooks(query: "wallet", kind: "mutation") pour chercher par nom/type/module → Kinds disponibles : query, mutation, infinite-query, refresh, utility

Avant de créer ou modifier un module API¶

→ bricks-intel:get-module-structure("nom-du-module") pour voir un module existant comme référence (structure, couches, stack Kysely+Zod vs legacy)

Avant d'ajouter ou modifier un endpoint¶

→ bricks-intel:get-endpoint-schema pour voir les endpoints existants du même domaine

→ bricks-intel:get-routes() pour voir l'arbre Expo Router complet (layouts, groups, guards) → bricks-intel:get-routes("wallet") pour filtrer par section → bricks-intel:get-migration-status() pour savoir si un écran est dans screens/ (legacy) ou modules/ (migré)

Avant de créer ou modifier du state client¶

→ bricks-intel:get-stores() pour lister tous les Zustand stores existants → bricks-intel:get-stores(query: "portfolio") pour chercher par nom/module

Pour analyser les patterns d'un dev ou d'un module¶

→ bricks-intel:analyze-patterns(author: "Hugo") pour voir les patterns récurrents d'un dev → bricks-intel:analyze-patterns(path: "projects/front-mobile-app/src/modules/wallet") pour un module

Pour avoir la vue complète d'un module front¶

→ bricks-intel:get-module-map("wallet") — screens, hooks, stores, composants, endpoints, dépendances d'un module en un appel

Pour évaluer l'impact d'un changement¶

→ bricks-intel:get-impact-map(keywords: ["transaction", "filter"]) — montre toutes les zones touchées (front, back, shared)

Pour comprendre les dépendances entre packages¶

→ bricks-intel:get-dependency-graph("nom-du-package")

Si tu ne sais pas où chercher¶

→ bricks-intel:search("mot-clé") — cherche dans les conventions, modules, endpoints, composants, packages, hooks, routes et stores en un seul appel

Ordre de priorité pour le contexte¶

Cursor rules — front (front-conventions, front-domain-map), back (api-conventions, domain-map), cross-cutting (generic-monorepo-rules). Toujours chargées
Bricks Intel MCP — annuaire dynamique : ce qui existe, où, combien de fois utilisé
Grep / exploration — seulement si les deux précédents ne suffisent pas