Lerne, wie Prompts, schnelle Iteration und Refactoring schwere Design‑Docs in einem Vibe‑Coding‑Workflow ersetzen können—ohne Klarheit, Alignment oder Qualität zu verlieren.
„Vibe‑Coding“ ist eine Art, Software zu bauen, bei der du mit einer Absicht und Beispielen startest und die Implementierung dann durch schnelle Zyklen aus Prompting, Ausführen und Anpassen evolvieren lässt. Statt einen großen Plan vorab zu schreiben, bringst du früh etwas zum Laufen, lernst aus dem, was du siehst, und steuerst den Code auf das gewünschte Ergebnis zu.
Ein Vibe‑Coding‑Workflow sieht so aus:
Das „Vibe“ ist keine Kaffeesatzleserei—es ist schnelles Feedback. Du nutzt Ausführung und Iteration anstelle langer Spekulationsphasen.
KI verschiebt den Aufwand vom Schreiben erschöpfender Dokumentation hin zu klaren, ausführbaren Anweisungen:
Dieser Ansatz passt am besten zu Produktiteration, internen Tools, frühen Feature‑Phasen und Refactors, bei denen der schnellste Weg darin besteht zu bauen und zu lernen.
Er eignet sich weniger, wenn formale Genehmigungen, strikte Compliance, langfristige teamübergreifende Verpflichtungen oder irreversible Architekturentscheidungen nötig sind. In diesen Fällen brauchst du weiterhin eine schriftliche Entscheidungsdokumentation—nur kleiner, präziser und expliziter.
Du lernst, wie du Prompts als leichte Spezifikationen behandelst, Iteration als dein Planungswerkzeug nutzt und dich auf Refactoring und Tests verlässt, um Klarheit zu bewahren—ohne zu schweren Design‑Dokumenten zurückzufallen.
Traditionelle Design‑Docs sollen vor dem Coden Klarheit schaffen. In schnellen Builds erzeugen sie oft das Gegenteil: ein langsames, fragiles Artefakt, das mit dem Lernprozess nicht mithalten kann.
Design‑Docs werden schnell veraltet. Sobald die Implementierung beginnt, entdeckt das Team Randfälle, Bibliotheks‑Eigenheiten, Performance‑Beschränkungen und Integrationsrealitäten, die am ersten Tag nicht offensichtlich waren. Wenn niemand die Dokumentation kontinuierlich aktualisiert (selten), wird sie zur historischen Aufzeichnung statt zur Anleitung.
Sie sind außerdem langsam zu schreiben und langsam zu lesen. Wenn Geschwindigkeit zählt, optimieren Teams fürs Shipping: Das Doc wird „nice to have“, überflogen und dann still ignoriert. Der Aufwand war trotzdem vorhanden—nur ohne Nutzen.
Ein großes Vorab‑Doc kann ein falsches Gefühl des Fortschritts erzeugen: Man fühlt sich „fertig mit dem Design“, bevor die harten Teile konfrontiert wurden.
Die echten Beschränkungen entdeckt man meistens durch Ausprobieren:
Wenn das Doc diese Experimente verzögert, verzögert es den Moment, in dem das Team lernt, was möglich ist.
Schnelle Builds werden von beweglichen Zielen geprägt: Feedback kommt täglich, Prioritäten verschieben sich und die beste Lösung ändert sich, sobald du einen Prototyp siehst. Traditionelle Docs gehen davon aus, dass du die Zukunft detailliert genug vorhersagen kannst, um früh zu verpflichten. Diese Diskrepanz erzeugt Verschwendung—entweder durch Umschreiben von Dokumenten oder indem Arbeit einem veralteten Plan folgen muss.
Das Ziel ist keine Bürokratie; es ist gemeinsames Verständnis: was wir bauen, warum es wichtig ist, was „fertig“ bedeutet und welche Risiken wir beobachten. Der Rest ist nur ein Werkzeug—und in schnellen Builds sind schwere Docs oft das falsche.
Ein traditionelles Design‑Doc versucht die Zukunft vorherzusagen: was du bauen wirst, wie es funktionieren wird und was du tust, wenn sich etwas ändert. Ein ausführbarer Prompt kehrt das um. Er ist eine lebende Spezifikation, die du ausführen, beobachten und überarbeiten kannst.
Anders gesagt: Das „Dokument“ ist kein statisches PDF—es sind die Anweisungen, die zuverlässig den nächsten korrekten Inkrement des Systems erzeugen.
Ziel ist es, deine Absicht unmissverständlich und testbar zu machen. Ein guter ausführbarer Prompt enthält:
Statt langer Prosa beschreibst du die Arbeit so, dass sie direkt Code, Tests oder eine Checkliste erzeugen kann.
Viele Überraschungs‑Reworks passieren, weil Annahmen implizit bleiben. Mache sie im Prompt explizit:
Das zwingt zur frühen Abstimmung und schafft eine sichtbare Entscheidungsgrundlage—ohne den Overhead eines schweren Docs.
Der nützlichste Teil eines Design‑Docs ist oft das Ende: was als abgeschlossen gilt. Setze das direkt in den ausführbaren Prompt, damit es mit der Arbeit mitreist.
Dein Prompt kann z. B. verlangen: bestehende Unit‑Tests, aktualisierte Fehlerbehandlung, Accessibility‑Checks und eine kurze Zusammenfassung der Änderungen. Wenn der Prompt die Spezifikation ist, wird „fertig“ kein Streitpunkt mehr, sondern eine Menge verifizierbarer Ergebnisse, die bei jeder Iteration erneut ausgeführt werden können.
Dieser Workflow funktioniert am besten, wenn Prompting, Ausführen, Review und Rollback eng verbunden sind. Vibe‑Coding‑Plattformen wie Koder.ai sind um diese Schleife herum gebaut: du kannst per Chat Web/Server/Mobile‑Slices iterieren, einen Planungsmodus nutzen, um einen Mikro‑Plan vor Codeänderungen zu bekommen, und Snapshots/Rollback verwenden, wenn eine Iteration schiefgeht. Der praktische Effekt ist weniger „Prompt‑Theater“ und mehr echte, testbare Inkremente.
Traditionelle Design‑Docs versuchen Unsicherheit auf Papier zu „lösen“. Die riskantesten Teile eines Builds sind aber meist die, die sich nicht sauber rationalisieren lassen: Randfälle, Performance‑Bottlenecks, verwirrende UX‑Flows, Drittanbieter‑Eigenheiten und die Art, wie echte Nutzer Formulierungen interpretieren.
Ein Vibe‑Coding‑Workflow behandelt Unsicherheit als etwas, das du durch enge Zyklen „abbrennst“. Anstatt darüber zu debattieren, was passieren könnte, baust du die kleinste Version, die Beweise liefern kann, und passt dann an.
Wähle die kleinste nützliche Scheibe, die trotzdem Ende‑zu‑Ende läuft: UI → API → Daten → Backend. So vermeidest du „perfekte“ Module, die nicht integriert funktionieren.
Beispiel: Wenn du „gespeicherte Suchen“ baust, entwerfe nicht sofort jede Filteroption. Starte mit einem Filter, einem gespeicherten Element, einem Abruf. Wenn diese Scheibe passt, erweitere sie.
Halte Zyklen kurz und explizit:
Ein 30–90‑Minuten‑Timebox erzwingt Klarheit. Ziel ist nicht, das Feature fertigzustellen—sondern das nächste größte Unbekannte zu eliminieren. Kannst du den nächsten Schritt nicht in ein bis zwei Sätzen beschreiben, ist er zu groß.
Wenn du dir unsicher wegen Machbarkeit oder UX bist, erstelle einen schnellen Prototyp. Prototypen sind nicht unbedingt „wegwerfbarer“ Toy‑Code, sofern du sie ehrlich beschriftest und Erwartungen setzt: sie beantworten eine Frage.
Beispiele für gute Prototyp‑Fragen:
Echtes Feedback ist besser als interne Argumente. Deploy hinter einem Feature‑Flag, demo vor einem Stakeholder oder laufe den Flow selbst mit Test‑Daten durch. Jede Schleife sollte ein konkretes Ergebnis liefern: ein bestehender Test, ein funktionierender Screen, eine gemessene Query‑Zeit oder ein klares ‚das verwirrt‘.
Große Design‑Docs versuchen Entscheidungen vorzuziehen. Ein Vibe‑Coding‑Workflow kehrt das um: Du zerlegst die Arbeit während du promptest und erzeugst Mikro‑Pläne, die der Codebasis zufließen und die Reviewer validieren können.
Statt „baue ein Billing‑System“, schreibe einen Prompt, der ein einzelnes Ergebnis und die dazugehörigen Beschränkungen nennt. Ziel ist es, breite Prompts in Aufgaben zu verwandeln, die die Codebasis aufnehmen kann—klein genug, dass die Antwort ohne neue Architektur erfassbar ist.
Eine nützliche Struktur:
Mache Planung zum Pflichtschritt: bitte die KI um einen Schritt‑für‑Schritt‑Plan, bevor du Code generieren lässt. Du suchst keine perfekte Vorhersage—nur eine überprüfbare Route.
Wandle den Plan dann in eine konkrete Checkliste um:
Wenn der Plan diese Punkte nicht benennen kann, ist er zu vage.
Mikro‑Pläne funktionieren am besten, wenn jede Änderung klein genug ist, um schnell reviewed zu werden. Behandle jeden Prompt wie eine PR‑große Scheibe: ein Schema‑Tweak oder ein Endpoint oder ein UI‑Zustandsübergang—dann iteriere.
Eine praktische Regel: Wenn ein Reviewer ein Meeting braucht, um die Änderung zu verstehen, teile sie noch einmal auf.
Für Team‑Konsistenz: speichere wiederverwendbare Prompt‑Vorlagen auf einer kurzen internen Seite (z. B. /playbook/prompts), damit Zerlegung zur Gewohnheit wird und nicht zur persönlichen Auslegung.
Refactoring ist der Moment, in dem „was wir gelernt haben“ zu „was wir meinten“ wird. In einem Vibe‑Coding‑Workflow sind frühe Prompts und Iterationen bewusst explorativ: du shipst eine dünne Scheibe, siehst, wo sie bricht, und entdeckst die echten Beschränkungen. Refactoring ist der Schritt, in dem Design explizit wird—festgehalten in Struktur, Namen, Grenzen und Tests, denen zukünftige Kolleg:innen vertrauen können.
Eine saubere Codebasis erklärt sich selbst. Wenn du eine vage Funktion wie handleThing() in calculateTrialEndDate() umbenennst und in ein Modul BillingRules verschiebst, schreibst du damit ein Design‑Doc in ausführbarer Form.
Gute Refactors sehen oft so aus:
Architekturdiagramme altern schnell. Saubere Schnittstellen altern besser—vor allem, wenn sie durch Tests abgesichert sind, die Verhalten definieren.
Statt einer Box‑und‑Pfeil‑Aufstellung von „Services“ bevorzugst du:
Wenn jemand fragt „Wie funktioniert das?“, ist die Antwort kein Slide‑Deck mehr, sondern die Grenzen im Code und die Tests, die sie durchsetzen.
Plane Refactors, wenn du genug Beweise gesammelt hast: wiederholte Änderungen im selben Bereich, verwirrte Ownership oder Bugs, die auf unklare Grenzen zurückgehen. Prompting und Iteration helfen schnell zu lernen; Refactoring sorgt dafür, dass du diese Lektionen einfräst, sodass der nächste Build von Klarheit ausgeht und nicht von Vermutungen.
Design‑Docs fallen nicht weg, wenn du sie ersetzt—sie werden nur kleiner und signalstärker. Ziel ist, gerade genug schriftlichen Kontext zu behalten, damit das zukünftige Ich (und die Kolleg:innen) verstehen, warum der Code so ist, wie er ist—ohne den Fortschritt einzufrieren.
Führe ein einfaches Verlaufsprotokoll der Prompts, die wichtig waren, und welche Änderungen daraus resultierten. Das kann eine Markdown‑Datei im Repo sein (z. B. /docs/prompt-log.md) oder ein Thread im Issue‑Tracker.
Erfasse:
So wird aus „wir haben der KI vieles gefragt“ eine prüfbare Spur, die Reviews und spätere Refactors unterstützt.
/docs/notes.md für das „Warum"Ziele eine halbe Seite „Warum“ pro Projekt oder Featurebereich an. Kein Spec—mehr so etwas wie:
Wenn jemand fragt „Warum haben wir nicht…?“, sollte die Antwort in zwei Minuten auffindbar sein.
Ein leichtes Issue‑Template ersetzt viele Doc‑Abschnitte. Füge Felder für Scope, Risiken und klare Akzeptanzkriterien („done bedeutet…“) hinzu. Das hilft auch bei KI‑unterstützter Arbeit: du kannst das Issue in Prompts einfügen und Ergebnisse erhalten, die zu den vorgegebenen Grenzen passen.
Wenn es relevant ist, verlinke auf bestehende interne Seiten, statt Inhalte zu duplizieren. Halte Links relativ (z. B. /pricing) und füge sie nur hinzu, wenn sie wirklich helfen, eine Entscheidung zu treffen.
Schnelle Iteration funktioniert nur, wenn alle an denselben Zielen ausgerichtet sind. Der Trick ist, „ein großes Doc, das jeder vergisst“ durch ein paar kleine Rituale und Artefakte zu ersetzen, die Menschen in der Schleife halten—besonders wenn KI beim Code‑Generieren hilft.
Ein Vibe‑Coding‑Workflow schafft keine Rollen ab; er macht sie klarer.
Wenn du für Software promptest, mache diese Owner sichtbar. Beispiel: „Product genehmigt Scope‑Änderungen“, „Design genehmigt Interaktionsänderungen“, „Engineering genehmigt architektonische Änderungen.“ So verhindert du, dass KI‑generierter Schwung Entscheidungen stillschweigend umschreibt.
Statt alle ein 10‑seitiges Doc lesen zu lassen, halte 15–25 Minuten Alignment‑Meetings an Schlüsselpunkten:
Als Ergebnis sollte ein kleines, ausführbares Set an Entscheidungen stehen: was wir jetzt ausliefern, was wir nicht ausliefern und was wir später wieder aufgreifen. Wenn Kontinuität nötig ist, halte sie in einer kurzen Notiz im Repo fest (z. B. /docs/decisions.md) statt in einer ausschweifenden Erzählung.
Pflege eine lebende „Constraints‑Liste“, die sich leicht in Prompts und PR‑Beschreibungen kopieren lässt:
Das wird dein leichtes Dokumentations‑Anker: Wenn der Iterationsdruck steigt, verhindert die Constraints‑Liste, dass die Schleife driftet.
Definiere, wer was genehmigen kann—und wann eskaliert werden muss. Eine einfache Richtlinie wie „Scope/UX/Security‑Änderungen benötigen explizite Freigabe“ verhindert, dass kleine KI‑gestützte Edits sich zu ungeprüften Redesigns summieren.
Wenn du eine Leitsregel willst: je kleiner das Doc, desto strikter die Genehmigungen. So bleibst du schnell, ohne Alignment zu verlieren.
Geschwindigkeit hilft nur, wenn du dem ausgelieferten Code vertrauen kannst. In einem Vibe‑Coding‑Workflow ersetzen Quality‑Gates lange „Genehmigungs“‑Dokumente durch Checks, die bei jeder Änderung laufen.
Formuliere vor dem Prompting eine kleine Menge Akzeptanzkriterien in Alltagssprache: was der Nutzer tun können soll, was „fertig“ bedeutet und was niemals passieren darf. Halte es eng genug, damit ein Reviewer es in Minuten prüfen kann.
Wandle diese Kriterien dann in ausführbare Checks um. Ein hilfreiches Pattern ist, jedes Kriterium in mindestens einen automatisierten Test zu überführen.
Warte nicht, bis das Feature „funktioniert“. Füge Tests hinzu, sobald du den Pfad Ende‑zu‑Ende ausführen kannst:
Wenn du Akzeptanzkriterien hast, bitte die KI, direkt Testfälle daraus zu generieren und bearbeite sie dann für Realismus. Ziel ist Intent‑Coverage, nicht ein riesiges Test‑Monstrum.
Behandle Code‑Review als Design‑ und Safety‑Checkpoint:
Reviewer können die KI auch bitten, „was kann schiefgehen“‑Szenarien vorzuschlagen, aber das Team trifft die endgültige Entscheidung.
Nicht‑funktionale Anforderungen gehen ohne Design‑Docs leicht verloren, also mache sie Teil des Gates:
Halte sie in der PR‑Beschreibung oder als kurze Checkliste, damit sie verifiziert und nicht angenommen werden.
Vibe‑Coding‑Workflows können extrem schnell sein—aber Geschwindigkeit macht es auch leicht, Fehler einzubauen, die erst sichtbar werden, wenn die Codebasis anfängt zu schreien. Die gute Nachricht: Die meisten dieser Fehler sind mit ein paar einfachen Gewohnheiten vermeidbar.
Wenn du mehr Zeit damit verbringst, Prompts zu perfektionieren, als Inkremente auszuliefern, hast du die Design‑Doc‑Paralyse in ein neues Format übertragen.
Praktische Lösung: Timebox Prompts: schreibe einen „gut genug“ Prompt, baue die kleinste Scheibe und verfeinere dann. Halte Prompts ausführbar: Inputs, Outputs und ein kurzer Akzeptanzcheck, damit du sofort validieren kannst.
Schnelle Iterationen begraben oft wichtige Entscheidungen—warum ein Ansatz gewählt wurde, was verworfen wurde und welche Constraints zählten. Später wird oft dasselbe erneut verhandelt oder Annahmen werden unbeabsichtigt gebrochen.
Vermeide das, indem du Entscheidungen festhältst:
/docs/decisions.md mit einer Bullet pro bedeutender Wahl.Schnelles Ausliefern ist nicht gleich nachhaltiges Ausliefern. Wenn jede Iteration Abkürzungen hinzufügt, wird der Workflow langsam, sobald Änderungen riskant werden.
Mach Refactoring zum Teil der Definition of Done: nachdem ein Feature funktioniert, mach eine zusätzliche Runde, um Namen zu vereinfachen, Funktionen zu extrahieren und tote Pfade zu löschen. Wenn Refactoring nicht sicher ist, ist das ein Signal, dass du Tests oder klarere Grenzen brauchst.
Ohne Guardrails kann jede Iteration den Code in eine andere Richtung ziehen—neue Patterns, uneinheitliche Namensgebung, gemischte Ordnerstrukturen.
Verhindere Drift, indem du das System verankerst:
Diese Gewohnheiten halten den Workflow schnell und bewahren Klarheit, Konsistenz und Wartbarkeit.
Das Rollout funktioniert am besten als kontrolliertes Experiment, nicht als firmenweiter Schalter. Wähle eine kleine Arbeitsscheibe, bei der du Auswirkungen messen und schnell anpassen kannst.
Wähle einen Feature‑Bereich (oder einen Service) und definiere eine einzelne Erfolgsmetrik für die nächsten ein bis zwei Sprints—z. B. Lead Time vom Ticket bis zum Merge, Anzahl Review‑Runden, entwichene Bugs oder On‑Call‑Unterbrechungen.
Schreibe vor dem Start in einem Satz, was „done“ bedeutet. Das hält das Experiment ehrlich.
Führe eine gemeinsame Prompt‑Vorlage ein, damit Prompts vergleichbar und wiederverwendbar sind. Halte sie simpel:
Speichere Prompts im Repo (z. B. /docs/prompt-log.md) oder im Ticketsystem, aber mach sie leicht auffindbar.
Statt langer Design‑Docs verlangen drei leichte Artefakte für jede Änderung:
Das schafft eine Spur der Absicht, ohne die Auslieferung zu verlangsamen.
Führe ein kurzes Retro zu Ergebnissen durch: Hat sich die Metrik verbessert? Wo hakte es im Review? Welche Prompts sorgten für Verwirrung? Aktualisiere die Vorlage, passe Minimums an und entscheide, ob du auf einen weiteren Bereich ausweitest.
Wenn dein Team ernsthaft schwere Docs ersetzen will, hilft Tooling, das Iteration sicher macht: schnelle Deploys, einfache Umgebungs‑Resets und Rollbacks, wenn ein Experiment schiefgeht.
Beispiel: Koder.ai ist für diesen Vibe‑Coding‑Workflow gebaut: du kannst per Chat Mikro‑Pläne und Implementierungen durchgehen, React‑basierte Web‑Apps, Go + PostgreSQL‑Backends und Flutter‑Mobile‑Apps generieren und Quellcode exportieren, wenn du von Exploration zu einer traditionellen Repo‑Arbeit übergehen willst. Snapshots und Rollback sind besonders nützlich, wenn du aggressiv iterierst und „probier’s“ risikofrei machen willst.
Design‑Docs verschwinden nicht in einem Vibe‑Coding‑Workflow—sie schrumpfen, werden spezifischer und rücken näher an die Arbeit. Statt eines großen „Paperworks“ vorab wird die Dokumentation kontinuierlich erzeugt: Prompts, die Absicht ausdrücken, Iterationen, die die Realität offenlegen, und Refactoring, das das Ergebnis lesbar und dauerhaft macht.
Prompting definiert Absicht. Ein guter Prompt wirkt wie eine ausführbare Design‑Spec: Constraints, Akzeptanzkriterien und „nicht kaputtmachen“‑Regeln in klarer Sprache.
Iteration findet Wahrheit. Kleine Zyklen (generieren → ausführen → inspizieren → anpassen) ersetzen Spekulation durch Feedback. Wenn etwas unklar ist, diskutierst du nicht endlos—du probierst es aus, misst und aktualisierst Prompt oder Code.
Refactoring macht es dauerhaft. Sobald die Lösung funktioniert, refactore, damit das Design lesbar wird: Namen, Grenzen, Tests und Kommentare, die das „Warum“ erklären. Das wird zuverlässiger zur langfristigen Referenz als ein veraltetes PDF.
Um Gedächtnisverlust zu vermeiden, halte ein paar kompakte, signalfähige Artefakte:
Führe einen konsistenten Prompt/PR‑Template ein, verfestige Tests bevor du das Tempo erhöhst, und halte Änderungen klein genug, um in Minuten statt Tagen reviewed zu werden. Wenn du eine konkrete Rollout‑Abfolge willst, siehe /blog/a-practical-rollout-plan-for-your-team.
Ein Vibe‑Coding‑Workflow ist eine iterative Build‑Schleife, in der du deine Absicht in natürlicher Sprache formulierst, ein kleines Inkrement (oft mit KI) erzeugst, es ausführst, die Ergebnisse beobachtest und verfeinerst.
Es ersetzt lange Vorab‑Planung durch schnelles Feedback: prompt → implementieren → testen → anpassen.
Design‑Dokumente werden schnell veraltet, sobald die Umsetzung reale Beschränkungen offenbart (API‑Eigenheiten, Randfälle, Performance‑Grenzen, Integrationsdetails).
Bei schnellem Arbeiten lesen Teams lange Docs oft nur oberflächlich oder ignorieren sie, sodass Aufwand ohne Nutzen entsteht.
Enthält vier Dinge:
Formuliere es so, dass jemand Code generieren das Ergebnis schnell verifizieren kann.
Fordere es explizit vor dem Coden:
Dann entscheide, welche Annahmen zu Constraints werden, welche zu Tests und welche Produkt/Design‑Input brauchen.
Wähle den kleinsten End‑to‑End‑Pfad, der trotzdem echte Grenzen durchläuft (UI → API → Daten → Backend).
Beispiel: Für „gespeicherte Suchen“ beginne mit einem Filter, einem gespeicherten Eintrag und einem Abruf, und erweitere erst, wenn diese Scheibe funktioniert.
Begrenze jeden Zyklus auf 30–90 Minuten und fordere ein konkretes Ergebnis (einen bestehenden Test, einen funktionierenden Screen, eine gemessene Query‑Zeit oder eine klare UX‑Beobachtung).
Wenn du den nächsten Schritt nicht in 1–2 Sätzen beschreiben kannst, ist er zu groß—teile ihn auf.
Fordere zuerst einen Plan an und verwandle ihn dann in eine Mikro‑Checkliste:
Behandle jeden Prompt als PR‑große Scheibe, die ein Reviewer ohne Meeting verstehen kann.
Nachdem du durch Iteration genug gelernt hast, um die echten Beschränkungen zu sehen: wiederkehrende Änderungen an derselben Stelle, unklare Grenzen oder Bugs, die auf Strukturprobleme zurückgehen.
Nutze Refactoring, um Absicht sichtbar zu machen: bessere Namen, domain‑orientierte Module und Tests, die Verhalten festschreiben.
Behalte kleine, hochsignalfähige Artefakte:
Bevorzuge Verlinken innerhalb des Repos (z. B. ) statt wiederholtem Abschreiben.
Nutze Quality‑Gates, die jede Iteration überprüfen:
Erfasse außerdem nicht‑funktionale Anforderungen explizit (Performance, Accessibility, Privacy/Security) in der PR‑Checkliste.
/docs/decisions.md