Thema: Anhang A. Wie das Lehrbuch mit Spec Kit und Kiro zusammenhängt
Schwierigkeitsgrad: Mittel
Geschätzte Studienzeit: 3-4 Stunden aktives Lernen + 2 Stunden Praxis
Voraussetzungen: Grundlegendes Verständnis von SDD (Specification-Driven Development)
Vertrautheit mit Markdown-Formatierung
Erfahrung mit mindestens einem KI-Assistenten für die Programmierung
Verständnis grundlegender Projektmanagement-Konzepte (Roadmaps, Anforderungen, Planung)
Lernziele: Die sieben Artefakte des Lehrbuchs mit ähnlichen Elementen in Spec Kit und Kiro anhand einer Zuordnungstabelle gegenüberstellen
Die Wahl des Formats (Lehrbuch/Spec Kit/Kiro) für ein konkretes Projekt anhand der Kriterien aus dem Anhang begründen
Einen Prozess von einem System in ein anderes übertragen, wobei der Sinn der Artefakte und nicht nur ihre Namen erhalten bleibt
Explizite Prüffakten in validation.md für ein hypothetisches Projekt formulieren
Die Nachteile des vereinfachten Lehrbuchformats ermitteln und zusätzliche Vereinbarungen für ein großes Team vorschlagen
Überblick: Dieser Anhang des SDD-Lehrbuchs beleuchtet den Zusammenhang zwischen dem proprietären Spezifikationsformat (Dateien mission.md, tech-stack.md, roadmap.md, requirements.md, plan.md, validation.md, QWEN.md) und zwei industriellen Systemen: Spec Kit und Kiro. Die Kernthese lautet: Das Format sollte nicht zur Dogma werden; wichtig ist es, Intention, Plan, Prüfung und Entscheidungen in reviewbaren Artefakten zu bewahren. Das Lehrbuch ist bewusst für das Lernen und die direkte Arbeit mit Qwen Code vereinfacht, während Spec Kit und Kiro eine reichhaltigere Infrastruktur für Teams, Vorlagen und Integrationen bieten. Das Studium dieses Anhangs ermöglicht dem Leser, sich frei zwischen den Systemen zu bewegen, Prozesse an die Bedürfnisse des Teams anzupassen und fundierte Entscheidungen über die Wahl des Werkzeugs zu treffen.
Schlüsselkonzepte: Proprietärer sdd-Dialekt für qwen code: Sieben Markdown-Dateien, die einen vollständigen Spezifikationszyklus bilden: von der Mission bis zur Validierung. Das Format ist für das direkte Lesen durch einen KI-Agenten ohne spezielle CLI-Dienstprogramme entwickelt. Jede Datei ist für einen separaten Aspekt des Denkens verantwortlich: warum das Projekt existiert, welche Einschränkungen gelten, in welcher Reihenfolge gebaut werden soll, was genau gebaut werden soll, wie die Umsetzung aufgeteilt wird, welche Fakten eine Zusammenführung erlauben, und wie sich der Agent verhalten soll.
Validation.md als separater Denkschritt: Die wichtigste architektonische Unterscheidung des Lehrbuchs von Alternativen. Anstatt Prüfkriterien auf Aufgaben, Checklisten oder Plananalysen zu verteilen – eine explizite Datei mit Fakten, die entscheiden, ob ein Branch zusammengeführt werden kann. Dies schafft eine separate Denkebene über Qualität, die vor Beginn der Umsetzung sichtbar ist.
Spec kit: Ein Spezifikationssystem mit Befehlen wie /speckit.specify, /speckit.clarify, /speckit.plan, /speckit.tasks, /speckit.analyze. Bietet fertige Vorlagen, Erweiterungen, Presets und wiederholbare Arbeitsabläufe. Ausgerichtet auf Teams mit mehreren Projekten, die einen einheitlichen Standard erfordern.
Kiro: Eine Plattform mit drei Ebenen: Steering-Dateien (ständige Regeln), Specs (konkrete Features), Aufgaben und Tests (überprüfbarer Pfad). Eng in den IDE-Prozess integriert, verwendet Agent Hooks und Steering zur Steuerung des Agentenverhaltens.
Artefakt-Zuordnungstabelle: Ein Mapping-Werkzeug zwischen Systemen. Zeigt, dass mission.md = Projektverfassung (Spec Kit) = Steering-Dateien (Kiro); requirements.md = /speckit.specify + /speckit.clarify = Anforderungen; plan.md = /speckit.plan + /speckit.tasks = Design + Aufgaben; validation.md = teilweise /speckit.analyze + Checklisten = Kriterien in Aufgaben und Tests.
Prozessübertragung durch Sinnerhalt: Eine Methodik der Anpassung: nicht Dateinamen aufzwingen, sondern Prinzipien zu übertragen – explizite Verfassung, Klärung von Mehrdeutigkeiten vor dem Plan, Trennung architektonischer Entscheidungen von der Aufgabenliste, sichtbare Prüffakten vor der Umsetzung, Vergleich der Umsetzung mit Artefakten und nicht mit Chat-Erinnerungen.
Drei Kiro-Ebenen für die Übertragung: Steering-Dateien (ständige Projektregeln), Specs (konkrete Feature-Spezifikationen), Aufgaben und Tests (überprüfbarer Pfad zur Umsetzung). Bei der Migration vom Lehrbuch zu Kiro muss der Inhalt auf diese Ebenen verteilt werden.
Formatwahlkriterien: Lehrbuch – für Lernen, kleine Projekte, Transparenz in Markdown, Plattformunabhängigkeit. Spec Kit – für etablierte Teams, Klärung von Mehrdeutigkeiten, Erweiterungen, viele Projekte. Kiro – für bestehende Kiro-Nutzer, IDE-Integration, eingebaute Specs und Agent Hooks.
Nachteile des vereinfachten Formats: In einem großen Team sind zusätzliche Vereinbarungen erforderlich: Merge-Requests, Roadmap-Verantwortliche, Spezifikationsreviews, Aufgabenvorlagen. Diese Themen werden in Teil 16 des Lehrbuchs behandelt.
Reviewbare Artefakte als Prozesskern: Das wichtigste Metaprinzip: Es ist nicht wichtig, wie die Dateien heißen oder welche CLI verwendet wird – wichtig ist, dass Intention, Plan, Prüfung und Entscheidungen in Artefakten existieren, die reviewt, versioniert und mit der Umsetzung verglichen werden können.
Übungsaufgaben: Titel: Übung 1: Erstellung einer Zuordnungstabelle für ein hypothetisches Projekt
Problemstellung: Ihnen liegt ein Projekt vor: eine mobile App zur Gewohnheitsverfolgung. Im Lehrbuchformat sind bereits Dateien erstellt: mission.md („Nutzer durch Gamifizierung dabei helfen, nachhaltige Gewohnheiten aufzubauen“), tech-stack.md (Flutter, Firebase, Provider), roadmap.md (MVP → soziale Funktionen → Analytik), requirements.md (Liste von Nutzerszenarien), plan.md (Architektur + sprintweise Aufgaben), validation.md (Retention-Metriken, Testabdeckung). Aufgabe: Füllen Sie die Zuordnungstabelle aus und geben Sie an, wie jede Lehrbuchdatei in Spec Kit (konkrete Befehle) und in Kiro (konkrete Ebenen/Dateien) abgebildet würde. Für validation.md begründen Sie, warum sein separates Bestehen eine architektonische Entscheidung und nicht nur eine Bequemlichkeit ist.
Lösung: Schritt 1: mission.md → Spec Kit: Projektverfassung (eingeführt durch /speckit.init oder manuell im Spezifikationskopf); Kiro: Steering-Datei project.md oder habits-steering.md. Schritt 2: tech-stack.md → Spec Kit: Teil der Verfassung + Plan (Einschränkungen werden in /speckit.clarify festgehalten, technischer Plan in /speckit.plan); Kiro: Steering-Datei tech-steering.md + design/specs. Schritt 3: roadmap.md → Spec Kit: Reihenfolge der Spezifikationen und Aufgaben, gesteuert durch /speckit.tasks; Kiro: Feature-Liste in specs/ mit Prioritäten. Schritt 4: requirements.md → Spec Kit: /speckit.specify für funktionale Anforderungen, /speckit.clarify für Mehrdeutigkeiten; Kiro: Dateien specs/habit-tracking.md, specs/gamification.md. Schritt 5: plan.md → Spec Kit: /speckit.plan für architektonische Entscheidungen, /speckit.tasks für Dekomposition; Kiro: design/architecture.md + tasks/ mit einzelnen Aufgaben. Schritt 6: validation.md → Spec Kit: teilweise /speckit.analyze (Prüfung nach Umsetzung) + Checklisten in Aufgaben; Kiro: Akzeptanzkriterien in jeder Aufgabe + Tests. Begründung für separates validation.md: Es schafft eine „Qualitätsfront“ – Fakten, die vor der Umsetzung sichtbar sein müssen und nicht nachträglich abgeleitet werden. Dies verändert die Teampsychologie: Der Entwickler sieht Erfolgskriterien vor dem Code-Schreiben, was „Aktion um der Aktion willen“ verhindert. In Spec Kit und Kiro ist diese Idee im Prozess „aufgelöst“, was zusätzliche Disziplin erfordert. Schritt 7: QWEN.md → Spec Kit: Agentenregeln in Presets; Kiro: Agent Hooks und Steering-Dateien für das Verhalten.
Schwierigkeitsgrad: mittel
Titel: Übung 2: Migration mit Sinnerhalt – vom Lehrbuch zu Kiro
Problemstellung: Ein Team von 4 Entwicklern arbeitete 3 Monate im Lehrbuchformat. Angehäuft: mission.md, tech-stack.md, roadmap.md mit 12 Punkten, requirements.md mit 8 Nutzerstorys, plan.md mit der architektonischen Entscheidung Clean Architecture zu verwenden, validation.md mit 5 Kriterien. Das Team wechselt zu Kiro. Aufgabe: Bestimmen Sie, welcher Inhalt in Steering-Dateien, Specs, Aufgaben und Tests übergeht. Besondere Aufmerksamkeit: validation.md enthält das Kriterium „API-Antwortzeit < 200 ms für das 95. Perzentil“ – wo landet es in Kiro und wie wird seine Sichtbarkeit VOR der Umsetzung gewährleistet, wie es die separate Datei tat?
Lösung: Schritt 1: Steering-Dateien (ständige Regeln): mission.md → project-steering.md; tech-stack.md → tech-steering.md; Prinzipien aus QWEN.md → agent-steering.md. Schritt 2: Specs (konkrete Features): jeder roadmap.md-Punkt + zugehörige Anforderungen → separate Datei in specs/: auth-spec.md, habit-creation-spec.md, gamification-spec.md usw. requirements.md wird aufgeteilt und in die entsprechenden Specs eingebettet. Schritt 3: Architektur aus plan.md → design/clean-architecture.md (separater Spec auf Systemebene). Schritt 4: Aufgaben und Tests: Dekomposition von plan.md → tasks/ mit Verknüpfung zu Specs. Schritt 5: Leistungskriterium aus validation.md: In Kiro gelangt es in die Akzeptanzkriterien der mit der API verbundenen Aufgaben. Problem: Es „löst sich“ in den Aufgaben auf. Für die Erhaltung der Sichtbarkeit VOR der Umsetzung: performance-steering.md in Steering-Dateien mit globalem SLA erstellen; performance-spec.md als Systemspec hinzufügen; Kriterium in die Definition of Done für alle API-Aufgaben aufnehmen; separate Aufgabe „Lasttest einrichten“ im ersten Sprint erstellen. Somit wird der Sinn „expliziter Prüffakten vor der Umsetzung“ durch mehrschichtige Duplizierung und Systemspezifikationen bewahrt, auch wenn die Form sich geändert hat.
Schwierigkeitsgrad: mittel
Titel: Übung 3: Begründung der Formatwahl für einen konkreten Kontext
Problemstellung: Drei Szenarien: (A) Solo-Entwickler, der SDD lernt, erstellt ein Pet-Project am Wochenende. (B) Produktteam von 15 Personen, 3 React-Projekte, benötigt einheitlichen Spezifikationsstandard für Übergabe zwischen Designern, Analysten und Entwicklern. (C) Team von 8 Personen arbeitet seit einem Jahr mit Kiro in VS Code, zufrieden mit IDE-Integration, aber hat das Gefühl, dass Spezifikationen in Aufgaben und Chats „verwässern“. Für jedes Szenario: Wählen Sie das Format, begründen Sie anhand 3 Kriterien aus dem Anhang, nennen Sie Risiko und Mitigation.
Lösung: Szenario A: Lehrbuchformat. Kriterien: (1) lernt SDD – direkte Entsprechung; (2) Projekt klein – benötigt keine Infrastruktur; (3) Plattformunabhängigkeit nötig – Pet-Project nicht an Unternehmenslizenzen gebunden. Risiko: Bei Skalierung geht Struktur verloren. Mitigation: Vereinbarungen aus Teil 16 im Voraus treffen, falls das Projekt wächst. Szenario B: Spec Kit. Kriterien: (1) etablierte Teams und Vorlagen – einheitlicher Standard für 15 Personen nötig; (2) separater Schritt zur Klärung von Mehrdeutigkeiten – kritisch bei Übergabe zwischen Rollen; (3) mehrere Projekte – einheitlicher Standard erforderlich. Risiko: Übermäßige Formalisierung bremst Startup-Projekte aus. Mitigation: „Leichtes“ Spec Kit-Preset für MVP-Phase erstellen. Szenario C: Kiro mit Erweiterung. Kriterien: (1) arbeiten bereits mit Kiro – Migrationskosten minimal; (2) IDE-Integration nötig – bleibt erhalten; (3) Problem der „verwässerten“ Specs – gelöst durch Einführung expliziter Steering-Dateien und separater Spec-Dateien analog zu validation.md. Risiko: Team empfindet Erweiterung als „noch mehr Bürokratie“. Mitigation: Workshop durchführen und zeigen, wie explizite Specs Zeit für Klärungen im Chat sparen.
Schwierigkeitsgrad: mittel
Titel: Übung 4: Erstellung von validation.md für ein bestehendes Spec Kit-Projekt
Problemstellung: Gegeben ist ein Spec Kit-Projekt: E-Commerce-Plattform. Das Team verwendet /speckit.specify für Anforderungen, /speckit.plan für Architektur, /speckit.tasks für Dekomposition, /speckit.analyze für Prüfung nach Umsetzung. Problem: Akzeptanzkriterien sind über Aufgaben in Jira „verteilt“, es gibt keinen zentralen Ort für die Prüfung vor dem Merge. Aufgabe: Erstellen Sie ein validation.md im Geiste des Lehrbuchs, indem Sie Kriterien extrahieren und konsolidieren. Der Inhalt sollte umfassen: (1) funktionale Kriterien für den Warenkorb; (2) nicht-funktionale (Leistung, Sicherheit); (3) „Validierungsreview“-Prozess vor dem Merge.
Lösung: Struktur von validation.md: Abschnitt 1: Kontext – „Diese Datei enthält Fakten, die vor dem Merge in main bestätigt werden müssen. Kein Branch wird ohne Prüfung anhand dieser Liste zusammengeführt.“ Abschnitt 2: Funktionale Kriterien (Warenkorb): [F1] Artikelhinzufügung aktualisiert Zähler in < 100 ms ohne Neuladen; [F2] Bei Mengenänderung erfolgt Preisneuberechnung clientseitig mit Servervalidierung; [F3] Warenkorb wird zwischen Sitzungen für authentifizierte Nutzer gespeichert; [F4] Warenkorb wird nach erfolgreicher Bestellung mit Bestätigung geleert. Abschnitt 3: Nicht-funktionale Kriterien: [N1] API-Antwortzeit Warenkorb < 200 ms (p95) bei Last von 1000 RPS; [N2] Alle Modifikationsoperationen erfordern gültiges JWT; [N3] SQL-Injection durch automatisches Scanning ausgeschlossen; [N4] Logs enthalten keine PII (Prüfung durch Regex in CI). Abschnitt 4: Validierungsreview-Prozess: Schritt 1 – Branch-Autor füllt validation-checklist.md im PR aus; Schritt 2 – CI führt automatische Prüfungen N1-N4 durch; Schritt 3 – Reviewer verifiziert F1-F4 manuell auf Staging; Schritt 4 – Bei Abweichung Merge-Blockade mit Angabe des nicht erfüllten Punkts; Schritt 5 – Nach Merge /speckit.analyze zur Aufdeckung verborgener Risiken. Integration mit Spec Kit: validation.md ersetzt /speckit.analyze nicht, sondern geht diesem voraus und schafft ein „Tor“ vor dem Merge. Das Team behält gewohnte Befehle bei, fügt aber ein explizites Qualitätsartefakt hinzu.
Schwierigkeitsgrad: fortgeschritten
Fallstudien: Titel: Fallstudie: Migration eines Startups vom Lehrbuchformat zu Spec Kit bei Teamwachstum von 2 auf 12 Personen
Szenario: EdTech-Startup „LinguaFlow“ begann mit zwei Gründern, die das Lehrbuchformat für die Entwicklung einer Sprachlernplattform nutzten. Innerhalb von 8 Monaten wuchs das Projekt: Ein eigener Designer, Analyst, 6 Entwickler, 2 QA kamen hinzu. Dateien mission.md, roadmap.md usw. lagen in einem gemeinsamen Repository, aber der Prozess „verwässerte sich“: Entwickler interpretierten requirements.md unterschiedlich, QA wussten nicht, nach welchen Kriterien Features zu prüfen waren, Analyst änderte roadmap.md ohne Teambenachrichtigung.
Herausforderung: Drei konkrete Probleme: (1) requirements.md wurde zu einer „Textwand“ von 400 Zeilen, die niemand aktualisierte; (2) validation.md existierte, aber Entwickler mergeden Branches „aus Erinnerung“ an Kriterien, ohne die Datei zu konsultieren; (3) beim Onboarding neuer Entwickler erforderte das Lehrbuchformat persönliche Erklärung durch die Gründer – Wissensskalierung funktionierte nicht. Das Team erwog Kiro (ein Entwickler nutzte es in persönlichen Projekten), aber die Gründer fürchteten, „Einfachheit“ und „Kontrolle“ zu verlieren.
Lösung: Umstieg auf Spec Kit mit Sinnerhalt: (1) mission.md und tech-stack.md wurden in Projektverfassung konsolidiert, verfügbar über /speckit.init; (2) requirements.md wurde in 8 separate Spezifikationen (/speckit.specify) aufgeteilt, jede mit Analyst als Verantwortlichem; (3) obligatorisches /speckit.clarify vor der Planung eingeführt – Designer und Analyst müssen alle „TBD“ in Anforderungen auflösen; (4) plan.md in /speckit.plan + /speckit.tasks transformiert mit expliziter Trennung von Architektur und Aufgaben; (5) Kriterien aus validation.md in Aufgabenchecklisten eingebettet und /speckit.analyze als post-implementationale Prüfung hinzugefügt; (6) Preset „LinguaFlow-Standard“ mit Agentenregeln erstellt, die QWEN.md fortsetzen. Schlüsselentscheidung: Die Idee „expliziter Prüffakten“ durch obligatorische Checkliste in /speckit.tasks bewahren, nicht durch separate Datei.
Ergebnis: Nach 3 Monaten: Onboarding-Zeit von 2 Wochen auf 3 Tage reduziert (neuer Entwickler startet /speckit.init und erhält vollen Kontext); Anzahl der Feature-„Rückläufer“ von QA zu Entwicklung um 60% gesenkt (dank /speckit.clarify); Analyst und Designer wurden Spezifikationsverantwortliche, Entwickler – Aufgabenverantwortliche; Gründer behielten Kontrolle durch Verfassungsreview und /speckit.analyze. Unerwarteter Effekt: Das Preset „LinguaFlow-Standard“ erwies sich als so erfolgreich, dass das Team begann, Spec Kit-Beratung für andere EdTech-Unternehmen zu verkaufen.
Gelernte Lektionen: Die Einfachheit des Lehrbuchformats wird bei Teamwachstum zur Falle – Skalierung erfordert Institutionalisierung von Prozessen
Die Idee „expliziter Prüffakten“ ist zwischen Systemen übertragbar, aber die Form muss an die Teamkultur angepasst werden
Migrationswiderstand hängt oft nicht mit technischen Risiken zusammen, sondern mit Kontrollverlust der Gründer – dies wird durch ihre Rolle in der Verfassung und /speckit.analyze gelöst
Erfolgreiche Migration erfordert einen „Vermittler“, der beide Systeme versteht – in diesem Fall einen Entwickler mit Kiro-Erfahrung, der die Prinzipien in die Sprache von Spec Kit übersetzte
Verwandte Konzepte: Artefakt-Zuordnungstabelle
Prozessübertragung durch Sinnerhalt
Nachteile des vereinfachten Formats
Formatwahlkriterien
Titel: Fallstudie: Integration von validation.md in ein bestehendes Kiro-Projekt einer Großbank
Szenario: Digitalbank-Team „FinSecure“ (20 Entwickler, 5 Produktteams) nutzte Kiro seit 2 Jahren. Struktur: Steering-Dateien für Compliance-Anforderungen, Specs für jedes Feature, Aufgaben in Jira mit Akzeptanzkriterien. Der regulatorische Druck verstärkte sich: Es musste nachgewiesen werden, dass jedes Feature vor dem Production-Release an 47 Kontrollpunkten geprüft wurde. Bestehende Kriterien in Aufgaben erwiesen sich als fragmentiert, Audit konnte kein vollständiges Bild rekonstruieren.
Herausforderung: Kiro sah keinen „Single Source of Truth“ für Validierungsfakten vor – sie waren über Aufgaben, Tests, Checklisten in Confluence verteilt. Bei Audit benötigte das Team 3-5 Tage für Beweissammlung pro Feature. Risiko: Unmöglichkeit, regulatorisches Audit zu bestehen, Bußgelder, Lizenzbeschränkung. Migration auf ein anderes System war aufgrund tiefer Kiro-Integration mit Bank-IDE und Security-Policies ausgeschlossen.
Lösung: Anpassung der validation.md-Idee innerhalb von Kiro: (1) separate Ebene „Validation Specs“ erstellt – Dateien wie specs/validation/feature-X-validation.md, obligatorisch für alle Features, die Geld oder Kundendaten berühren; (2) Validation Spec enthält 47 Kontrollpunkte, gruppiert nach Risiken, mit expliziten Feldern „bestätigendes Artefakt“ (Link zu Test, Log, Review); (3) CI-Schritt „Validation Gate“ hinzugefügt – Build blockiert, wenn Validation Spec nicht vom Security-Officer geprüft; (4) Steering-Datei validation-steering.md definiert, welche Features Validation Spec erfordern; (5) Agent Hook in Kiro schlägt automatisch Validation Spec-Vorlage bei Erstellung von Specs für kritische Features vor. Somit wurde der Sinn „separater Denkebene über Qualität“ in Kiro integriert, ohne bestehende Infrastruktur zu stören.
Ergebnis: Audit-Vorbereitungszeit von 3-5 Tagen auf 2 Stunden reduziert (alle Validation Specs in einem Verzeichnis mit klarer Struktur). Erstes regulatorisches Audit ohne Beanstandungen zum Validierungsprozess. Unerwarteter Effekt: Entwickler begannen früher über Compliance nachzudenken – Validation Spec wurde in der Designphase erstellt, nicht in Hektik vor Release. Team fixierte das Muster als „Kiro Validation Extension“ und gab es an die Open-Source-Community weiter.
Gelernte Lektionen: Eine Idee aus dem „einfachen“ Lehrbuch kann bei richtiger Anpassung „Enterprise“-Probleme lösen
Verteilte Qualitätskriterien schaffen „versteckte Schulden“ – ein Single Source of Truth ist für regulatorische und Audit-Anforderungen unerlässlich
Integration neuer Artefakte in bestehende Systeme erfordert Automatisierung (CI Gate, Agent Hooks) – sonst hält Disziplin nicht
Steering-Dateien in Kiro sind ideal für Policy-Definition, Specs für konkrete Prüfungen: Dies entspricht Kiros ursprünglicher Architektur
Verwandte Konzepte: validation.md als separater Denkschritt
Drei Kiro-Ebenen für die Übertragung
Reviewbare Artefakte als Prozesskern
Prozessübertragung durch Sinnerhalt
Studientipps: Erstellen Sie eine physische oder digitale „Zuordnungskarte“: Drucken Sie die Tabelle aus dem Anhang aus und ergänzen Sie sie mit eigenen Beispielen aus Ihren Projekten – motorisches Gedächtnis und Visualisierung verstärken das Einprägen
Üben Sie den „Rückübersetzung“: Nehmen Sie eine Spezifikation im Spec Kit-Format (/speckit.specify) oder Kiro-Format (Spec-Datei) und schreiben Sie sie ins Lehrbuchformat um – dies entwickelt tiefes Strukturverständnis, nicht nur oberflächliche Namenserkennung
Führen Sie ein „Projektaudit“ durch: Welche Artefakte aus der Zuordnungstabelle existieren bei Ihnen explizit, welche sind in Chats, Erinnerungen, Aufgaben „aufgelöst“? Diese Übung deckt „versteckte Schulden“ der Spezifikationen auf
Studieren Sie durch Vergleich der drei Spalten: Für jedes Artefakt stellen Sie die Fragen – „Was wird hinzugefügt?“, „Was geht verloren?“, „Was verändert die Denkordnung?“ – dies verhindert mechanistisches Übertragen von Namen ohne Sinnerhalt
Verwenden Sie die „Szenarienmethode“: Erfinden Sie ein konkretes Team (Größe, Erfahrung, bestehende Werkzeuge) und begründen Sie die Formatwahl – besser 3 tiefe Szenarien als 10 oberflächliche
Fokussieren Sie sich auf validation.md: Dies ist die wichtigste architektonische Unterscheidung. Versuchen Sie einem Kollegen zu erklären, warum „separate Datei“ die Entwicklungspsychologie verändert – wenn die Erklärung überzeugt, haben Sie den Kern verstanden
Lesen Sie Teil 16 des Lehrbuchs parallel: Die Nachteile des vereinfachten Formats werden dort behandelt, und das Verstehen der Formatgrenzen ist kritisch für bewusste Wahl
Üben Sie „Übersetzung“ auf Prozessebene, nicht nur Artefaktebene: Wie verhält sich der Schritt /speckit.clarify in Spec Kit zur „Klärung von Mehrdeutigkeiten vor dem Plan“ im Lehrbuch? Dies erfordert Workflow-Verständnis, nicht nur Dateistruktur
Zusätzliche Ressourcen: Originallehrbuch zu sdd für qwen code: Vollständiger Kurstext, einschließlich Teil 16 über Prozessskalierung in großen Teams
Dokumentation spec kit: Offizielle Handbücher zu Befehlen /speckit.*, Presets, Erweiterungen und Integrationen
Dokumentation kiro: Handbücher zu Steering-Dateien, Specs, Agent Hooks und IDE-Integration
Vergleichende Analyse sdd-Werkzeuge: Übersichtsartikel über Spec Kit, Kiro sowie weniger bekannte Systeme (z.B. Aider, Claude Code projects)
Spezifikationsmuster in regulierten Industrien: Fälle aus Fintech, Healthtech, Aerospace darüber, wie „explizite Prüffakten“ Compliance-Aufgaben lösen
Kursquellenmaterialien (Wissensbasis): Vollständiger Kontext, auf dem dieser Leitfaden basiert – für vertieftes Studium der Zusammenhänge zwischen Abschnitten
Zusammenfassung: Anhang A zeigt, dass das Spezifikationsformat ein Werkzeug und keine Dogma ist. Der proprietäre Lehrbuchdialekt (sieben Markdown-Dateien von mission.md bis validation.md) ist bewusst für Lernen und direkte Arbeit mit Qwen Code vereinfacht, während Spec Kit und Kiro industrielle Infrastruktur für Teams, Vorlagen und Integrationen bieten. Die wichtigste architektonische Unterscheidung des Lehrbuchs – validation.md als separater Denkschritt über Qualität, der eine „Front“ von Prüffakten vor der Umsetzung schafft. Die Zuordnungstabelle ermöglicht Bewegung zwischen Systemen bei Sinnerhalt der Artefakte. Die Formatwahl hängt vom Kontext ab: Lehrbuch für Lernen und kleine Projekte, Spec Kit für Teams mit etablierten Prozessen und vielen Projekten, Kiro für tiefe IDE-Integration und Agent Hooks. Erfolgreiche Anpassung erfordert Verständnis nicht nur dessen, „was“ zu übertragen ist, sondern auch „warum“ – Intention, Plan, Prüfung und Entscheidungen müssen unabhängig von der gewählten Plattform in reviewbaren Artefakten leben.