Format ADR-lite
Chaque décision suit une structure compacte :
| Section | Description |
|---|---|
| Contexte | Pourquoi cette décision est nécessaire |
| Décision | Ce qui a été décidé |
| Pourquoi | La raison la plus forte, en une ligne |
| Face à | 3 alternatives envisagées maximum |
| Implique | Conséquences et zones impactées |
Pour les décisions complexes, un format étendu ajoute une section Compromis.
Fonctions intelligentes
Inférence automatique des alternatives
Si tu n’écris que la décision, l’IA infère 1-2 alternatives typiques :
/note-decide Utiliser PostgreSQL pour le service utilisateursL’IA ajoute : Face à MongoDB, MySQL — car ce sont les alternatives typiques pour le choix d’une base de données.
Chaînes de décisions
Le système cherche dans les notes de décision existantes. Si ta nouvelle décision en remplace une ancienne, il crée un lien « Remplace » :
Remplace : « Utiliser MongoDB pour le service utilisateurs » (10 février)Cela construit un historique de décisions que tu peux remonter.
Détection de doublons
Avant de créer une nouvelle note, /note-decide cherche les décisions antérieures liées et te prévient si une décision similaire existe déjà.
Guidelines pour le titre
Les bons titres sont actionnables et spécifiques :
- « Utiliser JWT pour l’auth » (pas « Authentification »)
- « Déployer sur Fly.io » (pas « Déploiement »)
- « Passer de REST à GraphQL » (pas « API »)
Quand utiliser /note-decide
Utilise cette commande quand tu veux enregistrer pourquoi tu as choisi quelque chose, pas seulement ce que tu as choisi. Le journal de décisions devient inestimable quand :
- Un nouveau membre de l’équipe demande « pourquoi on l’a fait comme ça ? »
- Tu dois réviser une décision plusieurs mois après
- Tu veux retracer comment ton architecture a évolué