Fable ist zurück. So codest du wirklich damit.

Fable ist zurück.

Nach dem Exportkontroll-Chaos im Juni hat Anthropic den Zugang zu Claude Fable 5 wiederhergestellt. Seit dem 1. Juli 2026 ist Fable global wieder verfügbar über Claude.ai, Claude Platform, Claude Code und Claude Cowork, und Anthropic reaktiviert den Zugang auch auf AWS, Google Cloud und Microsoft Foundry so schnell wie möglich.

Aber die Rückkehr kommt mit einem sehr wichtigen Vorbehalt.

Fable ist jetzt durch strengere Safety-Klassifizierer geschützt. Wenn diese Klassifizierer entscheiden, dass eine Anfrage zu nah an hochriskantem Terrain aus Cybersecurity, Biologie oder Reasoning-Extraction liegt, kann die Anfrage blockiert und stattdessen an Claude Opus 4.8 geroutet werden. Anthropic sagt außerdem, dass der neue Klassifizierer eher harmlose Coding- und Debugging-Aufgaben markiert, während sie die False-Positives herunterjustieren.

Deshalb erleben manche Entwickler etwas, das sich wie dieses Verhalten anfühlt:

"Ich habe Fable ausgewählt, es zum Coden gebeten, und es ist zu Opus 4.8 gewechselt."

Die verständliche Reaktion lautet: "Also kann Fable nicht mehr coden?"

Ich halte das für die falsche Schlussfolgerung.

Die bessere Schlussfolgerung lautet:

Fable kann fürs Coding weiterhin extrem nützlich sein, aber du musst aufhören, es wie ein generisches Autocomplete-Modell zu benutzen. Nutz es wie einen Staff Engineer, Architekten, Migrationsplaner, Debugging-Lead und finalen Reviewer.

Dieser Wechsel zählt.

Anthropics eigener Fable-Prompting-Guide sagt, dass Fable bei komplexer, mehrdeutiger, langlaufender Arbeit am stärksten ist: die Art von Arbeit, die einen Menschen Stunden, Tage oder Wochen kosten könnte. Er hebt speziell stärkere Long-Horizon-Autonomie hervor, Code-Review, Debugging außerhalb eingeschränkter Cybersecurity-Kategorien, Repository-History-Suche, den Umgang mit Mehrdeutigkeit und Subagent-Delegation.

Die Frage ist also nicht: "Kann Fable coden?"

Die eigentliche Frage lautet: "Wo sollte Fable in meinem Coding-Workflow sitzen, damit ich maximalen Wert bekomme, ohne ständig ins Fallback zu laufen?"

Hier ist das praktische Playbook.

1. Nutze Fable für Urteilsvermögen, nicht für Tastenanschläge

Der schnellste Weg, Fable zu verschwenden, ist, es für jede kleine Änderung zu bemühen.

Nutz es nicht für:

• Winzige Syntax-Fixes
• Einfache CRUD-Änderungen
• Variablen umbenennen
• Formatierung
• Boilerplate-Generierung
• Routine-Dateisuche
• Einfache Test-Updates
• Mechanische Implementierungsschritte

Diese Aufgaben erledigt meist ein günstigeres oder schnelleres Modell besser.

Nutz Fable dort, wo Fehler teuer sind:

• Architekturentscheidungen
• Große Refactors
• Migrationsplanung
• Komplexes Debugging
• Design-Reviews
• Mehrdeutige Übersetzung von Produkt zu Code
• Multi-File-Abhängigkeitsanalyse
• Finaler Produktions-Review
• Teststrategie
• Codebase-Archäologie
• Langlaufende Agent-Aufgaben
• Pull-Request-Review, nachdem ein anderes Modell die Änderung implementiert hat

Ein gutes mentales Modell:

Sonnet oder Opus können der Implementierer sein.
Fable sollte oft der Architekt und Reviewer sein.

