codebase-explainer

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.

Jump to install

Repository: majiayu000/claude-skill-registry
Last source activity: June 23, 2026 at 12:15
Detected SKILL.md language: French
Stars: 543
Forks: 85

Install options

The review-first prompt is selected by default. You can switch to a direct command or download a local copy.

Review the source files

Read SKILL.md and any companion files shown by SkillsMP before deciding whether to install.

Back to search Back to installation

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.
model	opus
context	fork
agent	Explore
allowed-tools	["Read","Grep","Glob","Bash"]
user-invocable	false
knowledge	{"core":["../../knowledge/workflows/project-types.csv"],"advanced":["../../knowledge/testing/test-levels-framework.md"],"debugging":["../../knowledge/testing/test-healing-patterns.md"]}

Codebase Explainer

📥 Contexte à charger

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

# Structure racine
ls -la
tree -L 2 -I 'node_modules|.git|dist|build'

# Configuration
cat package.json        # ou requirements.txt, Cargo.toml, etc.
cat tsconfig.json       # si TypeScript
cat .eslintrc*          # conventions de code

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/`

- [ ] Type de projet identifié
- [ ] Stack technique (langages, frameworks)
- [ ] Structure des dossiers mappée
- [ ] Fichiers de config lus
- [ ] Entry points trouvés

Request → Controller → Service → Repository → Database
         ↓                        ↓
      Validation              Business Logic

Module A
  ├── imports → Module B
  ├── imports → Module C
  └── exports ← Module D (uses A)

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

### 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 ?

## Analyse du Codebase

### 🏗️ Architecture

**Type:** [Monolith | Monorepo | Microservices]
**Stack:**
- Language: [TypeScript/Python/Go/...]
- Framework: [Next.js/Express/Django/...]
- Database: [PostgreSQL/MongoDB/...]
- Testing: [Jest/Vitest/Pytest/...]

**Structure:**


### 📁 Fichiers pertinents

| Fichier | Rôle | Modification nécessaire |
|---------|------|------------------------|
| `src/services/user.ts` | Service utilisateur | Oui - Ajouter méthode |
| `src/types/user.ts` | Types User | Oui - Nouveau type |
| `tests/user.test.ts` | Tests unitaires | Oui - Nouveaux tests |

### 🔄 Flux de données


**Pour cette feature:**
1. Entrée: [Point d'entrée]
2. Traitement: [Logique principale]
3. Sortie: [Résultat attendu]

### 📏 Patterns à respecter

**Conventions observées:**
1. Nommage: `[convention]`
2. Structure: `[pattern]`
3. Tests: `[localisation et style]`
4. Erreurs: `[pattern de gestion]`

**Code existant similaire:**
- `src/services/product.ts` - Pattern service à suivre
- `src/types/product.ts` - Pattern type à suivre

### 🔗 Dépendances internes


### ⚠️ Points d'attention

| Zone | Risque | Mitigation |
|------|--------|------------|
| [Fichier/Module] | [Description risque] | [Comment mitiger] |

### 🧪 Tests existants

**Couverture actuelle:**
- `[fichier.test.ts]` - [X] tests, [patterns utilisés]

**Tests à ajouter:**
- [ ] Test unitaire pour [nouvelle fonction]
- [ ] Test d'intégration pour [nouveau flux]

### Validation Codebase Analysis

- [ ] Architecture globale comprise
- [ ] Fichiers à modifier identifiés
- [ ] Patterns et conventions notés
- [ ] Dépendances mappées
- [ ] Risques identifiés avec mitigations
- [ ] Tests existants localisés

**Prêt pour le plan d'implémentation ?** ✅/❌

### ✅ Checklist Output Codebase Analysis

| Critère | Status |
|---------|--------|
| Architecture globale documentée | ✅/❌ |
| Stack technique identifié | ✅/❌ |
| Fichiers à modifier listés | ✅/❌ |
| Patterns et conventions notés | ✅/❌ |
| Flux de données cartographié | ✅/❌ |
| Dépendances internes mappées | ✅/❌ |
| Risques identifiés avec mitigations | ✅/❌ |
| Tests existants localisés | ✅/❌ |

**Score : X/8** → Si < 6, compléter avant transition

## 🔗 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**