Claude Code: Alle Befehle gelernt, trotzdem blockiert? So gelingt der erste Schritt

An einem Freitagabend schrieb mir ein jüngerer Kollege auf Slack: “Ich hab alle Claude-Code-Befehle gelernt, aber ich weiß nicht, was ich als Nächstes eintippen soll, und sitze hier fest.” Er kann /init aufsagen, /clear, claude -p sowieso. Trotzdem erstarren seine Finger, sobald er vor seinem eigenen Repository sitzt.

Das ist kein Problem des Könnens. Eine Befehlsübersicht ist nur eine Liste mit “Namen von Werkzeugen”. Was zuerst, wie weit und mit welcher Kontrolle übergeben wird, steht da nicht drin. Deshalb gibt es Leute, die umso bewegungsunfähiger werden, je mehr sie auswendig lernen.

In diesem Artikel geht es genau darum: wie du aus dem “Ich kann alles, komme aber nicht in Gang” herauskommst und deinen allerkleinsten ersten Schritt machst.

Das Wichtigste in Kürze

• Dass du trotz gelernter Befehle stecken bleibst, liegt daran, dass vier Dinge nicht festgelegt sind: erlaubter Umfang, gesperrte Dateien, Rückweg und Nachweis.
• Das erste Ergebnis darf winzig sein: “nur einen Absatz korrigieren” oder “nur die Bedeutung eines roten Tests erklären lassen”.
• Wenn du vor dem Übergeben nicht ums Bearbeiten, sondern erst um “nur den Plan” bittest, sinkt die Zahl der Unfälle drastisch.
• Lege den Nachweis nicht über das menschliche Auge fest, sondern vorab über einen maschinell lesbaren Befehl wie git diff.
• Wenn du sicherer wirst, stufst du nur die als sicher erkannten Aktionen schrittweise zu “automatisch” hoch.

Warum du trotz Befehlsliste erstarrst

Eine Befehlsliste ist auf der Landkarte wie eine “Liste der Verkehrsschilder”. Selbst wenn du alle Schilder benennen kannst, fährt das Auto nicht los, solange Ziel und Abbiegestelle nicht feststehen.

Wer feststeckt, dem fehlt kein Wissen, sondern die Gewohnheit, diese vier Punkte in Worte zu fassen:

• Welche Datei soll gelesen werden und welche bleibt unberührt?
• Wie klein schneide ich die erste Änderung zu?
• Was ist die Bedingung dafür, dass es geklappt hat (woran erkenne ich Erfolg)?
• Wie mache ich es rückgängig, wenn es schiefgeht?

Auch ich habe am Anfang mit “Mach dieses Projekt irgendwie schön” alles abgewälzt und stand dann vor einem Diff mit 30 geänderten Dateien wie versteinert. Einen Diff, den man nicht lesen kann, kann man nicht prüfen. Eine Änderung, die man nicht prüfen kann, traut man sich aus Angst nicht zu übernehmen. Deshalb ist es richtig, am Anfang lächerlich klein zu beginnen.

Der erste Schritt darf so klein sein

Bei “Ergebnis” denkt man schnell an eine große neue Funktion, aber am Anfang reicht dieses Niveau völlig:

• Die Einleitung der README in nur 3 Zeilen lesbarer machen.
• Dem Hinweistext unter einem Artikel nur einen Satz hinzufügen.
• Die Bedeutung eines durchfallenden Tests erklären lassen, “ohne ihn zu reparieren”.

Der dritte Punkt ist besonders empfehlenswert. Weil keine einzige Codezeile geändert wird, kann gar nichts kaputtgehen. Trotzdem bekommst du sauber das erste Gefühl: “Claude Code hat mein eigenes Repository gelesen, und eine Antwort kam zurück.” Wer feststeckt, sollte genau hier zuerst die Finger bewegen.

Was du übergibst und was der Mensch entscheidet

Welche Arbeit du an Claude Code übergibst und welches Urteil der Mensch behält, trennst du von Anfang an klar. Lässt du es unklar laufen, schreitet das Tool meist eigenmächtig bis zu Stellen voran, die der Mensch entscheiden sollte.

Situation	An Claude Code übergeben	Der Mensch entscheidet
Umfang festlegen	Kandidatendateien suchen und vorschlagen	Endgültige Festlegung des erlaubten Bereichs
Bearbeiten	Entwurf von Text und Code	Ob übernommen wird
Prüfen	Test ausführen, Diff zusammenfassen	Urteil, ob veröffentlicht werden darf
Riskante Aktionen	Nur den Vorschlag zum Vorgehen	Löschen, Produktiv-Deploy, Zahlung ausführen

Der Punkt ist die rechte Spalte. Löschen, das Einspielen in die Produktivumgebung, Aktionen, bei denen Geld fließt, und schwer rückgängig zu machende Operationen wie git push --force legst du am Anfang allesamt auf “der Mensch drückt” fest. Nur was du selbst als sicher bestätigt hast, verschiebst du später nach links. Allein diese Reihenfolge einzuhalten, senkt deutlich, wie oft du dir nachts kalten Schweiß einhandelst.