Das deckt sich auch mit dem, was einige frühe Praktiker-Guides empfehlen: nutze günstigere Modelle für Triage, repetitive Ausführung und einfache Tool-Calls, und hol dann Fable für tieferes Urteilsvermögen, Migrationsplanung, Architektur-Review und finale Entscheidungen dazu.

2. Teile Coding-Arbeit in drei Phasen

Der zuverlässigste Fable-Workflow, den ich aus den Docs und Community-Mustern gefunden habe, ist dieser:

Phase 1: Erkunden
Phase 2: Planen
Phase 3: Ausführen und verifizieren

Fable muss nicht jede Phase besitzen.

Ein praktisches Setup:

Nutze ein günstigeres Modell oder Opus 4.8, um das Repo zu erkunden, Dateien zu sammeln, die Architektur zusammenzufassen, Test-Befehle zu identifizieren und ein sauberes Briefing vorzubereiten.

Nutze Fable, um über den harten Teil nachzudenken: was sich ändern sollte, was kaputtgehen könnte, in welcher Reihenfolge man es tun sollte und wie man es verifiziert.

Nutze Opus oder Sonnet, um repetitive Änderungen umzusetzen.

Nutze Fable erneut als finalen Reviewer.

Dieses "Fable-Sandwich" ist oft zuverlässiger, als Fable zu bitten, den gesamten Job blind vom ersten Prompt an zu erledigen.

Beispiel-Workflow:

Opus: das Repo kartieren, betroffene Dateien identifizieren, aktuelles Verhalten zusammenfassen.
Fable: den sichersten Migrationsplan entwerfen und versteckte Risiken identifizieren.
Opus oder Sonnet: den Plan umsetzen.
Fable: den Diff, die Tests, Edge-Cases und das Rollout-Risiko reviewen.
Mensch: die finale Ship-Entscheidung freigeben.

Hier geht es nicht darum, Schutzmechanismen zu umgehen. Es ist einfach gutes Model-Routing.

"Sonnet oder Opus können der Implementierer sein. Fable sollte oft der Architekt und Reviewer sein. Die Teams, die gewinnen, sind die, die lernen, Arbeit zwischen Modellen zu übergeben, statt ein Modell durch jeden Prompt zu zwingen."

3. Beginne bei großen Änderungen im Planungsmodus

Bei großen Coding-Aufgaben sollte Fable oft im Read-only-Modus beginnen.

Die Docs von Claude Code empfehlen /plan vor großen Änderungen und weisen darauf hin, dass /model und /effort dir erlauben, anzupassen, wie viel Reasoning du während der Aufgabe aufwendest. Vor dem Ausliefern bietet Claude Code die Workflows /diff, /code-review, /review und /security-review.

Ein starker Fable-Prompt sieht so aus:

/model claude-fable-5
/effort high
/plan

Goal:
Design the safest implementation plan for [feature/refactor/migration].

Constraints:
- Do not edit files yet.
- First map the affected files and dependencies.
- Identify assumptions and unknowns.
- Propose the smallest safe change.
- Separate implementation steps from verification steps.
- Tell me which parts should be delegated to a cheaper model.

Das bewirkt drei Dinge.

Erstens gibt es Fable die Art hochstufiger Reasoning-Aufgabe, bei der es Sinn ergibt.

Zweitens reduziert es versehentliches Über-Editieren.

Drittens erzeugt es einen sauberen Plan, den ein anderes Modell ausführen kann, falls Fable später ins Fallback fällt.

4. Nutze standardmäßig high Effort, nicht immer max

Fable hat einen Effort-Regler, und ihn gut zu nutzen zählt.

Anthropic empfiehlt high als Default für die meisten Fable-Aufgaben, xhigh nur für die capability-sensibelsten Workloads und medium oder low für routinemäßigere Arbeit. Die Docs warnen außerdem, dass High-Effort-Fable bei Routineaufgaben mehr Kontext sammeln und länger deliberieren kann als nötig.

