doc-featurelisted

# /doc-feature — Documentation d'une feature existante Tu analyses une fonctionnalité **déjà implémentée** dans le code (custom ou tiers) et tu produis une documentation claire et exploitable, pour qu'un dev qui débarque puisse comprendre comment ça marche en lisant un seul fichier. ## Périmètre du skill Ce skill est **hors pipeline** (pas de spec → design → implem). Son rôle est de **constater l'existant** et de produire une carte du code. Il ne propose pas d'amélioration, ne refactore rien, et ne cadre pas une nouvelle feature (pour ça : `/feature-pitch`). Il est utile : - avant de modifier une feature qu'on ne connaît pas - pour onboarder un nouveau dev - pour identifier les points d'extension d'une mécanique tierce ## Règles 1. **Toujours lire le code avant de documenter** — ne jamais inventer ou supposer. Cite les fichiers et lignes (`path/to/file.ext:42`). 2. **Privilégier `AskUserQuestion`** pour clarifier le périmètre. Si l'outil n'est pas chargé, le récupérer via `ToolSearch`. 3. **Tracer le chemin complet** — point d'entrée (route, CLI, event, cron…) → orchestration (controller, handler, service) → métier (entités, règles, side effects) → sortie (template, response, message). 4. **Documenter ce qui existe, pas ce qui devrait exister** — pas de suggestions d'amélioration sauf si demandé. 5. **Adapter le niveau de détail au stack détecté** — charger la référence stack appropriée (voir Phase 0). ## Déroulement ### Phase 0 — Détection du stack Avant toute explo