Générateur de Documentation de Projet
Générez une documentation de projet structurée en analysant le code source. Produit des documents qui reflètent le code réel, et non une architecture idéale.
Quand utiliser
- Un nouveau projet nécessite une documentation initiale
- La documentation est manquante ou obsolète
- Pour intégrer quelqu'un au codebase
- Après une refactorisation, pour rafraîchir la documentation
Workflow
1. Détecter le type de projet
Analysez la racine du projet pour déterminer de quel type de projet il s'agit :
| Indicateur | Type de projet |
|---|---|
wrangler.jsonc / wrangler.toml | Cloudflare Worker |
vite.config.ts + src/App.tsx | React SPA |
astro.config.mjs | Site Astro |
next.config.js | Application Next.js |
package.json avec hono | API Hono |
src/index.ts avec Hono | Serveur API |
drizzle.config.ts | Possède une couche base de données |
schema.ts ou schema/ | Possède un schéma de base de données |
pyproject.toml / setup.py | Projet Python |
Cargo.toml | Projet Rust |
2. Demander quoi générer
Quels documents dois-je générer ?
1. ARCHITECTURE.md — vue d'ensemble du système, stack, structure des répertoires, flux clés
2. API_ENDPOINTS.md — routes, méthodes, paramètres, formes de réponse, authentification
3. DATABASE_SCHEMA.md — tables, relations, migrations, index
4. Tout ce qui précède
Proposez uniquement les documents qui correspondent au projet. Ne proposez pas API_ENDPOINTS.md pour un site statique. Ne proposez pas DATABASE_SCHEMA.md s'il n'y a pas de base de données.
3. Analyser le codebase
Pour chaque document demandé, lisez les fichiers sources pertinents :
ARCHITECTURE.md — analysez :
package.json/pyproject.toml(stack, dépendances)- Points d'entrée (
src/index.ts,src/main.tsx,src/App.tsx) - Fichiers de configuration (
wrangler.jsonc,vite.config.ts,tsconfig.json) - Structure des répertoires (2 premiers niveaux)
- Modules clés et leurs exports
API_ENDPOINTS.md — analysez :
- Fichiers de routes (
src/routes/,src/api/, ou en ligne dans index) - Fichiers middleware (authentification, CORS, journalisation)
- Types de requête/réponse ou schémas Zod
- Modèles de gestion des erreurs
DATABASE_SCHEMA.md — analysez :
- Fichiers de schéma Drizzle (
src/db/schema.ts,src/schema/) - Fichiers de migration (
drizzle/,migrations/) - Fichiers SQL bruts s'ils existent
- Fichiers de seed s'ils existent
4. Générer la documentation
Écrivez chaque document dans docs/ (créez le répertoire s'il n'existe pas). Si le projet contient déjà des documents, proposez de les mettre à jour plutôt que de les écraser.
Pour les petits projets sans répertoire docs/, écrivez à la racine du projet.
Modèles de documents
ARCHITECTURE.md
# Architecture
## Vue d'ensemble
[Un paragraphe : ce que fait ce projet et comment il est structuré]
## Stack
| Couche | Technologie | Version |
|-------|-----------|---------|
| Runtime | [ex. Cloudflare Workers] | — |
| Framework | [ex. Hono] | [version] |
| Base de données | [ex. D1 (SQLite)] | — |
| ORM | [ex. Drizzle] | [version] |
| Frontend | [ex. React 19] | [version] |
| Styling | [ex. Tailwind v4] | [version] |
## Structure des répertoires
[Arbre annoté — 2 premiers niveaux avec commentaires sur l'objectif]
## Flux clés
### [Flux 1 : ex. "Authentification utilisateur"]
[Étape par étape : requête → middleware → gestionnaire → base de données → réponse]
### [Flux 2 : ex. "Pipeline de traitement de données"]
[Étape par étape à travers le système]
## Configuration
[Fichiers de configuration clés et ce qu'ils contrôlent]
## Déploiement
[Comment déployer, variables d'environnement nécessaires, commandes de build]
API_ENDPOINTS.md
# Points d'accès API
## URL de base
[ex. `https://api.example.com` ou relatif `/api`]
## Authentification
[Méthode : jeton Bearer, cookie de session, clé API, aucune]
[D'où viennent les jetons, comment les obtenir]
## Points d'accès
### [Groupe : ex. Utilisateurs]
#### `GET /api/users`
- **Auth** : Requise
- **Paramètres** : `?page=1&limit=20`
- **Réponse** : `{ users: User[], total: number }`
#### `POST /api/users`
- **Auth** : Requise (admin)
- **Corps** : `{ name: string, email: string }`
- **Réponse** : `{ user: User }` (201)
- **Erreurs** : 400 (validation), 409 (email en double)
[Répéter pour chaque point d'accès]
## Format d'erreur
[Forme standard de réponse d'erreur]
## Limites de débit
[Si applicable]
DATABASE_SCHEMA.md
# Schéma de base de données
## Moteur
[ex. Cloudflare D1 (SQLite), PostgreSQL, MySQL]
## Tables
### `users`
| Colonne | Type | Contraintes | Description |
|--------|------|-------------|-------------|
| id | TEXT | PK | UUID |
| email | TEXT | UNIQUE, NOT NULL | Email utilisateur |
| name | TEXT | NOT NULL | Nom d'affichage |
| created_at | TEXT | NOT NULL, DEFAULT now | Horodatage ISO |
### `posts`
[Même format]
## Relations
[Clés étrangères, modèles de jointure, règles de cascade]
## Index
[Index non primaires et pourquoi ils existent]
## Migrations
- Générer : `npx drizzle-kit generate`
- Appliquer en local : `npx wrangler d1 migrations apply DB --local`
- Appliquer à distance : `npx wrangler d1 migrations apply DB --remote`
## Données de seed
[Référence au script de seed s'il existe]
Règles de qualité
- Documentez ce qui existe, pas ce qui est planifié — lisez le code réel, n'inventez pas de points d'accès ou de tables
- Incluez les versions — extrayez-les de package.json / lock files, pas de mémoire
- Montrez les vrais formats de réponse — copiez-les à partir des types TypeScript ou des schémas Zod dans le code
- Gardez-le lisible — tableaux plutôt que paragraphes, blocs de code plutôt que prose
- Ne dupliquez pas CLAUDE.md — si des informations d'architecture sont déjà dans CLAUDE.md, déplacez-les dans ARCHITECTURE.md ou faites-y référence
- Signalez les lacunes — si vous trouvez des routes non documentées ou des tables sans objectif clair, notez-les avec
<!-- TODO: documenter l'objectif -->
Mise à jour des documents existants
Si des documents existent déjà :
- Lisez le document existant
- Comparez-le au codebase actuel
- Montrez à l'utilisateur ce qui a changé (nouveaux points d'accès, tables supprimées, stack mis à jour)
- Appliquez les mises à jour en préservant les notes ou sections écrites à la main
N'écrasez jamais silencieusement le contenu personnalisé que l'utilisateur a ajouté à ses documents.