ADR-lite-Format
Jede Entscheidung folgt einer kompakten Struktur:
| Abschnitt | Beschreibung |
|---|---|
| Kontext | Warum diese Entscheidung nötig ist |
| Entscheidung | Was entschieden wurde |
| Warum | Die einzelne stärkste Begründung |
| Statt | Max. 3 erwogene Alternativen |
| Folgen | Konsequenzen und betroffene Bereiche |
Für komplexe Entscheidungen ergänzt das erweiterte Format einen Kompromisse-Abschnitt.
Smarte Features
Auto-Alternativen
Wenn du nur die Entscheidung nennst, erkennt KI 1–2 typische Alternativen:
/note-decide PostgreSQL für den User-Service nutzenKI ergänzt: Statt MongoDB, MySQL — weil das die üblichen Alternativen bei einer Datenbank-Wahl sind.
Entscheidungsketten
Das System sucht in vorhandenen Entscheidungs-Notizen. Wenn deine neue Entscheidung eine alte ablöst, wird ein „Ersetzt”-Link angelegt:
Ersetzt: „MongoDB für den User-Service nutzen" (10. Feb.)So baust du eine Entscheidungs-Historie auf, die du zurückverfolgen kannst.
Duplikat-Erkennung
Vor dem Anlegen einer neuen Notiz sucht /note-decide nach verwandten früheren Entscheidungen und warnt dich, falls eine ähnliche Entscheidung bereits existiert.
Titel-Richtlinien
Gute Titel sind konkret und umsetzbar:
- „JWT für Auth nutzen” (nicht „Authentifizierung”)
- „Auf Fly.io deployen” (nicht „Deployment”)
- „Von REST auf GraphQL wechseln” (nicht „API”)
Wann /note-decide nutzen
Nutze es, wenn du das Warum deiner Wahl festhalten willst, nicht nur das Was. Das Entscheidungs-Log wird unbezahlbar, wenn:
- Ein neues Teammitglied fragt: „Warum machen wir’s so?”
- Du eine Entscheidung Monate später wieder aufgreifen musst
- Du nachvollziehen willst, wie deine Architektur sich entwickelt hat