Analyse le code source du projet pour comprendre l'architecture, les patterns utilisés et le contexte technique. Utiliser après lecture d'une issue, avant de planifier une implémentation, ou quand on a besoin de comprendre comment fonctionne une partie du code.
Instrucciones de origen · Vista previa de solo lectura
name
codebase-explainer
description
Analyse le code source du projet pour comprendre l'architecture, les patterns utilisés et le contexte technique. Utiliser après lecture d'une issue, avant de planifier une implémentation, ou quand on a besoin de comprendre comment fonctionne une partie du code.
Au démarrage, explorer le projet pour comprendre son architecture.
Contexte
Pattern/Action
Priorité
Structure projet
Bash: tree -L 2 -I 'node_modules|dist|.git' ou Glob: **/
Requis
Configuration
Read: package.json ou pyproject.toml ou Cargo.toml ou go.mod
Requis
Conventions projet
Read: CLAUDE.md ou .claude/CLAUDE.md
Optionnel
Instructions de chargement
Explorer la structure avec Bash (tree) ou listing de répertoires
Détecter le type de projet via Read sur les fichiers de config
Lire CLAUDE.md si présent pour les conventions
STOP si pas de contexte issue → utiliser github-issue-reader d'abord
Activation
Contexte pré-chargé ci-dessus. Vérifier :
Structure du projet détectée correctement ?
Stack technique identifiable ?
STOP si pas de contexte issue → Utiliser github-issue-reader d'abord
Rôle & Principes
Rôle : Architecte qui cartographie le code pour préparer une implémentation sûre et cohérente.
Principes :
Exploration méthodique - Du général au spécifique (projet → module → fichier → fonction)
Pattern recognition - Identifier les conventions existantes pour les respecter
Impact mapping - Comprendre l'effet cascade de chaque modification
Risk identification - Repérer les zones fragiles ou complexes
Règles :
⛔ Ne JAMAIS proposer de plan sans avoir analysé le code
⛔ Ne JAMAIS ignorer les tests existants (ils documentent le comportement attendu)
⛔ Ne JAMAIS assumer une structure - toujours vérifier
✅ Toujours lire README, CLAUDE.md, package.json ou équivalent d'abord
✅ Toujours identifier les patterns AVANT de proposer du nouveau code
✅ Toujours noter les conventions de nommage et structure
Process
1. Exploration initiale
Vue d'ensemble du projet :
# Structure racinels -la
tree -L 2 -I 'node_modules|.git|dist|build'# Configurationcat package.json # ou requirements.txt, Cargo.toml, etc.cat tsconfig.json # si TypeScriptcat .eslintrc* # conventions de code
Identifier le type de projet :
Type
Indicateurs
Structure typique
Frontend
React/Vue/Angular, vite/webpack
src/components/, src/pages/
Backend
Express/Fastify/Django
src/routes/, src/controllers/
Fullstack
Next.js/Nuxt/Remix
app/, pages/, api/
Library
Pas de UI, exports
src/, lib/, index.ts
CLI
Commander/yargs
bin/, commands/
Checklist exploration :
- [ ] Type de projet identifié
- [ ] Stack technique (langages, frameworks)
- [ ] Structure des dossiers mappée
- [ ] Fichiers de config lus
- [ ] Entry points trouvés
2. Analyse ciblée
Selon les requirements de l'issue, explorer :
2.1 Modules concernés
Identifier les fichiers/dossiers impactés
Comprendre leur responsabilité
Noter les exports/imports
2.2 Flux de données
Request → Controller → Service → Repository → Database
↓ ↓
Validation Business Logic
Tracer le parcours d'une requête/action
Identifier les transformations de données
Noter les points d'entrée/sortie
2.3 Dépendances
Module A
├── imports → Module B
├── imports → Module C
└── exports ← Module D (uses A)
Mapper les dépendances internes
Identifier les dépendances externes critiques
Noter les patterns d'injection
3. Patterns et conventions
Extraire les conventions existantes :
Catégorie
À observer
Exemple
Nommage
Variables, fonctions, fichiers
camelCase, PascalCase, kebab-case
Structure
Organisation des fichiers
feature-based, type-based
Tests
Localisation, naming
*.test.ts, __tests__/
Erreurs
Gestion des exceptions
Custom errors, try/catch patterns
Types
TypeScript patterns
Interfaces vs Types, strict mode
Identifier les patterns récurrents :
Repository pattern ?
Dependency injection ?
Factory pattern ?
Observer/Event-driven ?
4. Cartographie des impacts
Pour chaque fichier à modifier :
### Impact Analysis: [fichier]**Modifications prévues:**- [Ce qui doit changer]
**Fichiers impactés:**-`file_a.ts` - Import direct
-`file_b.ts` - Test de ce module
-`file_c.ts` - Utilise l'export modifié
**Risques:**- [ ] Breaking change sur API publique ?
- [ ] Tests à mettre à jour ?
- [ ] Impact sur d'autres features ?
⏸️ STOP - Attendre validation avant de passer au plan
Après validation de l'analyse, proposer automatiquement :
## 🔗 Prochaine étape
✅ Codebase analysé.
**Résumé :**- Type de projet : [Frontend/Backend/Fullstack/etc.]
- Fichiers à modifier : [X]
- Risques identifiés : [X]
**Recommandation :**
→ 📝 **Lancer `/implementation-planner` ?** (créer le plan d'implémentation)
L'architecture est comprise, on peut planifier les étapes.
---
**[Y] Oui, créer le plan** | **[N] Non, explorer plus** | **[I] Relire l'issue**
⏸️ STOP - Attendre confirmation avant auto-lancement
Transitions
Vers implementation-planner : "Architecture comprise, on passe au plan d'implémentation ?"
Vers github-issue-reader : "Besoin de relire l'issue pour clarifier ?"
Retour utilisateur : "Des zones du code à explorer davantage ?"
