Analyse ce projet et génère un fichier CLAUDE.md complet à la racine du dépôt.

<instructions>
Commence par explorer le projet pour comprendre sa structure:
1. Lis le package.json (ou Cargo.toml, pyproject.toml, etc.) pour identifier la stack
2. Lis les fichiers de configuration (tsconfig, eslint, prettier, etc.)
3. Explore la structure des dossiers (src/, app/, tests/, etc.)
4. Identifie les scripts disponibles (dev, build, test, lint)
5. Cherche les patterns de code existants (conventions de nommage, style d'imports)

Ensuite, génère un CLAUDE.md avec les sections suivantes:
</instructions>

<structure-claude-md>
# CLAUDE.md

## Vue d'ensemble du projet
- Description en une phrase
- Stack technique complète (framework, langage, ORM, etc.)
- Architecture (monorepo/single-app, microservices, etc.)

## Commandes
```bash
# Développement
[commande dev]

# Build
[commande build]

# Tests
[commande test]

# Lint
[commande lint]

# Autres commandes utiles
[commandes spécifiques au projet]
```

## Architecture
- Structure des dossiers avec description de chaque dossier principal
- Flux de données (comment les composants communiquent)
- Patterns utilisés (si identifiables)

## Conventions de code
- Style de nommage (fichiers, variables, composants)
- Structure des imports (ordre, groupement)
- Patterns spécifiques au projet (ex: composants serveur vs client)
- Ce qu'il ne faut PAS faire (anti-patterns identifiés)

## Variables d'environnement
- Liste des variables nécessaires (sans les valeurs)
- Fichier(s) de référence (.env.example, etc.)

## Tests
- Framework utilisé
- Convention de nommage des tests
- Commande pour lancer un test spécifique
- Couverture minimale attendue (si configurée)
</structure-claude-md>

<regles-qualite>
- Sois factuel: ne documente que ce qui EXISTE dans le projet, pas ce qui "devrait" exister
- Sois concis: chaque section doit tenir en quelques lignes, pas de paragraphes longs
- Sois actionnable: chaque information doit aider Claude Code à écrire du meilleur code
- Inclus les commandes exactes, pas de placeholders génériques
- Si le projet a des particularités (flags de build spéciaux, ordre de démarrage), documente-les
- N'inclus PAS de valeurs de secrets ou de tokens
</regles-qualite>

<exemples-bons-mauvais>
Mauvais: "Le projet utilise React pour le frontend"
Bon: "Frontend React 19 avec App Router Next.js 16, composants serveur par défaut"

Mauvais: "Lancez les tests avec la commande de test"
Bon: "bun run test (Vitest), bunx vitest run src/lib/auth.test.ts pour un fichier"

Mauvais: "Suivez les conventions de nommage standard"
Bon: "Composants: PascalCase.tsx, utilitaires: camelCase.ts, routes API: app/api/[resource]/route.ts"
</exemples-bons-mauvais>