Feature Doc Generator

Transformer une feature concrète d'un projet en documentation de référence générique et réutilisable, prête à être poussée à Claude Code pour implémenter la même feature dans un autre projet.

Workflow

1. Identifier la feature — Comprendre ce qu'on documente
2. Analyser le code source — Explorer le projet courant
3. Poser des questions complémentaires — Combler les trous
4. Générer la documentation — Produire les fichiers Markdown par couche
5. Réviser et finaliser — Valider avec l'utilisateur

Étape 1 : Identifier la feature

Demander à l'utilisateur :

• Le nom de la feature (ex: "Gestion de fichiers audio et transcription")
• Une description en une phrase
• Les technologies principales impliquées (si connues)

Étape 2 : Analyser le code source

Explorer le projet courant pour extraire l'information technique :

1. Structure du projet — Arborescence des dossiers pertinents
2. Back-end — Routes, modèles, services, migrations, config
3. Front-end — Composants UI, state management, appels API, routing
4. APIs et intégrations — Clients API externes, config fournisseurs, webhooks
5. Configuration — Variables d'environnement, fichiers de config, packages

Pour chaque couche, noter les patterns architecturaux, librairies clés, décisions techniques, et pièges résolus.

Étape 3 : Questions complémentaires

Après l'analyse du code, poser des questions ciblées sur ce qui ne peut pas être déduit :

• Pourquoi tel fournisseur a été choisi
• Limitations connues et workarounds
• Considérations de coût/performance
• Alternatives évaluées et rejetées
• Edge cases importants découverts en production

Étape 4 : Générer la documentation

Créer un dossier docs/feature-references/<nom-de-la-feature>/ dans le projet.

Fichiers à produire

Consulter le template de référence correspondant avant de rédiger chaque fichier :

Adaptation

Ne pas créer les fichiers non pertinents (ex: pas de frontend.md pour une feature sans front-end, pas de api-providers.md sans API externe).

Règles de rédaction

• Générique : Ne jamais mentionner le nom du projet source. Utiliser "le projet", "l'application"
• Exemples de code : Inclure des snippets représentatifs mais renommer les éléments spécifiques au projet
• Expliquer le pourquoi : Justifier chaque décision technique
• Lister les alternatives : Mentionner les autres approches possibles
• Inclure les gotchas : Documenter les pièges et comment les éviter
• Actionnable : Un développeur ou Claude Code doit pouvoir suivre le guide et implémenter la feature

Étape 5 : Réviser et finaliser

Présenter un résumé des documents générés. Demander s'il y a des ajustements ou des informations manquantes. Itérer si nécessaire.