Thema: Teil 21. Abschluss und Arbeitssystem
Schwierigkeitsgrad: Mittelstufe
Geschätzte Lernzeit: 4-6 Stunden (Theorie: 2 Stunden, Praxis: 2-4 Stunden)
Voraussetzungen: Grundlagen der Arbeit mit Git und Branches
Verständnis von grundlegendem CI/CD
Bekanntschaft mit LLM-Agenten (Qwen Code, Claude Code oder Äquivalente)
Absolvierung der Teile 1-20 des SDD-Kurses (wünschenswert, aber nicht obligatorisch)
Grundlegende Erfahrung mit Markdown und Strukturierung von Dokumentation
Lernziele: Eine vollständige Struktur des SDD-Repositorys bilden und den Zweck jeder Datei erklären
Den Betriebszyklus 'Spezifikation → Implementierung → Prüfung → Zusammenführung' mit Verwendung von /clear zwischen Rollen ausführen
Den Reifegrad von SDD im eigenen Team nach der Skala 0-4 bestimmen und einen Plan für den Übergang auf die nächste Stufe erstellen
Einen minimalen funktionierenden SDD-Prozess für ein reales Projekt aus 5 Dateien erstellen
Eine Retrospektive nach 2-3 Features durchführen und Beobachtungen herausarbeiten, die sich zur Kodifizierung in Agentenregeln eignen
Überblick: Dieser abschließende Teil des SDD-Kurses verwandelt Theorie in ein Arbeitssystem. SDD ist kein Dateiensatz um der Dateien willen, sondern eine Kontrollinfrastruktur, die dem Menschen hilft, Souveränität zu bewahren, wenn der Agent in Minuten verändern kann, was früher Stunden dauerte. Die wichtigste Fähigkeit besteht nicht darin, maximal lange Prompts zu schreiben, sondern die richtigen Grenzen zwischen Absicht (Spezifikation), Planung, Implementierung und Prüfung aufzubauen. Der Leitfaden führt Sie durch die abschließende Repository-Struktur, den Betriebszyklus, Entscheidungsgrenzen, typische Fehler, die Reifegradskala und die praktische Einführung in einem echten Team. Ziel ist es, das Team auf Stufe 2 im didaktischen Projekt AgentClinic zu bringen und Werkzeuge für weiteres Wachstum zu geben.
Schlüsselkonzepte: Arbeitssystem sdd: SDD ist keine Dokumentation um der Dokumentation willen, sondern ein lebendiger Prozess, der nur bei Disziplin funktioniert. Die Schlüsselformel: Die Spezifikation bewahrt langfristige Absicht, Fakten entscheiden, ob ein Branch zusammengeführt werden darf, der Agent führt schnell aus, der Mensch trägt die Verantwortung für das Urteil. Oder noch kürzer: Spezifikationen leiten an, Fakten ermöglichen die Zusammenführung.
Abschließende Repository-Struktur: Die vollständige Struktur umfasst: Stammdateien (AGENTS.md, QWEN.md, README.md, CHANGELOG.md, package.json, tsconfig.json); das Verzeichnis .qwen/ mit Einstellungen, Hooks, Speicher und Fähigkeiten; das Verzeichnis specs/ mit mission.md, tech-stack.md, roadmap.md und Feature-Spezifikationen nach dem Schema YYYY-MM-DD-feature-name/ (requirements.md, plan.md, validation.md); Quellcode in src/, Tests in tests/, PR-Vorlage in .github/pull_request_template.md.
Betriebszyklus: Klare Handlungsabfolge: Vorbereitung (git checkout main, git pull, git status, npm test, npm run typecheck) → Spezifikation mit dem Fähigkeit feature-spec und /clear → Commit der Spezifikation → Implementierung mit klarer Begrenzung 'nur Aufgabengruppe 1' und /clear → Prüfung nach validation.md mit Auflistung bestätigter, gescheiterter, fehlender und mehrdeutiger Fakten → Aktualisierung von CHANGELOG mit der Fähigkeit changelog → Abschlussprüfungen und Zusammenführung → Neupplanung vor dem nächsten Feature.
Entscheidungsgrenzen: Jede Datei speichert ihren Entscheidungstyp: mission.md — Zielgruppe, Produktsinn, Ton, Erfolgsdefinition; tech-stack.md — Sprache, Umgebung, Framework, Datenbank, Testen, Bereitstellungsbeschränkungen, verbotene Technologien; roadmap.md — Phasenreihenfolge, Status, lieferbare Ergebnisse, nächster Schritt; Feature-Spezifikation — Grenzen, out of scope, Aufgabengruppen, validation.md-Fakten, Prüfbefehle, Faktenstatus, manuelle Prüfungen; QWEN.md/AGENTS.md — Verhaltensregeln, Prüfbefehle, Verbot spekulativer Refactorings, Anforderung der Spezifikation vor Code.
Reifegradskala sdd: Fünfstufige Skala: 0 — Vibe-Coding (ein langer Chat, Entscheidungen in der Sitzungshistorie); 1 — Spezifikationen fakultativ, validation.md als Wunsch, /clear wird vergessen; 2 — SDD als Standardvorgabe, ausführbare Fakten, /clear als Gewohnheit, Neupplanung zwischen Features; 3 — kodifizierter Prozess, Fähigkeiten, Schutz-Hooks, vierstufiges Review, Erkennung von Antipatterns; 4 — lernfähiger Prozess, Beobachtungen werden zu Regeln, Agentenspeicher wird bewusst gesteuert, Austauschbarkeit des Agenten geprüft. Ziel des Leitfadens — Stufe 2.
Minimale sdd-Vorlage: Für den Anfang genügen 5 Dateien: specs/mission.md, specs/tech-stack.md, specs/roadmap.md, specs/YYYY-MM-DD-feature/(requirements.md, plan.md, validation.md). Warten Sie nicht auf das perfekte Framework — beginnen Sie mit dem Minimum und bauen Sie aufgrund von Beobachtungen aus.
Kodifizierung von Beobachtungen: Der Schlüsselmechanismus für das Wachstum von Stufe 2 auf 3: Wenn sich ein wiederholender Agentenfehler feststellt, schlägt jemand ruhig vor „Lass uns eine Regel in QWEN.md hinzufügen“, und diese Regel erscheint tatsächlich. Die Retrospektive nach 2-3 Features analysiert: Wo hat der Agent geraten, welche Spezifikationen waren nutzlos, welche Prüfungen haben echte Fehler gefunden, welche Punkte waren Wünsche und keine Fakten, was sollte automatisiert werden.
Austauschbarkeit des Agenten: Prinzip, das auf Stufe 4 geprüft wird: Das Team wechselte das Werkzeug (Qwen → Claude → anderes) und verlor den Prozess nicht. Erreicht durch klare Dokumentierbarkeit von Absichten und Fakten, unabhängig vom konkreten Agenten.
Übungsaufgaben: Titel: Übung 1: Erstellung eines minimalen SDD-Skeletts
Problemstellung: Nehmen Sie Ihr aktuelles Projekt (oder erstellen Sie ein neues Repository). Erstellen Sie eine minimale SDD-Vorlage aus 5 Dateien: specs/mission.md, specs/tech-stack.md, specs/roadmap.md, specs/2026-01-15-auth-module/requirements.md, specs/2026-01-15-auth-module/plan.md, specs/2026-01-15-auth-module/validation.md. Füllen Sie jede Datei nach den Regeln der Entscheidungsgrenzen. Führen Sie dann den Betriebszyklus bis einschließlich der Spezifikationsphase aus: Branch-Vorbereitung, /clear, Anfrage an den Agenten mit der Fähigkeit feature-spec, Commit der Spezifikation.
Lösung: Schritt 1: Erstellen Sie das Verzeichnis specs/ im Projektstamm. Schritt 2: In mission.md notieren Sie: Zielgruppe (z.B. 'interne Entwickler einer medizinischen Klinik'), Produktsinn ('Automatisierung der Patientenanmeldung'), Ton ('sachlich, ohne Emojis'), Erfolgsdefinition ('Anmeldezeit sinkt von 10 auf 2 Minuten'). Schritt 3: In tech-stack.md fixieren Sie: TypeScript, Node.js 20, Hono, SQLite, Vitest, Docker, MongoDB verboten. Schritt 4: In roadmap.md beschreiben Sie 3 Phasen: 1) Infrastruktur (Status: erledigt), 2) Authentifizierung (Status: in Bearbeitung), 3) Terminplanung (Status: geplant). Schritt 5: Für das Feature auth-module erstellen Sie requirements.md mit Grenzen ('umfasst: JWT-Login, Refresh-Token; umfasst nicht: OAuth, 2FA'), plan.md mit 3 Aufgabengruppen, validation.md mit 5 Fakten und Prüfbefehlen. Schritt 6: git checkout -b feat/auth-spec, git add specs/, git commit -m 'Add auth-module spec'. Prüfung: Die Repository-Struktur entspricht der minimalen SDD-Vorlage.
Schwierigkeitsgrad: Anfänger
Titel: Übung 2: Diagnose des Reifegrads eines Teams
Problemstellung: Analysieren Sie den aktuellen Entwicklungsprozess in Ihrem Team (oder in einem hypothetischen Team aus 3 Entwicklern, das Cursor nutzt). Bestimmen Sie den aktuellen SDD-Reifegrad nach der Skala 0-4. Geben Sie für jedes Merkmal des Übergangs zwischen den Stufen (0→1, 1→2, 2→3, 3→4) konkrete Fakten aus Ihrer Praxis an, die das Erreichen der Stufe bestätigen oder widerlegen. Erstellen Sie einen Plan aus 3 konkreten Schritten für den Übergang auf die nächste Stufe mit einer Zeitschätzung für die Einführung.
Lösung: Schritt 1: Erstellen Sie eine Tabelle mit 5 Spalten: Stufe, Merkmale, Fakten aus der Praxis, Bestätigt?, Nachweise. Schritt 2: Füllen Sie für Stufe 0 aus: 'Ein langer Chat mit dem Agenten' → 'Entwickler Ivan führt einen 200-Nachrichten-Chat in Cursor, Entscheidungen sind nicht dokumentiert' → Bestätigt → Screenshot der Historie. Für Stufe 1: 'Spezifikationen fakultativ' → 'Für große Features schreiben wir README, für kleine nicht, validation.md fehlt' → Teilweise. Für Stufe 2: 'SDD als Standardvorgabe' → 'Nein, neue Features beginnen mit der Bitte „schreib Code“' → Nicht bestätigt. Schritt 3: Aktuelle Stufe = 1 (zwischen 1 und 2). Schritt 4: Plan für den Übergang auf 2: (a) Regel einführen 'Kein mehrdateiliges Feature ohne requirements.md, plan.md, validation.md' — 1 Woche; (b) /clear zwischen Rollen in die Prompt-Vorlage aufnehmen — 3 Tage; (c) Erste Retrospektive nach 2 Features durchführen — 2 Wochen. Insgesamt: 4 Wochen bis zur stabilen Stufe 2.
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 3: Simulationsprüfung mit Ablehnung
Problemstellung: Der Agent hat das Feature 'hello-hono' implementiert (API auf Hono mit dem Endpunkt GET /health). Tests bestehen, aber bei der Prüfung nach validation.md wurden Abweichungen festgestellt: (1) in der Spezifikation war Port 3000 angegeben, der Agent nutzte 8080; (2) in der Spezifikation wurde der Header X-Request-ID gefordert, der Agent hat ihn nicht hinzugefügt; (3) die Tests des Agenten prüfen nur 200 OK, validation.md fordert jedoch die Prüfung der Antwortstruktur {status: 'ok', timestamp: ISO8601}. Erstellen Sie einen Prüfbericht im Format 'bestätigte Fakten, gescheiterte Fakten, fehlende Fakten, mehrdeutige Punkte'. Bestimmen Sie, ob der Branch zusammengeführt werden darf, und beschreiben Sie die nächsten Schritte.
Lösung: Prüfbericht: Bestätigte Fakten: (a) Server startet ohne Fehler (npm run dev wird ausgeführt); (b) Endpunkt GET /health existiert; (c) HTTP 200 wird zurückgegeben. Gescheiterte Fakten: (a) Server-Port ist 8080 statt 3000 (Anforderung validation.md §3.1); (b) Header X-Request-ID fehlt (Anforderung §4.2); (c) Antwortstruktur entspricht nicht {status: 'ok', timestamp: ISO8601}, es wird einfach 'OK' zurückgegeben (Anforderung §5.1). Fehlende Fakten: (a) Graceful Shutdown nicht geprüft (§6.1, Test fehlt in der Implementierung); (b) SIGTERM-Behandlung nicht geprüft (§6.2). Mehrdeutige Punkte: (a) 'Server sollte produktionsreif sein' — Kriterium nicht definiert; (b) 'Dokumentation des Endpunkts' — unklar, Swagger oder README. Zusammenführungsentscheidung: Branch darf NICHT zusammengeführt werden. Die gescheiterten Fakten §3.1, §4.2, §5.1 sind obligatorisch (Status: obligatorisch in validation.md). Nächste Schritte: (1) Branch an den Agenten mit Bericht zurückgeben und Forderung zur Korrektur der gescheiterten Fakten; (2) Mehrdeutige Punkte in der Spezifikation präzisieren; (3) Nach Korrektur — Wiederholungsprüfung nur der gescheiterten und fehlenden Fakten; (4) QWEN.md mit Regel aktualisieren: 'Server-Port immer aus specs/tech-stack.md oder Feature-Spezifikation entnehmen, keine Framework-Standardwerte verwenden'.
Schwierigkeitsgrad: Mittelstufe
Titel: Übung 4: Kodifizierung nach der Retrospektive
Problemstellung: Nach 3 Features im Team AgentClinic wurden folgende Beobachtungen gesammelt: (a) der Agent machte 2 von 3 Malen ein 'spekulatives Refactoring' — änderte die Verzeichnisstruktur ohne Aufforderung; (b) validation.md für das Feature 'agents-ailments' wurde vollständig aus dem vorherigen Feature kopiert und entsprach nicht den realen Anforderungen; (c) das Team vergaß /clear zwischen Spezifikation und Implementierung, der Agent verwechselte Kontexte; (d) die Fähigkeit feature-spec wurde erstellt, bevor das Team seinen Prozess verstand, und enthält veraltete Anweisungen. Verwandeln Sie diese Beobachtungen in 4 konkrete Regeln für QWEN.md und beschreiben Sie den Prozess zur Aktualisierung der Fähigkeit feature-spec.
Lösung: Regeln für QWEN.md: (1) 'VERBOTEN: Verzeichnisstruktur, Dateinamen, Abhängigkeiten ohne ausdrückliche Angabe in der Spezifikation ändern. Wenn Refactoring notwendig erscheint — stoppen, im Bericht melden, auf Bestätigung warten.' (2) 'Vor Verwendung von validation.md prüfen, dass er dem aktuellen Feature entspricht: Daten, Entitätsnamen, Prüfbefehle müssen spezifisch sein, nicht kopiert.' (3) 'Obligatorische Abfolge: /clear vor jedem Rollenwechsel (Spezifizierer → Entwickler → Prüfer). Chat-Kontext wird nicht zwischen Rollen übertragen.' (4) 'Fähigkeiten — lebendige Artefakte. Bei veralteter Anweisung sofort melden, nicht blind folgen.' Aktualisierung der Fähigkeit feature-spec: Schritt 1: Aufgabe erstellen 'feature-spec nach Retrospektive 2026-05-15 aktualisieren'. Schritt 2: Änderungen in .qwen/skills/feature-spec/SKILL.md einpflegen: Abschnitt 'Antipatterns' mit 3 Praxisbeispielen hinzufügen, validation.md-Vorlage mit Erinnerung an Spezifität aktualisieren, Checkliste 'Vor Erstellung der Spezifikation' hinzufügen. Schritt 3: Aktualisierte Fähigkeit an einem kleinen Feature testen. Schritt 4: Wenn der Agent weniger Klärungsfragen stellt — Fähigkeit verbessert, Version in CHANGELOG festhalten.
Schwierigkeitsgrad: Fortgeschritten
Fallstudien: Titel: Fallstudie: Migration des Startups MedFlow vom Vibe-Coding zu SDD-Stufe 2
Szenario: MedFlow — Telemedizin-Startup, 4 Entwickler, nutzen aktiv Cursor mit Composer. In 6 Monaten 15.000 Nachrichten in Chats angesammelt, Produktion 3 Mal wegen 'Optimierungen' des Agenten ausgefallen, Dokumentation war bei Erstellung bereits veraltet. CTO entschied sich nach einem weiteren Vorfall für SDD-Einführung: Der Agent löschte die Tabelle appointments, 'optimierte' das Schema, weil in einem 200 Nachrichten zurückliegenden Chat eine andere Struktur besprochen wurde.
Herausforderung: (1) Entwickler leisteten Widerstand: 'Das wird uns bremsen, wir sind doch schon schnell'. (2) Kein einheitliches Produktverständnis: Jeder Entwickler hatte seine eigene Vision. (3) Agenten waren an lange Chats gewöhnt und 'erraten' Absichten. (4) Die Feature-Liefergeschwindigkeit sollte bei gleichzeitiger Zuverlässigkeitssteigerung erhalten bleiben.
Lösung: Woche 1: Eine einzige harte Regel eingeführt — 'Kein mehrdateiliges Feature ohne requirements.md, plan.md, validation.md'. specs/mission.md erstellt (einheitliche Vision: 'Plattform für asynchrone Konsultationen, nicht synchrone Anrufe'), specs/tech-stack.md (Firebase verboten, PostgreSQL fixiert). Woche 2-3: Kurzes AGENTS.md mit 5 Regeln hinzugefügt, einschließlich Verbot spekulativer Refactorings. Fähigkeit feature-spec erst nach 2 manuellen Spezifikationen erstellt — nicht früher. Woche 4: /clear zwischen Rollen eingeführt, Entwickler verfolgen dies beim Pair Programming. Woche 6: Erste Retrospektive — festgestellt, dass 40% der validation.md-Punkte Wünsche waren, keine prüfbaren Fakten. Kriterien präzisiert. Woche 8: Austauschbarkeit geprüft — ein Entwickler wechselte für ein Feature von Cursor zu Claude Code, Prozess funktionierte ohne Verluste.
Ergebnis: Nach 3 Monaten: Zeit von Idee bis Produktion sank von 14 auf 9 Tagen (kontraintuitiv: weniger Rollbacks und Bugs), Agenten-bedingte Vorfälle von 3/Monat auf 0, neuer Entwickler eingearbeitet in 3 Tagen statt 2 Wochen (las specs/, keine Chat-Historie). Team erreichte Stufe 2, plant Übergang auf 3 durch Automatisierung von Hooks.
Gelernte Lektionen: Nicht mit dem perfekten Prozess beginnen, sondern mit einer einzigen unabdingbaren Regel — das ist der einzige Weg, Widerstand zu überwinden
Agentenfähigkeiten dürfen nicht vor dem Prozessverständnis erstellt werden: Die ersten 2 Spezifikationen müssen manuell sein, um Muster zu erkennen
Retrospektive nach 2-3 Features ist kritisch: Ohne sie bleibt validation.md eine Wunschliste, und der Prozess eine Formalität
Austauschbarkeit des Agenten — kein abstraktes Ziel, sondern praktische Prüfung: Probieren Sie ein anderes Werkzeug für ein Feature aus und erkennen Sie Lücken in der Dokumentation
Verwandte Konzepte: Minimale SDD-Vorlage
SDD-Reifegradskala
Betriebszyklus
Kodifizierung von Beobachtungen
Austauschbarkeit des Agenten
Titel: Fallstudie: Unternehmensteam BigTech, auf Stufe 3 steckengeblieben wegen vorzeitiger Automatisierung
Szenario: Ein Team aus 12 Entwicklern in einem großen E-Commerce-Projekt wechselte schnell von Stufe 1 auf 3: 15 Fähigkeiten erstellt, 8 Schutz-Hooks, automatisches Review. Nach 4 Monaten erstickte der Prozess: Hooks lehnten 60% der Commits bei Fehlalarmen ab, Fähigkeiten widersprachen sich, Entwickler umgingen das System durch 'Vibe-Coding in persönlichen Branches'.
Herausforderung: (1) Automatisierung überholte das Verständnis: Hooks kodifizierten Annahmen, keine geprüften Muster. (2) Fähigkeiten vermehrten sich ohne zentrale Verantwortung — jeder Entwickler fügte 'seine' Fähigkeit hinzu. (3) Der Prozess wurde zum Selbstzweck: Metriken des 'Reifegrads' wichtiger als reale Effizienz. (4) Vergessene Retrospektive: Das Team analysierte nicht, welche Regeln funktionieren und welche nicht.
Lösung: Radikale Vereinfachung: Alle Hooks außer 2 deaktiviert, 10 von 15 Fähigkeiten gelöscht, nur feature-spec und changelog beibehalten. Monatlicher Audit eingeführt: Jede Regel in QWEN.md muss einen Verweis auf einen konkreten Vorfall haben, den sie verhindert hat. Manuelle Prüfungen für 20% der Features zurückgeführt — Zufallsstichprobe zur Validierung der Automatisierung. Retrospektive wurde vor jeder Sprintplanung obligatorisch, nicht nur zwischen Features.
Ergebnis: Nach 2 Monaten: Fehlalarme der Hooks von 60% auf 8% gesunken, Zykluszeit 'Spezifikation → Zusammenführung' um 35% verkürzt, Entwickler kehrten in den Hauptprozess zurück. Team kehrte bewusst zu Stufe 2 mit Elementen von 3 zurück, plant Rückkehr auf 3 nach 6 Monaten Beobachtungen.
Gelernte Lektionen: Stufen 3 und 4 dürfen nicht Selbstzweck sein: Vorzeitige Automatisierung ist schlimmer als keine Automatisierung
Jede Regel in QWEN.md muss eine 'Abstammung' haben — einen konkreten Vorfall, sonst ist sie Spekulation
Zufällige manuelle Prüfung von 20% automatisierter Prozesse — notwendige Qualitätskontrolle
Reifegradskala — Diagnosewerkzeug, kein KPI: Verwenden Sie sie zum Verstehen, nicht zur Berichterstattung
Verwandte Konzepte: SDD-Reifegradskala
Kodifizierung von Beobachtungen
Häufigste Fehler
Entscheidungsgrenzen
Lerntipps: Üben Sie /clear physisch: Öffnen Sie Qwen Code, führen Sie den Befehl aus, vergewissern Sie sich, dass der Chat-Kontext tatsächlich zurückgesetzt wurde. Viele vergessen dies automatisch, und der Agent verwechselt Rollen.
Erstellen Sie ein 'Vorlagen-Repository' SDD auf GitHub und klonen Sie es für jedes neue Projekt — das senkt die Einstiegshürde und verhindert 'Schreibblockade'.
Führen Sie wöchentlich eine 'Grenzen-Audit' durch: Öffnen Sie mission.md, tech-stack.md, roadmap.md und prüfen Sie, ob sie sich widersprechen. Inkonsistenz dieser drei Dateien — Hauptgrund für nutzlose Spezifikationen.
Für den visuellen Stil: Zeichnen Sie den Betriebszyklus auf A3-Papier und hängen Sie ihn neben den Monitor. SDD funktioniert nur bei buchstäblicher Befolgung der Abfolge, ohne Auslassungen.
Üben Sie 'Red Teaming': Bitten Sie einen Kollegen, Ihre Spezifikation absichtlich zu brechen — validation.md überspringen, /clear ignorieren, Refactoring außerhalb des Plans machen. Das deckt blinde Flecken in QWEN.md auf.
Führen Sie ein 'Agenten-Vorfall-Journal': Notieren Sie Datum, Prompt, unerwartetes Verhalten, hinzugefügte Regel. Nach 10 Einträgen erkennen Sie Muster, die sich zur Kodifizierung eignen.
Für den Hörsaalstil: Diskutieren Sie mit dem Team den Fall MedFlow, dann führen Sie ein Rollenspiel durch — ein 'Agent' (mit geschlossenen Augen für die Ausgangsdokumente), ein 'Spezifizierer', ein 'Prüfer'. Spüren Sie selbst, wo der Prozess versagt.
Lesen Sie diesen Teil nicht 'in einem Zug'. Halten Sie nach jedem Abschnitt an und führen Sie eine Mikro-Praxis durch: Erstellen Sie eine Datei, prüfen Sie eine Hypothese, stellen Sie dem Agenten einen Test-Prompt.
Zusätzliche Ressourcen: Repository agentclinic (Strukturbeispiel): Studieren Sie die abschließende Struktur aus den Kursmaterialien als Maßstab für Ihre Projekte
Minimale sdd-Vorlage: specs/mission.md + specs/tech-stack.md + specs/roadmap.md + specs/YYYY-MM-DD-feature/(requirements.md, plan.md, validation.md)
Qwen Code Dokumentation zu Fähigkeiten (skills): https://github.com/QwenLM/Qwen2.5-Coder (offizielle Beispiele der Struktur .qwen/skills/)
Teil 16 des sdd-Kurses (vierstufiges Review): Kursmaterialien — zur Vorbereitung auf Stufe 3
Teil 20 des sdd-Kurses (Antipatterns): Kursmaterialien — zur Erkennung typischer Fehler
Teil 10 des sdd-Kurses (Kodifizierung): Kursmaterialien — für den Mechanismus der Umwandlung von Beobachtungen in Regeln
Teil 15 des sdd-Kurses (Austauschbarkeit des Agenten): Kursmaterialien — zur Prüfung der Unabhängigkeit vom konkreten Werkzeug
Buch 'Working Effectively with Legacy Code' (Michael Feathers): Klassiker über Änderungsgrenzen — anwendbar auf Entscheidungsgrenzen in SDD
Praxis 'Prompt Engineering for Developers' (DeepLearning.AI): Zum Verständnis der Rolle von /clear und der Trennung von Kontexten
Zusammenfassung: SDD ist ein Arbeitssystem der Kontrolle, keine Bürokratie. Ihr Kern sind vier Grenzen: Spezifikationen bewahren die Absicht, Fakten ermöglichen die Zusammenführung, der Agent führt schnell aus, der Mensch trägt die Verantwortung für das Urteil. Beginnen Sie mit dem Minimum: 5 Dateien und eine unabdingbare Regel. Erreichen Sie Stufe 2 durch Disziplin von /clear, ausführbaren Fakten in validation.md und Neupplanung zwischen Features. Stufen 3 und 4 kommen von selbst, wenn Sie regelmäßig Retrospektiven durchführen und Beobachtungen kodifizieren — aber machen Sie sie nicht zum Selbstzweck. Prüfen Sie Ihren Weg mit einem abschließenden Test: Bitten Sie den Agenten, ohne Chat-Kontext zu handeln, nur anhand der Dateien. Wenn er gute Fragen stellt — sind Sie auf dem richtigen Weg.