Meine praktische Regel:

Nutze medium für interaktive Coding-Hilfe.
Nutze high für die meisten ernsthaften Engineering-Aufgaben.
Nutze xhigh für Architektur, Migrationen, tiefes Debugging und finale Reviews.
Vermeide xhigh für winzige Änderungen.

Eine gute Anweisung, die man mit höherem Effort kombiniert:

Do the simplest thing that solves the stated problem. Do not add features, abstractions, compatibility layers, or surrounding cleanup unless they are necessary for this task.

Diese Anweisung kommt Anthropics eigener Empfehlung nahe, Fable bei höherem Effort vom Über-Refactoring abzuhalten.

5. Mach dein Repo Fable-lesbar

Fable ist mächtig, aber es ist nicht hellsichtig.

Wenn dein Projektkontext unordentlich ist, verschwendet Fable Tokens damit, Dinge zu entdecken, die ein menschliches Team einmal hätte aufschreiben können.

Claude Code empfiehlt, mit /init eine Start-CLAUDE.md zu erstellen und sie dann mit Build-Befehlen, Test-Befehlen, Code-Stil, Workflow-Regeln und nicht offensichtlichen Projekt-Fallstricken zu verfeinern. Es warnt auch, dass aufgeblähte CLAUDE.md-Dateien dazu führen können, dass Claude die wichtigen Anweisungen ignoriert.

Eine gute CLAUDE.md sollte enthalten:

• Wie man Abhängigkeiten installiert
• Wie man einen einzelnen Test ausführt
• Wie man die volle Test-Suite ausführt
• Wie man den Typecheck macht
• Wie man lintet
• Welchen Paketmanager man nutzt
• Nicht offensichtliche Architekturregeln
• Wichtige Verzeichnisse
• Branch- und PR-Konventionen
• Bekannte Fallen im Repo

Eine schlechte CLAUDE.md enthält:

• Lange Tutorials
• Offensichtliche Sprachkonventionen
• Datei-für-Datei-Erklärungen
• Veraltete Informationen
• Regeln, die einander widersprechen
• Generische Anweisungen wie "write clean code"

Ein praktischer CLAUDE.md-Ausschnitt:

# Project commands
- Install: pnpm install
- Dev server: pnpm dev
- Typecheck: pnpm typecheck
- Unit test one file: pnpm test path/to/file.test.ts
- Full test suite: pnpm test
- Lint: pnpm lint

# Workflow
- Prefer small, reviewable diffs.
- For bug fixes, add or update a regression test first when practical.
- Run typecheck after a series of code changes.
- Do not run the full test suite unless the targeted tests pass first.

# Architecture
- API routes live in src/server/routes.
- Shared domain logic lives in src/domain.
- UI components should not call database code directly.

Das macht Fable zuverlässiger, weil es sein Reasoning-Budget auf das harte Problem verwenden kann, statt deinen Workflow neu zu entdecken.

6. Pack wiederholbare Workflows in Skills

Stopf nicht jeden Workflow in die CLAUDE.md.

Claude Code unterstützt Skills über SKILL.md-Dateien. Die Docs empfehlen, Skills für Domänenwissen und wiederverwendbare Workflows zu nutzen, die bei Bedarf laden sollen, statt jede Konversation aufzublähen.

Zum Beispiel könntest du erstellen:

.claude/skills/fable-migration-review/SKILL.md

---
name: fable-migration-review
description: Review a proposed code migration for hidden risks and verification gaps
---

Review the proposed migration.

1. Identify affected modules.
2. Find hidden dependencies.
3. Identify backwards compatibility risks.
4. Check whether the plan can be split into smaller PRs.
5. Define targeted tests.
6. Define rollback strategy.
7. Produce a ship/no-ship recommendation.

Dann kannst du es aufrufen, wann immer Fable einen Migrations-Review macht.