Lass dir zuerst “nur den Plan” zurückgeben

Der Trick ist, nicht sofort bearbeiten zu lassen. Bei der ersten Bitte lässt du keine Hand rühren, sondern nur den Plan nennen. Die folgende Prompt-Vorlage kannst du direkt einfügen und nutzen.

Ich bitte dich gleich um genau eine kleine Änderung. Bearbeite noch nichts.
Gib mir zuerst die folgenden 4 Punkte als Aufzählung zurück.

1. Datei, die du anfasst (nur eine)
2. Dateien, die du nicht anfasst (.env sowie alles rund um Auth und Abrechnung niemals anfassen)
3. Inhalt der Änderung (Verhalten nicht ändern, nur den Text korrigieren)
4. Befehl, mit dem ich nach der Änderung prüfe (z. B. git diff)

Beginne erst mit dem Bearbeiten, nachdem ich diese 4 Punkte freigegeben habe.

Schau dir die zurückkommenden 4 Punkte an: Ist die anzufassende Datei auf eine eingegrenzt und steht sogar der Prüfbefehl dabei, dann passt die Körnung der Bitte. Kommt umgekehrt eine Antwort wie “Ich überprüfe das gesamte Repository”, ist das ein Zeichen, dass deine Bitte noch zu weit gefasst war. Grenze den Umfang ein und bitte in derselben Form noch einmal.

Wenn dir das Formulieren der Bitte schwerfällt, bilden Prompt-Design für Claude Code und So schreibst du eine CLAUDE.md das Fundament. Übergibst du die Projektregeln vorab, steigt die Qualität des Plans noch einmal eine Stufe.

Eine Checkliste zum Kopieren für den ersten Schritt

Die vier Punkte im Kopf jedes Mal in eine Datei zu schreiben, ist lästig. Deshalb lege ich hier ein kleines Skript ab, mit dem schon durch reines Beantworten ein “Notizzettel für den ersten Schritt” entsteht. Es läuft, sobald Node.js vorhanden ist.

// first-win.mjs — formuliert den ersten Schritt in einer Minute aus
// Verwendung: node first-win.mjs

const plan = {
  ziel: "Mit Claude Code eine kleine Änderung sicher durchbringen",
  anfassen: ["README.md"],                 // auf eine eingrenzen
  nichtAnfassen: [".env", "Auth", "Abrechnung", "Produktions-DB"],
  ersterBefehl: "git status --short",      // aktuellen Stand prüfen
  aenderung: "Einleitung in 3 Zeilen lesbarer machen, Verhalten nicht ändern",
  pruefung: "git diff -- README.md",       // ist der Diff lesbar?
  rueckweg: "git checkout -- README.md",   // bei Problemen sofort zurück
};

// Prüfung: Ist die anzufassende Datei auf eine eingegrenzt?
if (plan.anfassen.length !== 1) {
  console.error("⚠ Grenze die anzufassende Datei am Anfang auf eine ein");
  process.exit(1);
}

console.log("=== Notizzettel für den ersten Schritt ===");
for (const [key, value] of Object.entries(plan)) {
  const text = Array.isArray(value) ? value.join(", ") : value;
  console.log(`${key}: ${text}`);
}
console.log("\nDiesen Zettel in Claude Code einfügen und sagen: 'Gib vor dem Bearbeiten den Plan zurück'");

Ausgeführt wird es so:

node first-win.mjs

Den entstandenen Zettel fügst du direkt in Claude Code ein und nutzt ihn zusammen mit der obigen “Gib nur den Plan zurück”-Vorlage. Das Skript bricht in der ersten Zeile ab, sobald mehr als eine Datei angefasst werden soll, und dient so auch als Bremse, wenn du mal gierig wirst.

Drei Einsatzstellen, die wirklich funktioniert haben

Hier drei Beispiele, die ich oder Leute um mich herum als “ersten Schritt” gewählt haben und mit denen es sauber vorwärtsging.

1. Die README-Einleitung korrigieren. Für Leser, die wegen eines Befehls vorbeischauen, nur die ersten 3 Zeilen vereinfachen. Die Prüfung läuft allein über git diff, also bekommst du auf kürzestem Weg das Gefühl, einen Diff lesen zu können. Hier wächst dein Selbstvertrauen.

2. Dem Hinweistext unter dem Artikel einen Satz hinzufügen. An einer dünn erklärten Stelle nur einen Satz ergänzen und über die öffentliche URL prüfen, ob das Linkziel lebt. Da es nur eine Textänderung ist, besteht keine Gefahr, Code kaputtzumachen.

