Der offizielle Leitfaden für die erste Sitzung mit Claude Opus 5.5 nennt drei Handgriffe: die ganze Aufgabe in einer Nachricht übergeben, Aufforderungen zum gründlichen Nachdenken aus den Prompts streichen und am Ende eines langen Laufs zuerst lesen, was das Modell von der nutzenden Person braucht. Diese drei Punkte sind eine komprimierte Arbeitsanweisung, keine Marketingformel. Wer sie befolgt, arbeitet an wenigen Stellen anders – dort aber deutlich.
Claude Opus 5.5 arbeitet deutlich länger eigenständig als sein Vorgänger, gibt offen Auskunft über seine Schritte und denkt vor jeder Antwort nach. Am besten lässt sich das mit einer Fachfirma vergleichen, die ein Gebäude saniert: Sie erhält den kompletten Auftrag, kennt die Abnahmebedingung, ruft nur an, wenn eine Entscheidung ansteht, führt auf der Baustelle eine Checkliste und übergibt am Ende einen Bericht. Diese fünf Punkte strukturieren den Leitfaden – und diesen Text.
Die Ziellinie nennen, statt Zwischenschritte zu diktieren
Die wichtigste Empfehlung: die gesamte Aufgabe in einer einzigen Nachricht übergeben. Statt einzelne Schritte vorzugeben, beschreibt man, wie das Ergebnis aussehen soll – die Ziellinie. Der Leitfaden nennt als Beispiel einen Umbau im Zahlungsverkehr: Jeder Endpunkt soll den neuen Client nutzen, der alte Client soll verschwinden, die Testsuite soll durchlaufen. Damit weiß das Modell, wann es fertig ist, und muss nicht raten.
In Claude Code könnte dieser Auftrag so aussehen: Migriere die Payment-Endpunkte vom alten Client auf den neuen. Fertig heißt: Jeder Endpunkt nutzt den neuen Client, der alte Client ist gelöscht, und die Testsuite läuft durch. Melde dich nur, wenn ein Test aus einem Grund fehlschlägt, den du nicht erklären kannst. Der letzte Satz macht den Unterschied. Er verschiebt die Rückfragen von ständig auf nur dann, wenn es wirklich nötig ist.
Der Grund liegt in der Ausdauer des Modells. Opus 5.5 arbeitet laut Leitfaden länger an mehrteiligen Aufgaben als Opus 5. Am meisten bringt das dort, wo eine Änderung durch ein großes Repository getragen werden muss, bis die Tests grün sind. Frühe Tester ließen es stundenlang an Programmieraufgaben arbeiten, ohne ständig einzugreifen. Wer den Auftrag in kleine Häppchen zerlegt, nimmt dem Modell diesen Vorteil.
Eine zweite Eigenheit betrifft Gestaltungsaufträge. Ohne Vorgaben greift Opus 5.5 auf wenige Standardmuster zurück. Eine allgemeine Anweisung wie „vermeide ein generisches Aussehen“ tauscht laut Leitfaden meist nur ein Standardmuster gegen ein anderes. Hilfreicher ist eine konkrete Verbotsliste: kein cremefarbener oder gebrochen weißer Hintergrund, keine kursiven Akzentwörter in Überschriften, keine nummerierten Abschnittslabels im Stil „01 / 02 / 03“, keine Monospace-Labels, keine pillenförmigen Buttons. Danach sieht man sich an, was das Modell stattdessen gewählt hat, und ergänzt die Liste, wenn es wieder nicht passt.
„Denk gründlich nach“ streichen und das Nachdenken dem Modell überlassen
Claude Opus 5.5 denkt vor jeder Antwort nach und entscheidet selbst, wie viel Aufwand das braucht. Zeilen wie „denk gründlich nach“ oder „gehe Schritt für Schritt vor“ gehören deshalb gestrichen – nicht nur aus einzelnen Prompts, sondern auch aus gespeicherten Anweisungen. In Tests in einer Chat-Anwendung begannen die Antworten ohne eine solche Zeile früher, ohne dass die Qualität erkennbar litt. Man bittet also nicht mehr ums Denken – man bekommt es ohnehin.
Für eine schnelle Auskunft zu einer einfachen Frage sagt man das besser direkt, etwa mit „Antworte direkt“. Wer in Claude Code steuern will, wie aufwendig nachgedacht wird, ändert nicht den Prompt, sondern den Aufwandsgrad – das ist der dafür vorgesehene Hebel. Prompt-Floskeln und Effort-Einstellung sind zwei verschiedene Werkzeuge, und der Leitfaden hält sie auseinander.
Wenn dir mitten in einem Lauf etwas einfällt, musst du nicht neu starten. In Claude Code tippst du die Nachricht und drückst Enter, während Claude arbeitet, zum Beispiel: Behalte die alten Endpunktnamen zusätzlich als Alias bei. Der Leitfaden betont, dass Läufe länger dauern und ein Neustart dadurch mehr kostet als früher. Eine einzelne nachgeschobene Anweisung ist deshalb der günstigere Weg, solange die Grundrichtung stimmt.
Lange Läufe steuern: Stopps regeln, Subagenten einteilen, Checkliste auslagern
Opus 5.5 berichtet während der Arbeit, hält aber manchmal an: mit einer Zusammenfassung, die den nächsten Schritt nur nennt, ohne ihn zu gehen, mit dem Angebot fortzufahren oder mit einer Liste von Optionen, die die Arbeit gar nicht blockieren. Solche Stopps lassen sich benennen, und das Modell folgt diesen Anweisungen. Der Leitfaden schlägt dafür eine kurze Regel in der CLAUDE.md vor: Wenn ein Schritt meine Eingabe nicht braucht, mach weiter. Statusnotizen gehören in dieselbe Nachricht wie die nächste Aktion. Halte nur an, wenn du ohne mich nicht weitermachen kannst oder bevor etwas Destruktives passiert: Daten löschen, Force-Push oder Änderungen außerhalb dieses Repositorys. Die letzte Zeile sorgt dafür, dass die eigene Kontrolle erhalten bleibt; Berechtigungsabfragen für destruktive Befehle sollten zusätzlich aktiv bleiben.
Antwortet man auf ein „Soll ich fortfahren?“ mit „weiter“, läuft die Aufgabe weiter. Passiert das häufig, hilft die Regel aus der CLAUDE.md. Wer lieber im Pair-Programming arbeitet, dreht die Vorgabe um und verlangt einen einzeiligen Plan vorab plus kurze Zusammenfassung am Ende. Opus 5.5 folgt laut Leitfaden beiden Varianten; man muss sich nur entscheiden.
Für Audits, Migrationen oder Reviews über eine große Codebasis empfiehlt der Leitfaden, die Arbeit auf Subagenten zu verteilen und jedes Ergebnis prüfen zu lassen. Ein passender Auftrag lautet: Prüfe jeden Service in services/ auf den Retry-Bug aus dem verlinkten Issue. Gib jeden Service an einen eigenen Subagenten. Wenn ein Subagent Bericht erstattet, prüfe seine Belege, bevor du sie akzeptierst. Schließe mit einer Tabelle ab: Service, betroffen ja oder nein, Belege. Frühe Tester ließen Opus 5.5 auf diese Weise parallele Subagenten koordinieren, mit wenig Aufsicht.
Für sehr lange Läufe rät der Leitfaden, die Aufgabenliste in eine Datei auszulagern: Führe eine Checkliste in TASKS.md. Hake jeden Punkt ab, wenn er erledigt ist, und ergänze alles Neue, das du findest. Warum das hilft: Ein langer Lauf füllt das Kontextfenster, und Claude Code fasst ältere Turns irgendwann zusammen. Eine Liste in einer Datei übersteht diese Komprimierung und zeigt auf einen Blick, was erledigt ist und was noch aussteht. Man liest also die Datei, nicht den Scrollback.
Ergebnisse prüfen, bevor du sie übernimmst
Am Ende eines langen Laufs liest man zuerst, was das Modell von dir will: eine offen gelassene Entscheidung, eine Freigabe für eine Änderung. Erst danach den Rest der Zusammenfassung. Opus 5.5 berichtet klarer über seine Arbeit als Opus 5 und benennt in einfacher Sprache, was es getan hat, was es gefunden hat und was es braucht. Wer das Format ändern will, schreibt es in die CLAUDE.md, etwa: Beende jeden Lauf mit drei Überschriften: Blocked on me, Changed, Found.
Bevor ein Mensch den Diff liest, kann Opus 5.5 ihn oder einen Pull Request prüfen. Der passende Auftrag lautet: Prüfe den Diff dieses Branches gegen main. Liste nur Probleme auf, wegen derer du den Merge blockieren würdest. Nenne für jedes die Datei und Zeile, warum es falsch ist und wie man zeigt, dass es fehlschlägt. Ein früher Tester berichtete, Opus 5.5 habe selbst mit niedrigstem Aufwand mehr Fehler gefunden als Opus 5 mit hohem Aufwand, bei weniger Fehlalarmen. Außerdem erklärt es seine Änderungen in klarer Sprache, was Pull-Request-Beschreibungen leichter prüfbar macht.
Für Recherche und Analyse lohnt eine zusätzliche Anweisung: Markiere alles, was du nicht bestätigen konntest, und sag, wo du gesucht hast. Ein ehrliches „Das konnte ich nicht finden“ ist wertvoll, und wenn man danach fragt, findet man es auch leichter im Text. Der Hinweis funktioniert in einem Recherchebericht genauso wie in Claude Code.
Arbeiten in den Claude-Apps: Bilder, lange Dokumente, fertige Dateien
Zuerst der Blick auf die Modellauswahl: Dort sollte Claude Opus 5.5 stehen. Für Diagramme, Screenshots und Folien gilt dann die einfache Regel, das Material anzuhängen statt Zahlen abzutippen. Opus 5.5 liest Charts, Diagramme und Screenshots genauer als Opus 5, ohne dass es dafür zusätzlicher Schritte bedarf. Es versteht auch Bedeutung, die von der Position im Bild abhängt: welche Kästen ein Pfeil verbindet, was sich zwischen zwei Versionen eines Diagramms geändert hat oder wann ein Termin in einem Kalender-Screenshot beginnt und endet. Eine konkrete Frage wie „Welche dieser Services rufen die Billing-API direkt auf?“ nutzt das am besten aus.
Lange Dokumente lassen sich gezielt auf Widersprüche prüfen: Prüfe dieses Deck auf alles, was sich widerspricht: Zahlen, Daten, Namen. Zitiere jedes Problem und nenn die Stelle. Laut Leitfaden fiel dem Modell in einem langen Planungsthread ein Datum auf, das auf den falschen Wochentag fiel, und in einer Präsentation ein Diagramm, das nicht zu den Zahlen passte. Wer eine Tabelle oder ein Dokument braucht, fragt nach der Datei und nicht nach einer Gliederung; die erzeugten Dateien brauchen vor dem Teilen weniger Nacharbeit als bei Opus 5. Ein Beispiel: Mach daraus eine Tabelle, die ich teilen kann: eine Zeile pro Anbieter, mit Spalten für Kosten, Vertragsende und Verantwortliche.
In langen Chats kann es vorkommen, dass Opus 5.5 eine frühere Antwort noch einmal durchgeht, während es über eine kurze Rückfrage nachdenkt. Das bremst die Antwort. Dagegen hilft in den Projektanweisungen der Satz: Was du einmal beantwortet hast, gilt als erledigt. Konzentriere dich auf meine aktuelle Frage und geh nicht auf eine frühere Antwort zurück, außer ich frage danach oder weise auf ein Problem hin. In Projekten für lange Analysen lässt man diese Anweisung besser weg, weil dort ein späterer Schritt durchaus einen Fehler in einem früheren aufdecken kann.
Markierte Nachrichten: Schutzmechanismen und der Wechsel auf ein älteres Modell
Claude Opus 5.5 ist das erste Opus-Modell, das mit Bio- und Cyber-Schutzmechanismen auf dem Niveau von Fable startet. In den Claude-Apps und in Claude Code wandern die meisten markierten Nachrichten zu einem älteren Modell, und die Arbeit läuft dort weiter. Das Suchen von Sicherheitslücken im Quellcode ist ausdrücklich erlaubt, und alltägliche Gesundheits- und Bildungsfragen sollten weiterhin funktionieren. Der Leitfaden räumt ein, dass die Schutzmechanismen gelegentlich legitime Arbeit markieren, und man arbeitet daran, falsche Markierungen zu reduzieren.
In den Claude-Apps erscheint ein Hinweis, der mit „Switched to“ und dem Namen eines älteren Modells beginnt. Die Antwort kommt dann von diesem Modell, und der Chat bleibt dort. Zurück zu Opus 5.5 geht es über die Modellauswahl; liegt die frühere Nachricht noch im Chat, kann sie erneut markiert werden, weshalb ein neuer Chat das Problem umgeht. Wer vorher gefragt werden möchte, schaltet unter Einstellungen und dann Fähigkeiten die Option „Switch models when a message is flagged“ ab und bekommt stattdessen eine pausierte Karte mit den Optionen. Die Prüfung umfasst die gesamte Konversation inklusive Dateien und Suchergebnissen, eine Markierung kann also aus älterem Inhalt stammen und nicht nur aus der letzten Nachricht.
Für Claude Code beschreibt der Leitfaden denselben Ablauf: Auch dort erscheint ein Hinweis auf den Modellwechsel, und die Arbeit wird auf dem älteren Modell fortgesetzt, statt abzubrechen. Nur der Ort der Anzeige unterscheidet sich. Wer regelmäßig mit sicherheitsnahen Themen arbeitet, sollte die Markierungen als Teil des Werkzeugverhaltens einplanen und nicht als Fehler behandeln.
Bei Claude Opus 5.5 geht es weniger um neue Schaltflächen als um eine andere Arbeitsweise. Aufträge werden vollständig übergeben, das Denken nicht mehr per Prompt eingefordert, Stopps vorher definiert, Checklisten liegen in Dateien statt im Verlauf. Am Ende liest man zuerst den Bericht, dann den Code. Wer diese fünf Gewohnheiten in einer CLAUDE.md und in den Projektanweisungen hinterlegt, spart sich die Rückfragen, die früher selbstverständlich waren. Die Rollen verschieben sich: weniger Taktgeber, mehr Auftraggeber mit klarer Abnahme.
Quelle: claude.dev