Das ist eine gute Nutzung von Fable, weil der Wert nicht im Tippen von Code liegt. Der Wert liegt darin, zu erwischen, was ein anderes Modell oder ein Engineer übersehen könnte.

7. Nutze Hooks für Regeln, die immer passieren müssen

Anweisungen sind beratend. Hooks sind deterministisch.

Die Docs von Claude Code sind hier sehr klar: nutze Hooks für Aktionen, die jedes Mal ohne Ausnahme passieren müssen. Ein Hook kann zum Beispiel eslint nach Änderungen laufen lassen oder Writes in sensible Ordner blockieren.

Das zählt für Fable, weil du dich nicht darauf verlassen solltest, dass sich irgendein Modell in einer langen Session an jede operative Regel erinnert.

Gute Hook-Ideen:

• Formatierung nach Datei-Änderungen laufen lassen
• Lint nach Änderungen laufen lassen
• Änderungen an generierten Dateien blockieren
• Änderungen an Migrationen blockieren, sofern nicht explizit erlaubt
• Riesige Test-Logs auf Fehler herunterfiltern
• Versehentliche Writes in die Produktions-Config verhindern
• Warnen, wenn Secrets in einem Diff auftauchen

Die Docs weisen auch darauf hin, dass Hooks den Token-Verbrauch senken können, indem sie verrauschten Output vorverarbeiten. Statt Claude ein 10.000-Zeilen-Log lesen zu lassen, kann ein Hook zum Beispiel nur die passenden Fehlerzeilen zurückgeben.

Genau das ist die Art von Umgebungs-Setup, die Fable effektiver macht: gib ihm das richtige Signal, nicht den ganzen Lärm.

8. Sei bei Security-Arbeit explizit und defensiv

Hier passieren viele Fallbacks.

Anthropic sagt, dass Fables Schutzmechanismen auf offensive Cybersecurity-Techniken zielen, etwa das Bauen von Exploits, Malware oder Angriffs-Tooling. Dieselben Docs sagen auch, dass harmlose Cybersecurity-Arbeit die Schutzmechanismen auslösen kann.

Formuliere legitime Arbeit also nicht so, dass sie nach Exploit-Entwicklung klingt.

Schlechter Prompt:

Find vulnerabilities in this auth system and show me how to exploit them.

Besserer Prompt:

I am reviewing my own authorized codebase. Please perform a defensive code review focused on correctness, authentication boundaries, authorization checks, input validation, secrets handling, and test coverage.

Do not provide exploit chains, offensive tooling, payloads, or attack instructions. For each issue, provide:
1. The affected file and line
2. Why it is risky
3. A safe remediation
4. A safe regression test

Selbst das kann trotzdem an Opus 4.8 geroutet werden. Das ist manchmal zu erwarten. Anthropic nutzt bewusst einen Sicherheitsmargin-Ansatz, der mehrdeutige Cyber-Anfragen blockiert, selbst wenn viele davon wahrscheinlich harmlos sind.

Das Ziel ist nicht, den Klassifizierer auszutricksen. Das Ziel ist, legitimen defensiven Scope klar zu benennen und keinen gefährlichen Output anzufragen.

Für tiefere Security-Reviews innerhalb von Claude Code nutz wo passend den eingebauten /security-review-Befehl. Claude Code dokumentiert ihn als tieferen Read-only-Durchlauf vor dem Ausliefern.

9. Vermeide es, verstecktes Reasoning anzufragen

Ein weiterer vermeidbarer Fallback-Auslöser: Fable zu bitten, internes Reasoning offenzulegen.

Anthropics Fable-Docs sagen, dass das Modell Schutzmechanismen rund um die Extraktion von zusammengefasstem Thinking hat, und der Migration-Guide dokumentiert eine reasoning_extraction-Refusal-Kategorie.

Frag also nicht:

Show your full hidden chain of thought step by step.

Frag:

