Sortie structurée
Chaque rapport de bug suit cette structure :
- Titre — résumé concis (8 mots maximum)
- Ce qui se passe — description du comportement du bug
- Contexte git — branche actuelle et changements récents
- Étapes de reproduction — inférées depuis la description ou placeholders
- Attendu vs Réel — format de comparaison
Détection automatique de la severity
Le système infère la severity depuis ta description :
| Severity | Mots déclencheurs | Exemple |
|---|---|---|
| Critical | crash, data loss, security, down, blocks | « L’app plante au démarrage » |
| High | broken, fails, can’t, regression | « Le formulaire de login échoue à la validation » |
| Medium | wrong, incorrect, unexpected, slow | « L’API renvoie des données incorrectes » |
| Low | minor, cosmetic, typo, alignment | « Bouton mal aligné en mobile » |
Intégration avec git
Un seul appel Bash capture :
- Le nom de la branche actuelle
- Un résumé des changements récents (derniers commits)
- Les fichiers modifiés pertinents pour la zone du bug
Ce contexte est inclus automatiquement dans le rapport de bug, ainsi le prochain développeur peut voir quel code a changé près du bug.
Quand utiliser /note-bug
Utilise /note-bug au lieu de /note quand tu veux :
- Étiquetage automatique de la severity
- Contexte git dans le rapport
- Format structuré pour les étapes de reproduction
- Codage couleur rose pour l’identifier facilement