flriancu/claude-code-setup

Anforderungs-Kickoff

Der Benutzer trifft Entscheidungen explizit und günstig im Voraus und baut dann in überprüften Schritten auf. Ein One-Shot-Build enthält Annahmen, die später mühsam rückgängig gemacht werden müssen. Lange stille Überlegungen, bevor etwas auf Papier ist, nerven ihn genauso („kein Grund für One-Shot, warum das lange Nachdenken? lass uns einen Entwurf mit Phasen machen“). Also stell Fragen und einen Plan schnell auf Papier und lass ihn lenken.

1. Sammeln, kurz

• Lies, was bereitgestellt wurde: Dateien, Ordner, Links, Bilder, frühere Chats und Notizen, die README des Repos. Notiere, was bereits entschieden ist, damit du es nicht noch einmal fragst.
• Wenn eine Eingabe noch fehlt („Link kommt gleich“, „Foto kommt später“), beginne trotzdem mit den Fragen und markiere, welche davon abhängen.
• Schreibe noch keinen Code und ändere keine Dateien. Denke nicht lange nach: Die Fragen sind das Denkwerkzeug.

2. Nummerierte Fragen stellen

• Eine nummerierte Liste, gruppiert nach Thema, wenn es viele gibt. Jede Frage ist eine Zeile mit den Optionen, die du siehst, und deiner empfohlenen Voreinstellung, zum Beispiel: 3. Installationsort: C: oder D:? Empfohlen: D:, da C: fast voll ist.
• Der Benutzer antwortet knapp mit Nummern („1. beides 2. aktualisieren 3. ok“). Ordne jede Antwort sorgfältig zu. „ok“ oder „einverstanden“ akzeptiert deine Voreinstellung; „ersteres“ und „letzteres“ beziehen sich auf die Reihenfolge deiner Optionen; eine übersprungene Nummer bedeutet „deine Entscheidung, sag mir, was du gewählt hast“.
• Decke ab, was für dieses Vorhaben wichtig ist: Ziel und Zielgruppe; Umfang und explizite Nicht-Ziele; Eingaben und Ausgaben (Formate, Orte); Einschränkungen (Plattform, erlaubte oder verbotene Tools, Lizenzen, Offline-Nutzung, Hardware); Qualitätsniveau und Abnahmetest („woran erkennen wir, dass es funktioniert“); Fehlerverhalten (was passiert, wenn jeder Teil zu jedem Zeitpunkt ausfällt: ein Absturz, eine verlorene Verbindung, ein Stromausfall, ein Knoten von mehreren fällt aus); Treue (was niemals verändert werden darf); wo Dinge leben (Repo, Pfade, Remote); Auslieferung (wer erhält was, wie oft).
• Führe eine zweite, kürzere Runde nur für Antworten durch, die neue Fragen aufgeworfen haben. Höre auf zu fragen, sobald die verbleibenden Unbekannten sichere Voreinstellungen haben, und liste diese Voreinstellungen stattdessen auf.

3. Den Vertrag schreiben: REQUIREMENTS.md

Lege ihn im Projektstamm an, erstelle den Ordner, wenn das Projekt neu ist. Halte ihn einfach, kurz und datiert:

# <Projekt> Anforderungen

Vereinbart am <YYYY-MM-DD>. Diese Datei ist der Vertrag; Änderungen werden hier mit einem Datum festgehalten.

## Ziel
## Zielgruppe und Nutzung
## Umfang
## Nicht-Ziele
## Entscheidungen
- E-01 <Entscheidung> (<Datum>)
## Funktionale Anforderungen
- FA-01 ...
## Einschränkungen und nicht-funktionale Anforderungen
- NFA-01 ...
## Verifikation
Eine Zeile pro Anforderung: wie sie verifiziert wird und wo der Nachweis lebt.
| ID | Methode (Test / Inspektion / Analyse / Demonstration) | Nachweis (Testfall, Skript, Datei) |
## Offene Fragen

Stabile IDs (E-xx, FA-xx, NFA-xx) ermöglichen es, spätere Arbeiten, Commits und Berichte darauf zu beziehen. Halte die Antworten des Benutzers in seinen eigenen Worten fest; paraphrasiere sie nicht zu etwas Stärkerem oder Schwächerem um.

Gib jeder Anforderung eine Verifikationsmethode und einen Nachweisort. Die vier Methoden sind die Standardmethoden aus dem Anforderungsmanagement (ISO/IEC/IEEE 29148). Bevorzuge einen Test. Wenn eine Anforderung nur durch Inspektion oder Analyse überprüft werden kann („keine direkten OS-Thread-Aufrufe“, „Planungs-Overhead unter 100 Mikrosekunden pro Knoten“), schreibe die Überprüfung als Skript, das seine Ausgabe als Nachweis speichert, sodass der Beweis wiederholt und nicht neu diskutiert werden kann.

4. Den Plan schreiben: Phasen

Lege ihn neben den Anforderungen in PLAN.md ab, oder in einem Abschnitt „Phasen“, wenn das Projekt klein ist. Phase 0 ist normalerweise das Setup oder ein Pilot, der zuerst die riskanteste Annahme beweist. Gib für jede Phase das Ziel, die Schritte, das Arbeitsergebnis, wie es verifiziert wird, und die Anforderungs-IDs, die es bedient. Halte die Phasen klein genug, um sie in einer Sitzung zu überprüfen, und sage, dass der Plan unterwegs angepasst wird.

Dann stoppe. Berichte die beiden Dateien in ein paar Zeilen und empfehle die erste Phase.

5. Auf Anfrage ausführen, eine Phase nach der anderen

• Führe nur die Phasen aus, die der Benutzer nennt („Phase 0 ausführen“, „Phasen 0 und 1 ausführen“, „los“).
• Berichte am Ende jeder Phase, was getan wurde, den Nachweis, dass es funktioniert (ausgeführte Befehle, Ausgaben, Testergebnisse), was vom Plan abgewichen ist und warum, und was als nächstes kommt. Markiere die Phase im Plan als erledigt.
• „Fortschrittskontrolle“ bedeutet: aktuelle Phase, was ist erledigt, was läuft, was ist blockiert.
• Ein neuer Wunsch, der den Umfang ändert, wird mit seinem Datum in REQUIREMENTS.md eingetragen, bevor du ihn baust. Eine rückgängig gemachte Entscheidung wird als Rücknahme festgehalten; die alte Zeile bleibt bestehen.
• Behebe Bugs, die unterwegs gefunden werden, wenn der Benutzer es gesagt hat; anderweitig liste sie auf.
• Wenn die letzte Phase erledigt ist, oder wenn der Benutzer darum bittet, führe eine Lückenanalyse durch: Anforderungen gegen Code, Tests, Dokumentation und Nachweise. Melde jede Lücke mit ihrer Anforderungs-ID, behebe sie eine nach der anderen auf Anfrage und führe die Nachweisskripte erneut aus.
• Committe oder pushe nicht nach jedem Schritt. Schlagen einen Commit vor, wenn eine Phase abgeschlossen ist; pushen nur auf Aufforderung.

Varianten

• Entscheidungen ohne Code (ein Kauf, eine Tool-Auswahl): gleiche Fragen, dann ein kurzer Vergleich mit den vereinbarten Kriterien anstelle der zwei Dateien.
• Inhalte von anderen (das Buch eines Autors, Daten eines Kunden, Aufnahmen): füge eine Treueanforderung von Anfang an hinzu. Nichts im Inhalt ändert sich stillschweigend; jede Änderung wird vorgeschlagen, markiert und zur Genehmigung gemeldet.