Give me the conclusion, key evidence, tradeoffs, risks, and recommended next action.

Fürs Coding ist das ohnehin meist besser. Du brauchst kein Transkript des privaten Reasonings des Modells. Du brauchst eine Engineering-Entscheidung, die du prüfen kannst.

10. Nutze Fable für Code-Review, nachdem ein anderes Modell den Code geschrieben hat

Eines der besten Muster ist:

Lass ein günstigeres Modell den Diff schreiben.
Lass Fable ihn reviewen.

Anthropics Fable-Seite enthält Kundenfeedback, dass Fable einen von Opus entworfenen PR reviewt und in einem Durchlauf deutliche Verbesserungen gebracht hat. Dieselbe Seite enthält Feedback, dass Fable stark bei UI-Design, Game-Coding, Intent-Verständnis und dem Erwischen komplexer Design-Lücken ist.

Ein praktischer Prompt:

/model claude-fable-5
/effort xhigh

Review the current diff as a senior engineer.

Focus on:
- Correctness bugs
- Hidden coupling
- Backwards compatibility
- Missing tests
- Edge cases
- Simpler implementation paths
- Risky assumptions
- Files that should not have changed

Do not rewrite the whole PR. Return only:
1. Must-fix issues
2. Should-fix issues
3. Tests to add or run
4. Ship/no-ship recommendation

Das ist eine perfekte Fable-Aufgabe, weil das Modell nicht bloß Code generiert. Es beurteilt, ob die Arbeit sicher ist.

11. Nutze Subagents, aber mach nicht alle davon zu Fable

Fable ist gut in Delegation. Anthropic sagt, es ist verlässlicher darin, parallele Subagents zu dispatchen und aufrechtzuerhalten, und sein Prompting-Guide empfiehlt, Subagents häufig für unabhängige Teilaufgaben zu nutzen.

Aber das heißt nicht, dass jeder Subagent Fable nutzen sollte.

Die Kosten-Docs von Claude Code empfehlen, günstigere Modelle für Teammitglieder zu nutzen, Teams klein zu halten, Spawn-Prompts fokussiert zu halten und Teammitglieder abzuschalten, wenn sie fertig sind.

Ein besseres Muster:

Fable = Orchestrator
Sonnet oder Opus = Implementierungs-Agents
Haiku oder günstigere Modelle = einfache Scan-/Extraktions-Agents
Fable = finale Synthese und Entscheidung

Beispiel-Subagent-Setup:

• Research-Agent: kartiert Dateien und Abhängigkeiten
• Test-Agent: findet und führt relevante Tests aus
• Implementierungs-Agent: macht mechanische Änderungen
• Review-Agent: prüft die Diff-Qualität
• Fable-Orchestrator: entscheidet den Plan und die finale Empfehlung

Claude Code lässt dich mit /agents eigene Subagents erstellen, ihre Tools wählen, ihr Modell wählen und sie wo passend auf Read-only-Tools beschränken.

So bekommst du mehr Fable-Qualitäts-Output, ohne bei jedem repetitiven Schritt Fable-Tokens zu verbrennen.

12. Nutze Worktrees für parallele Experimente

Willst du mehrere Ansätze testen, isoliere sie.

Claude Code unterstützt git worktrees mit claude --worktree und erzeugt separate Arbeitsverzeichnisse und Branches, sodass Änderungen in einer Session keine Dateien in einer anderen berühren.

Das funktioniert gut mit Fable:

Bitte Fable, zwei oder drei tragfähige Implementierungsstrategien vorzuschlagen.
Führe jede Strategie in einem separaten Worktree mit günstigeren Implementierungs-Agents aus.
Bring die Diffs zurück zu Fable zum Vergleich.
Frag Fable, welche am sichersten auszuliefern ist.

Prompt:

Compare these three worktree diffs.

Evaluate:
- Smallest safe change
- Test coverage
- Maintainability
- Regression risk
- Compatibility with current architecture
- Rollback simplicity