3. Die Bedeutung eines durchfallenden Tests erklären lassen. Hier lässt du nichts reparieren. Lass dir nur drei Dinge zurückgeben: “Bedeutung des Fehlers”, “wahrscheinlich beteiligte Dateien” und “die Stelle, die der Mensch als Nächstes ansieht”. Ohne eine einzige Codezeile anzufassen, übst du, die Ursache einzukreisen.

Allen dreien gemeinsam ist, dass die Prüfung mit einem Befehl erledigt ist und du selbst bei einem Fehlschlag in einer Sekunde zurück bist. Wer kein Entwickler ist, dem hilft zusätzlich Claude Code für Nicht-Entwickler, um leichter einen textnahen ersten Schritt auszuwählen.

Häufige Fallstricke und wie du sie behebst

Fallstrick 1: Direkt nach dem Blick auf die Befehlsliste “Mach dieses Repository besser” auftragen. Der Umfang ist zu weit, und der zurückkommende Diff wird unlesbar. Die Behebung ist simpel: auf “1 Datei, 1 Absatz” eingrenzen. Je enger, desto sicherer wird das erste Ergebnis.

Fallstrick 2: Die Prüfmethode aufschieben. Lässt du es laufen, ohne festzulegen, woran man Erfolg erkennt, weißt du selbst bei einem plausibel aussehenden Ergebnis nicht, ob du es übernehmen darfst. Schreibe von Anfang an einen Prüfbefehl wie git diff in deine Bitte.

Fallstrick 3: Riskante Aktionen sofort übergeben. Stellst du Löschen oder Produktiv-Deploy von Anfang an auf automatisch, führt das zu nicht rückgängig machbaren Unfällen. Lege am Anfang alles auf “der Mensch drückt” fest und stufe nur das, was du als sicher bestätigt hast, zu automatisch hoch.

Häufige Fragen

F. Wie viele Befehle muss ich können, bevor ich anfange? A. Drei reichen: /init, /clear und git diff zum Prüfen der Änderung. Den Rest schlägst du nach, wenn die Situation kommt. Klein loszulegen, bevor du auswendig lernst, prägt sich am Ende schneller ein.

F. Welche Aufgabe eignet sich am besten als erster Schritt? A. Die Bedeutung eines durchfallenden Tests “nur erklären” zu lassen. Weil kein Code geändert wird, kann nichts kaputtgehen, und du bekommst dennoch das Gefühl, das Repository lesen zu lassen. Den Grundablauf habe ich auch im Einstiegsleitfaden zusammengefasst.

F. Ich habe um einen Plan gebeten, aber es fängt sofort an zu bearbeiten. A. Setze “Bearbeite noch nichts” an den Anfang der Vorlage und füge am Ende “Warte auf meine Freigabe” hinzu. Geht es trotzdem voran, ist meist der Änderungsumfang unklar, also begrenze die anzufassende Datei namentlich auf genau eine.

F. Reicht es nicht, mit dem menschlichen Auge zu prüfen? A. An einem hektischen Tag scheitert das garantiert. Legst du vorab maschinell lesbare Prüfungen fest, etwa Zeichenzahl, Diff oder Test-Erfolg, sinken die Übersehen. Der Trick ist, das menschliche Urteil auf “Übernehmen oder nicht” zu konzentrieren.

F. Was mache ich, wenn ich sicherer geworden bin? A. Denselben “Notizzettel für den ersten Schritt” auf etwas größere Aufgaben ausweiten. Auch wenn mehr Prüfbefehle dazukommen, änderst du das Prinzip nicht, dass der Mensch riskante Aktionen behält. Für Kniffe, die die Arbeit beschleunigen, hilft Tipps zur Produktivität.

Was beim Test tatsächlich herauskam

Den Kollegen vom Anfang habe ich zuerst den Schritt “nur die Bedeutung eines durchfallenden Tests erklären lassen” machen lassen. Code wird nicht angefasst. Zurück kam der Dateiname der Ursache und die Stelle der Funktion, die er als Nächstes ansehen sollte. Er sagte “Das schaffe ich” und kam noch am selben Tag bis zur 3-Zeilen-Korrektur der README.

Auch bei mir selbst ist, seit ich aufgehört habe, alles abzuwälzen, und stattdessen ein “Gib nur den Plan zurück” einschiebe, die Zeit fast verschwunden, in der ich vor einem unlesbaren Diff erstarre. Nur was sich mit git diff prüfen lässt auftragen, riskante Aktionen drückt der Mensch. Allein diese zwei einzuhalten, macht den ersten Schritt erstaunlich leicht. Du musst nicht alle Befehle auswendig können. Klein loslegen und den rückgängig machbaren Umfang abklopfen. Von da aus zu starten reicht völlig.

Wer das Lernen eine Stufe weiterbringen will, schaut in die Materialübersicht; wer beraten möchte, wie man es ins betriebliche Geschäft bringt, in Schulung und Beratung. Das genaue Verhalten der Befehle ist als Primärquelle am sichersten in der offiziellen Dokumentation nachzulesen.