Erst fragen, dann bauen: Ein Interview-Workflow für Claude Code

Ich wollte Caching für eine API. Claude baute eine Lösung mit Redis, nur brauchte ich In-Memory mit Invalidierung. Also alles löschen, von vorn anfangen.

Das eigentliche Problem ist nicht Claude. Es ist das Raten.

Warum Claude nicht fragt

Claude Code hat ein undokumentiertes Werkzeug namens AskUserQuestion.¹ Es unterbricht den Workflow für Multiple-Choice-Rückfragen. So entscheide ich vor der Implementierung, nicht danach durch Korrektur.

Nur nutzt Claude das Tool zu selten. Bei Mehrdeutigkeit entscheidet es eigenständig und baut, was plausibel erscheint.

Claude zum Fragen bringen

Das Frageverhalten lässt sich über die Datei CLAUDE.md steuern. Meine Regeln:

## Interview-Verhalten

Bei neuen Features oder Änderungen mit Entscheidungsspielraum:
- IMMER erst Anforderungen klären bevor Code geschrieben wird
- Nutze AskUserQuestion proaktiv bei:
  - Mehreren möglichen Implementierungen
  - Unklarem Scope
  - Entscheidungen die andere Systemteile betreffen
- Stelle 1-2 Fragen pro Durchgang
- Frage nach Edge Cases und Fehlerverhalten
- Frage was explizit NICHT passieren soll

Die Regeln liegen im Repository-Root oder global unter ~/.claude/CLAUDE.md.

Der Interview-Command

Diese Regeln verbessern das Frageverhalten, doch für mehrstufige Aufgaben nutze ich einen eigenen Slash Command. Er liegt unter .claude/commands/interview.md:

Du bist ein Requirements Engineer. Deine EINZIGE Aufgabe: Mich interviewen.

## Kontext
$ARGUMENTS

## Regeln
1. Nutze AUSSCHLIESSLICH das AskUserQuestion Tool
2. Stelle 1-2 Fragen pro Durchgang
3. Frage nach:
   - Technische Entscheidungen
   - Edge Cases
   - Fehlerverhalten
   - Was explizit NICHT passieren soll
4. Keine offensichtlichen Fragen
5. Kein Code schreiben

## Ablauf
1. Lies relevante Dateien im Projekt (falls nötig)
2. Interview führen bis alles geklärt
3. Am Ende: Schreibe Spezifikation als Markdown-Datei

## Output
Speichere die Spec im Projekt (z.B. specs/, docs/ oder Projektroot)

Der Aufruf /interview Error Handling verbessern startet das Interview. Entscheidend ist die Anweisung, keinen Code zu schreiben, denn ohne sie implementiert Claude nach den Fragen sofort.

Wer den Projektkontext einbaut, bekommt bessere Fragen. Für eine API könnte der Command so aussehen:

Du bist ein API-Designer. Interviewe mich zu einem neuen Endpoint.

## Kontext
$ARGUMENTS

Lies zuerst:
- Die bestehenden Controller in src/controllers/
- Das Error-Handling in src/middleware/error.ts
- Die API-Konventionen in docs/api-conventions.md

## Fragen die du stellen solltest
- HTTP-Methode und Pfad
- Request/Response-Schema
- Authentifizierung nötig?
- Welche Fehler können auftreten?
- Rate Limiting?

Am Ende steht eine Markdown-Datei: die Spec für die Umsetzung.

Wann es sich lohnt

Ein Interview lohnt sich, wenn mehr als ein plausibler Lösungsweg existiert. Bugfixes mit klarer Ursache brauchen keines, ebenso wenig wie Aufgaben mit dokumentierten Requirements.

Der eigentliche Wert liegt nicht in der Spec am Ende, sondern im Nachdenken, das die Fragen erzwingen.

In der Praxis

Ohne Interview baut Claude ein generisches Error-Schema mit Logging und ist fertig. Mit Interview sieht das anders aus:

Ich: “Ich will das Error Handling in meiner API verbessern.”

Claude fragt:

1. Fehlertypen: “Welche Kategorien von Fehlern sollen unterschieden werden?” (Validation vs. Business Logic vs. System)
2. Client-Kommunikation: “Wie sollen Fehler an den Client kommuniziert werden?” (Nur HTTP Status oder detailliertes Error-Objekt?)
3. Logging: “Soll strukturiertes Logging integriert werden?”
4. Unerwartete Fehler: “Was passiert bei unerwarteten Exceptions?”

Die resultierende Spec:

# Error Handling Refactoring

## Scope
- Validation Errors: 400 mit feldspezifischen Messages
- Business Logic Errors: 422 mit Error-Code
- System Errors: 500 mit Correlation-ID

## Response Schema
{
  "error": "ERROR_CODE",
  "message": "Lesbare Beschreibung",
  "details": [{"field": "email", "message": "Ungültiges Format"}],
  "correlationId": "uuid"
}

## Logging
- Alle Errors loggen mit Correlation-ID
- System Errors: Alert an Monitoring

## Nicht im Scope
- Retry-Mechanismen
- Circuit Breaker

Ohne Regeln in der CLAUDE.md fragt Claude selten von sich aus. Aber die fünf Minuten für die Einrichtung lohnen sich spätestens beim nächsten Feature, das auf Anhieb funktioniert.