Pick one. Explain why. Do not merge anything.

Wieder tut Fable das, worin es am besten ist: Synthese, Urteilsvermögen und Risikoanalyse.

13. Bitte Fable, gegen Tool-Ergebnisse zu verifizieren, nicht gegen Bauchgefühl

Fable ist mächtig, aber du solltest es trotzdem seine Arbeit beweisen lassen.

Anthropic empfiehlt, Fable anzuweisen, Fortschrittsbehauptungen an tatsächlichen Tool-Ergebnissen zu verankern, und sagt, das habe erfundene Status-Reports in ihren Tests nahezu eliminiert.

Nutze Prompts wie:

Before reporting success, audit each claim against actual tool output from this session.

Only say something is complete if:
- The code was changed
- The relevant tests were run
- You can cite the command output
- Any skipped verification is explicitly marked as skipped

Für Implementierungsaufgaben:

After making changes:
1. Show the files changed.
2. Run targeted tests first.
3. Run typecheck.
4. If tests fail, stop and report the failure honestly.
5. Do not claim success unless verification passed.

Das ist besonders nützlich für lange Sessions, in denen das Modell sonst eine übermäßig selbstsichere Zusammenfassung geben könnte.

14. Halte den Kontext klein und bewusst

Fable hat ein großes Kontextfenster, aber großer Kontext ist nicht gratis.

Die Kosten-Docs von Claude Code sagen, dass Token-Kosten mit der Kontextgröße skalieren, und empfehlen, zwischen unzusammenhängenden Aufgaben zu clearen, /compact mit eigenen Compaction-Anweisungen zu nutzen, das richtige Modell zu wählen, ungenutzte MCP-Server zu deaktivieren, Code-Intelligence-Plugins zu installieren und Hooks oder Skills zu nutzen, um unnötige Datei-Reads zu reduzieren.

Praktische Regeln:

• Nutze /clear beim Aufgabenwechsel.
• Nutze /context, um zu sehen, was Platz verbraucht.
• Nutze /compact Focus on test output, decisions, changed files, and unresolved risks.
• Behalte keine unzusammenhängende Debugging-Historie herum.
• Füg keine riesigen Logs ein, wenn eine gefilterte Fehlerzusammenfassung reicht.
• Bevorzuge @file-Referenzen gegenüber vagen Beschreibungen.
• Nutze CLI-Tools wie gh, aws, gcloud oder sentry-cli wo passend, weil Claude Code sagt, dass CLI-Tools oft kontext-effizienter sind als API- oder MCP-Alternativen.

Fable funktioniert am besten, wenn der Kontext reichhaltig ist, nicht aufgebläht.

15. Diagnostiziere Fallback systematisch

Wenn Fable zu Opus 4.8 wechselt, wiederhole nicht einfach denselben Prompt.

Frag, welche Kategorie du wahrscheinlich getroffen hast.

• Ging es bei der Aufgabe um Vulnerabilities, Exploits, Auth, Malware, Payloads oder Angriffspfade?
• Wurden Reproduktionsschritte statt Remediation angefragt?
• Wurde verstecktes Reasoning angefragt?
• Hat deine CLAUDE.md oder ein Hook verdächtige Sprache eingespeist?
• War ein Subagent-Prompt zu breit formuliert?
• War die Aufgabe eigentlich besser für /security-review oder Opus 4.8 geeignet?

Der Claude-API-Migration-Guide sagt, dass Fable-Refusals stop_reason: "refusal" als erfolgreiche HTTP-200-Antwort zurückgeben, mit stop_details.category-Werten wie cyber, bio oder reasoning_extraction. Er beschreibt auch API-Fallback-Handling, um abgelehnte Anfragen auf einem anderen Modell erneut auszuführen.

Speziell für Claude Code erwähnen die CLI-Docs claude --safe-mode als nützlich, um zu prüfen, ob eine Anpassung das automatische Fallback von Fable 5 auslöst.

Das ist ein praktischer Debugging-Trick: Verhält sich Fable im Safe-Mode anders, ist womöglich deine lokale Konfiguration Teil des Problems.

16. Nutze diese Task-Map

Hier ist die einfachste praktische Routing-Map.

Großartige Fable-Aufgaben:

• Architektur-Review
• Migrationsplanung
• Komplexe Bug-Diagnose
• Multi-File-Refactors
• Finaler PR-Review
• Mehrdeutige Produktanforderungen
• Teststrategie
• Repository-weite Abhängigkeitsanalyse
• UI-Review aus Screenshots
• Orchestrierung langlaufender Agents
• Vergleich mehrerer Implementierungsansätze
• "Warum ist dieses System fragil?"-Analyse

Gut, aber achte auf die Kosten:

• Tests schreiben
• Implementierungspläne generieren
• Dokumentation aus Code erzeugen
• Performance-Profiling-Pläne
• API-Design
• Datenmodell-Review
• CI-Fehleranalyse
• Release-Planung
• Onboarding in große Codebases

Meist nicht Fable wert:

• Winzige Fixes
• Boilerplate
• Einfache Datei-Änderungen
• Formatierung
• Rewrites einzelner Funktionen
• Dependency-Bumps
• Einfache Doku-Bereinigung
• Routine-Shell-Befehle
• Einfache Search-and-Replace-Arbeit

Wahrscheinlich Fallback oder sorgfältiges defensives Framing nötig:

• Security-Vulnerability-Review
• Authentication- und Authorization-Review
• Exploit-nahes Debugging
• Malware-artige Verhaltensanalyse
• Anfragen mit Payloads oder Bypasses
• Anfragen nach verstecktem Reasoning
• Biologie- oder Chemie-Workflows

Nutze Fable nicht für:

• Offensive Exploit-Entwicklung
• Malware
• Credential-Diebstahl
• Bypass-Anleitungen
• Angriffs-Tooling
• Jailbreak-Versuche
• Alles, wo das Ziel ist, Schutzmechanismen zu umgehen

17. Eine praktische Fable-Coding-Prompt-Bibliothek

Nutze diese als Ausgangspunkte.

Der Architektur-Prompt

Use Fable as a senior staff engineer.

Goal:
Evaluate the architecture for [change].

Please:
1. Map the relevant modules.
2. Identify hidden coupling.
3. Identify the smallest safe implementation path.
4. List risks and tradeoffs.
5. Define verification steps.
6. Recommend whether this should be one PR or multiple PRs.

Do not edit files yet.

Der Implementierungs-Handoff-Prompt

Turn this plan into an implementation brief for a cheaper coding model.

Include:
- Files to edit
- Exact behavioral changes
- Tests to add
- Commands to run
- Things not to change
- Acceptance criteria

Der Final-Review-Prompt

Review the current diff as a senior engineer.

Return:
1. Must-fix issues
2. Should-fix issues
3. Missing tests
4. Regression risks
5. Ship/no-ship recommendation

Ground every claim in the actual diff or test output.

Der defensive Security-Prompt

I am reviewing my own authorized codebase.

Perform a defensive review focused on:
- Authentication boundaries
- Authorization checks
- Input validation
- Secrets handling
- Unsafe data exposure
- Test coverage

Do not provide exploit chains, payloads, offensive tooling, or attack instructions.

For each finding, provide:
- File and line
- Risk
- Safe remediation
- Safe regression test

Der Fallback-Diagnose-Prompt

Analyze why this request may have triggered fallback.

Do not try to bypass safeguards. Instead:
1. Identify ambiguous or risky wording.
2. Rewrite the task with a clearly defensive, authorized scope.
3. Remove requests for exploit reproduction or hidden reasoning.
4. Suggest whether this belongs in Fable, Opus, /security-review, or a human review.