claude-regelwerk/AI/Regelwerk/prompting.md

---
type: resource
status: reference
title: Prompting-Grundlagen für aktuelle Claude-Modelle
summary: Die allgemeinen Prompt-Techniken aus der Anthropic-Doku „Prompting best practices" — Klarheit, Beispiele, XML-Struktur, Werkzeugnutzung, Thinking, lange Aufgaben, Subagenten. Verbindlich für Fable 5.1; andere Modelle entscheiden selbst.
tags: [regelwerk, modelle, prompting, subagenten]
created: 2026-09-05
updated: 2026-09-29
source: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices
---

# Prompting-Grundlagen für aktuelle Claude-Modelle

> **Geltungsbereich.** Anthropic führt diese Seite als Referenz für **alle** aktuellen Modelle (Fable 5.1, Mythos 5.1, Fable 5, Opus 5, Opus 4.8 bis 4.6, Sonnet 5, Sonnet 4.6, Haiku 4.5). Im Vault gilt trotzdem dieselbe Regel wie für [[AI/Regelwerk/fable-5-1|fable-5-1.md]]: **Verbindlich nur für Claude Fable 5.1.** Opus 5, Sonnet 5 und Haiku 4.5 arbeiten nach ihren eigenen Optimierungen und entscheiden selbst, ob sie einen Punkt übernehmen. Wo die Doku eine Technik an einem bestimmten Modell gemessen hat, steht das Modell dabei — Anthropic selbst sagt, man solle sie vor der Übertragung auf ein anderes Modell an eigenen Evals nachprüfen.
> Angeordnet am 2026-09-05. Quelle abgerufen am 2026-09-05. Aussagen stammen aus der Doku, nicht aus eigener Messung.

## Wozu diese Datei

Die meisten Punkte hier betreffen nicht das Sprechen mit dem Nutzer, sondern das **Schreiben von Aufträgen**: an Subagenten, in Agent- und Skill-Dateien, in Plänen, und in System-Prompts eigener Integrationen in Code-Projekten. Wer einen Executer-Auftrag oder einen Prüfauftrag formuliert, schreibt einen Prompt. Dafür gelten die Regeln unten. Die eigene Modell-Seite (für Fable 5.1: [[AI/Regelwerk/fable-5-1|fable-5-1.md]]) liest man laut Doku zuerst, dann diese Techniken.

Die Modellseiten dazu: [[AI/Regelwerk/fable-5-1|fable-5-1.md]], [[AI/Regelwerk/opus-5|opus-5.md]], [[AI/Regelwerk/sonnet-5-5|sonnet-5-5.md]], [[AI/Regelwerk/sonnet-5|sonnet-5.md]]. Nicht eingearbeitet sind „Prompting Claude Fable 5" und „Prompting Claude Opus 4.8" — beide Modelle laufen im Vault nicht.

## 1 Allgemeine Prinzipien

**Klar und direkt.** Claude reagiert auf ausdrückliche Anweisungen. Wer „mehr als das Nötige" will, sagt das — das Modell schließt es nicht aus vagen Formulierungen. Das Bild der Doku: ein brillanter neuer Mitarbeiter ohne Kenntnis der Hausregeln. Die goldene Regel: Zeig den Prompt einem Kollegen mit wenig Kontext. Wäre er verwirrt, ist es das Modell auch. Ausgabeformat und Grenzen konkret benennen; Schritte als nummerierte Liste, wenn Reihenfolge oder Vollständigkeit zählen.

**Kontext und Grund mitgeben.** Statt „NEVER use ellipses": „Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them." Das Modell verallgemeinert aus der Begründung. Das ist genau die Form, in der das Regelwerk hier geschrieben ist — Regel plus Beleg, warum.

**Beispiele.** Der verlässlichste Hebel für Format, Ton und Struktur. Relevant (nah am echten Fall), vielfältig (Randfälle, damit kein unbeabsichtigtes Muster entsteht), strukturiert (in `<example>`-Tags, mehrere in `<examples>`). Die Doku empfiehlt drei bis fünf. Das ist die Doku-Fassung von Punkt 2 der [[AI/Regelwerk/dokumentations-grossprojekte|Dokumentations-Großprojekte]]: Ton per Beispiel, nicht per Beschreibung.

**XML-Tags zur Strukturierung.** Wenn ein Prompt Anweisungen, Kontext, Beispiele und Eingaben mischt, jede Sorte in ein eigenes Tag (`<instructions>`, `<context>`, `<input>`). Tag-Namen konsistent halten; verschachteln, wo es eine Hierarchie gibt (`<documents>` mit `<document index="n">`).

**Rolle setzen.** Ein Satz im System-Prompt reicht, um Verhalten und Ton zu fokussieren („You are a helpful coding assistant specializing in Python."). Unsere Agent-Dateien tun das in der ersten Zeile.

**Langer Kontext (ab etwa 20.000 Tokens).** Lange Dokumente und Daten **oben** platzieren, Anfrage und Anweisungen **unten** — laut Doku bis zu 30 Prozent bessere Antworten bei komplexen Mehrdokument-Eingaben. Jedes Dokument in `<document>` mit `<source>` und `<document_content>`. Bei Dokumentaufgaben zuerst relevante Zitate in `<quotes>`-Tags ziehen lassen, dann die eigentliche Aufgabe — das fokussiert auf den relevanten Teil.

**Modell-Selbstauskunft.** Soll sich das Modell korrekt identifizieren oder Modellstrings nennen, steht das im Prompt: „The assistant is Claude, created by Anthropic. The current model is Claude Opus 5." bzw. „The exact model string for Claude Opus 5 is claude-opus-5."

## 2 Ausgabe und Formatierung

**Kommunikationsstil.** Aktuelle Modelle sind direkter, sachlicher, weniger ausführlich als frühere — sie überspringen nach Werkzeugaufrufen gern die Zusammenfassung. Wer sie will: „After completing a task that involves tool use, provide a quick summary of the work you've done." Zwei Ausnahmen laut Doku: **Opus 5** antwortet von sich aus länger, und Effort ändert die sichtbare Länge nicht verlässlich — Kürze ausdrücklich anfordern. **Fable 5.1** hat die Gegentendenz in Agentenarbeit (weniger Zwischentext) — siehe fable-5-1.md, Abschnitt 2.

**Format steuern.** Vier Hebel: (1) Sagen, was zu tun ist, statt was nicht — „Your response should be composed of smoothly flowing prose paragraphs" statt „Do not use markdown". (2) XML-Formatanzeiger: „Write the prose sections in <smoothly_flowing_prose_paragraphs> tags." (3) Prompt-Stil an den gewünschten Ausgabestil angleichen — Markdown im Prompt erzeugt Markdown in der Antwort. (4) Ausführliche Formatvorgaben, etwa der Doku-Block `<avoid_excessive_markdown_and_bullet_points>` für Fließtext statt Aufzählungen. **Vorbehalt der Doku:** Bei Fable 5.1 unterdrückt so ein Block Struktur, die der Inhalt braucht — dort weglassen oder durch die kurze Regel aus fable-5-1.md Abschnitt 6 ersetzen.

**LaTeX.** Aktuelle Modelle setzen Mathematik standardmäßig in LaTeX. Wer Klartext will: „Format your response in plain text only. Do not use LaTeX, MathJax, or any markup notation such as \( \), $, or \frac{}{}."

**Dokumenterstellung.** Präsentationen, Animationen und visuelle Dokumente gelingen laut Doku meist im ersten Anlauf; Gestaltungselemente und Animationen ausdrücklich anfordern.

**Prefill ist weg.** Seit den 4.6-Modellen liefert ein vorausgefüllter letzter Assistant-Turn einen 400. Ersatz je Zweck: Strukturvorgabe → Structured Outputs oder Tools mit Enum; Präambel vermeiden → „Respond directly without preamble"; Fortsetzung → in der Nutzernachricht „Your previous response was interrupted and ended with `[previous_response]`. Continue from where you left off."; Kontextauffrischung → in den User-Turn oder in die Kompaktierung verlegen.

## 3 Werkzeugnutzung

**Handeln muss man anfordern.** Aktuelle Modelle befolgen Anweisungen wörtlich. „Can you suggest some changes?" ergibt Vorschläge, „Change this function to improve its performance" ergibt Änderungen. Das ist der Grund, warum Executer-Aufträge im Imperativ stehen und Prüfaufträge ausdrücklich „ändere nichts" sagen.

Zwei Voreinstellungen, je nach Produkt:

```text
<default_to_action>
By default, implement changes rather than only suggesting them. If the user's intent is unclear, infer the most useful likely action and proceed, using tools to discover any missing details instead of guessing. Try to infer the user's intent about whether a tool call (e.g., file edit or read) is intended or not, and act accordingly.
</default_to_action>
```

```text
<do_not_act_before_instructions>
Do not jump into implementation or change files unless clearly instructed to make changes. When the user's intent is ambiguous, default to providing information, doing research, and providing recommendations rather than taking action. Only proceed with edits, modifications, or implementations when the user explicitly requests them.
</do_not_act_before_instructions>
```

Der zweite Block ist inhaltlich das, was der `pruefer` tut. Der Stamm-Grundsatz „wer ein Problem beschreibt, bekommt eine Einschätzung, keine Änderung" ist die Kurzfassung.

**Dosierung.** Opus 4.5 und 4.6 reagieren stärker auf den System-Prompt als Vorgänger; wer gegen Unterauslösung „CRITICAL: You MUST use this tool when…" geschrieben hat, bekommt jetzt Überauslösung. Normal formulieren: „Use this tool when…".

**Parallele Werkzeugaufrufe.** Aktuelle Modelle rufen unabhängige Werkzeuge parallel auf — mehrere Suchen, mehrere Dateien, mehrere Bash-Befehle (das kann sogar das System ausbremsen). Steuerbar in beide Richtungen. Der Doku-Block für maximale Parallelität:

```text
<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the tool calls, make all of the independent tool calls in parallel. Prioritize calling tools simultaneously whenever the actions can be done in parallel rather than sequentially. For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into context at the same time. Maximize use of parallel tool calls where possible to increase speed and efficiency. However, if some tool calls depend on previous calls to inform dependent values like the parameters, do NOT call these tools in parallel and instead call them sequentially. Never use placeholders or guess missing parameters in tool calls.
</use_parallel_tool_calls>
```

Zum Drosseln: „Execute operations sequentially with brief pauses between each step to ensure stability." Bei Fable 5.1 in langen Agentenschleifen die Parallel-Anweisung als rundenbezogene System-Nachricht nach jeder Ergebnisrunde senden — fable-5-1.md Abschnitt 3.

## 4 Thinking

**Adaptives Thinking ist der Standard.** Ab den 4.6-Modellen `thinking: {type: "adaptive"}`; bei Fable 5.1, Mythos 5.1, Fable 5 und Mythos 5 ist Thinking immer an und adaptiv der einzige Modus. Tiefe steuert `effort` plus die Komplexität der Anfrage. `budget_tokens` ist ab 4.7 ein 400-Fehler; auf 4.6 noch funktional, aber abgekündigt. Bei Opus 5 und Sonnet 5 ist Thinking an, wenn der Parameter fehlt; bei Opus 5 lässt es sich nur bis Effort `high` abschalten. Laut interner Evaluation schlägt adaptives Thinking das manuelle Extended Thinking.

**Überdenken eindämmen (gemessen an Opus 4.6).** Das Modell erkundet mehr vorab, besonders bei hohem Effort. Pauschale Vorgaben („Default to using [tool]") durch gezielte ersetzen („Use [tool] when it would enhance your understanding"), Über-Prompting gegen Unterauslösung entfernen („If in doubt, use [tool]" führt jetzt zu Überauslösung), Effort als Rückfallebene senken. Gegen langes Hin- und Her-Erwägen:

```text
When you're deciding how to approach a problem, choose an approach and commit to it. Avoid revisiting decisions unless you encounter new information that directly contradicts your reasoning. If you're weighing two approaches, pick one and see it through. You can always course-correct later if the chosen approach fails.
```

**Thinking lenken.** Nach Werkzeugergebnissen reflektieren lassen: „After receiving tool results, carefully reflect on their quality and determine optimal next steps before proceeding." Denkt das Modell zu oft (passiert bei großen System-Prompts): „Thinking adds latency and should only be used when it will meaningfully improve answer quality - typically for problems that require multistep reasoning. When in doubt, respond directly."

Vier Faustregeln der Doku: Allgemeine Anweisungen („think thoroughly") schlagen handgeschriebene Schrittpläne — das Modell denkt oft besser, als ein Mensch vorschreibt. Beispiele mit `<thinking>`-Tags übertragen das Denkmuster. Manuelles Chain-of-Thought mit `<thinking>`/`<answer>` nur, wenn Thinking aus ist — bei Opus 5 lieber Thinking bei niedrigem Effort anlassen, weil es sonst interne XML-Tags in die Ausgabe schreiben kann. Selbstprüfung anfordern („Before you finish, verify your answer against [test criteria]") fängt Fehler verlässlich, besonders bei Code und Mathematik — **Ausnahme Opus 5:** es prüft von sich aus gut, und übernommene Prüfanweisungen führen zu Über-Verifikation; beim Umstieg entfernen statt umschreiben.

Randnotiz: Opus 4.5 ohne Thinking reagiert empfindlich auf das Wort „think" — dort „consider", „evaluate", „reason through".

## 5 Agentische Systeme

**Lange Aufgaben und Zustand.** Aktuelle Modelle halten über lange Sitzungen die Orientierung, indem sie schrittweise vorgehen — wenige Dinge zugleich, stetig. Das trägt über mehrere Kontextfenster: arbeiten, Zustand sichern, in frischem Kontext weitermachen.

**Kontextbewusstsein** haben Sonnet 5, Sonnet 4.6, Sonnet 4.5 und Haiku 4.5 — sie kennen ihr verbleibendes Tokenbudget. Läuft ein Harness mit Kompaktierung oder Dateispeicher (wie Claude Code), sagt man das dem Modell, sonst wickelt es bei nahendem Limit von sich aus ab:

```text
Your context window will be automatically compacted as it approaches its limit, allowing you to continue working indefinitely from where you left off. Therefore, do not stop tasks early due to token budget concerns. As you approach your token budget limit, save your current progress and state to memory before the context window refreshes. Always be as persistent and autonomous as possible and complete tasks fully, even if the end of your budget is approaching. Never artificially stop any task early regardless of the context remaining.
```

**Arbeit über mehrere Kontextfenster** — sechs Punkte der Doku, die sich mit unserer Standardschleife decken:

1. Das erste Fenster bekommt einen anderen Prompt: Rahmen aufbauen (Tests, Setup-Skripte), spätere Fenster arbeiten eine Todo-Liste ab.
2. Tests vorab in strukturierter Form (`tests.json`) anlegen lassen, mit dem Satz: „It is unacceptable to remove or edit tests because this could lead to missing or buggy functionality."
3. Komfortwerkzeuge (`init.sh` für Server, Tests, Linter), damit ein frisches Fenster nicht alles neu entdeckt.
4. **Frisch starten statt kompaktieren** ist oft besser — aktuelle Modelle lesen ihren Zustand sehr gut vom Dateisystem. Dann präzise vorgeben: „Call pwd; you can only read and write files in this directory." / „Review progress.txt, tests.json, and the git logs." / „Manually run through a fundamental integration test before moving on to implementing new features." Das ist der Doku-Beleg für „frischer Subagent statt Fortsetzung" aus [[AI/Regelwerk/codeworkflow|codeworkflow.md]].
5. Verifikationswerkzeuge bereitstellen (Computer Use, Browser, Browser-MCP), weil das Modell ohne Menschen prüfen muss.
6. Vollen Kontext nutzen lassen: „This is a very long task, so it may be beneficial to plan out your work clearly. It's encouraged to spend your entire output context working on the task - just make sure you don't run out of context with significant uncommitted work. Continue working systematically until you have completed this task."

**Zustand halten.** Strukturierte Daten als JSON, Fortschrittsnotizen als Freitext, **Git als Zustandsprotokoll** (aktuelle Modelle nutzen es über Sitzungen hinweg besonders gut), und ausdrücklich zu inkrementeller Arbeit auffordern. Unsere `todo.md`, `tasks/lessons.md` und die Secondbrain-Dumps sind genau diese Aufteilung.

**Autonomie und Sicherheit (gemessen an Opus 4.6).** Ohne Vorgabe kann das Modell schwer umkehrbare Aktionen ausführen. Der Doku-Block:

```text
Consider the reversibility and potential impact of your actions. You are encouraged to take local, reversible actions like editing files or running tests, but for actions that are hard to reverse, affect shared systems, or could be destructive, ask the user before proceeding.

Examples of actions that warrant confirmation:
- Destructive operations: deleting files or branches, dropping database tables, rm -rf
- Hard to reverse operations: git push --force, git reset --hard, amending published commits
- Operations visible to others: pushing code, commenting on PRs/issues, sending messages, modifying shared infrastructure

When encountering obstacles, do not use destructive actions as a shortcut. For example, don't bypass safety checks (e.g. --no-verify) or discard unfamiliar files that may be in-progress work.
```

**Recherche.** Erfolgskriterien vorgeben, Quellenabgleich über mehrere Quellen verlangen, bei komplexen Aufgaben strukturiert: „Search for this information in a structured way. As you gather data, develop several competing hypotheses. Track your confidence levels in your progress notes to improve calibration. Regularly self-critique your approach and plan. Update a hypothesis tree or research notes file to persist information and provide transparency. Break down this complex research task systematically." Das passt zur Quellenpflicht im Codeworkflow und in [[AI/Regelwerk/finanzanalyse|finanzanalyse.md]].

**Subagenten.** Aktuelle Modelle delegieren von selbst, wenn Subagenten-Werkzeuge definiert sind. **Vorbehalt:** Opus 4.6 hat eine starke Neigung zu Subagenten und startet sie auch dort, wo ein `grep` reicht; Opus 5 delegiert ebenfalls bereitwilliger als Vorgänger (Details auf der nicht eingearbeiteten Opus-5-Seite). Bei Überbeanspruchung:

```text
Use subagents when tasks can run in parallel, require isolated context, or involve independent workstreams that don't need to share state. For simple tasks, sequential operations, single-file edits, or tasks where you need to maintain context across steps, work directly rather than delegating.
```

Für den Vault heißt das: Die Tabelle „Wann die Schleife entfällt" im Codeworkflow (Einzeiler selbst machen) ist die Antwort auf genau diese Neigung des Koordinatormodells.

**Prompt-Ketten.** Mit adaptivem Thinking und Subagenten braucht es selten explizite Ketten. Sinnvoll bleiben sie, wenn Zwischenergebnisse inspiziert oder eine feste Pipeline erzwungen werden soll — das häufigste Muster ist Entwurf → Prüfung gegen Kriterien → Überarbeitung, je Schritt ein eigener Aufruf. Das ist die Standardschleife in API-Form.

**Dateierzeugung.** Aktuelle Modelle legen gern temporäre Skripte als Zwischenspeicher an; das hilft oft. Wer aufräumen will: „If you create any temporary new files, scripts, or helper files for iteration, clean up these files by removing them at the end of the task."

**Überengineering (gemessen an Opus 4.5 und 4.6).** Zusätzliche Dateien, unnötige Abstraktionen, ungefragte Flexibilität. Der Doku-Block:

```text
Avoid over-engineering. Only make changes that are directly requested or clearly necessary. Keep solutions simple and focused:

- Scope: Don't add features, refactor code, or make "improvements" beyond what was asked. A bug fix doesn't need surrounding code cleaned up. A simple feature doesn't need extra configurability.

- Documentation: Don't add docstrings, comments, or type annotations to code you didn't change. Only add comments where the logic isn't self-evident.

- Defensive coding: Don't add error handling, fallbacks, or validation for scenarios that can't happen. Trust internal code and framework guarantees. Only validate at system boundaries (user input, external APIs).

- Abstractions: Don't create helpers, utilities, or abstractions for one-time operations. Don't design for hypothetical future requirements. The right amount of complexity is the minimum needed for the current task.
```

Das ist die ausführliche Fassung der Executer-Regel „kleinstmögliche Änderung".

**Tests bestehen ist nicht die Lösung.** Gegen Hartkodieren und Helferskripte:

```text
Please write a high-quality, general-purpose solution using the standard tools available. Do not create helper scripts or workarounds to accomplish the task more efficiently. Implement a solution that works correctly for all valid inputs, not just the test cases. Do not hard-code values or create solutions that only work for specific test inputs. Instead, implement the actual logic that solves the problem generally.

Focus on understanding the problem requirements and implementing the correct algorithm. Tests are there to verify correctness, not to define the solution. Provide a principled implementation that follows best practices and software design principles.

If the task is unreasonable or infeasible, or if any of the tests are incorrect, please inform me rather than working around them. The solution should be robust, maintainable, and extendable.
```

Deckt sich mit „Ursachen beheben, nicht kaschieren" in `.claude/agents/executer.md` und mit dem Grundsatz aus dem Codeworkflow, dass grüne Tests nur beweisen, dass der Code die Erwartung der Tests erfüllt.

**Halluzinationen beim Code.** Vor dem Antworten lesen:

```text
<investigate_before_answering>
Never speculate about code you have not opened. If the user references a specific file, you MUST read the file before answering. Make sure to investigate and read relevant files BEFORE answering questions about the codebase. Never make any claims about code before investigating unless you are certain of the correct answer - give grounded and hallucination-free answers.
</investigate_before_answering>
```

Im Vault heißt dasselbe „ein Dateiname ist kein Beleg" und „Quellenpflicht".

## 6 Fähigkeitsspezifisch

**Bildverarbeitung.** Opus 4.5 und 4.6 lesen Bilder und Screenshots besser, auch mehrere im Kontext; Videos lassen sich als Einzelbilder analysieren. Ein Zuschneide-Werkzeug oder ein Skill zum „Zoomen" bringt laut Tests konstante Verbesserung (Cookbook-Rezept „multimodal-crop-tool"). Für Fable 5.1 steht das ausführlicher in fable-5-1.md Abschnitt 16.

**Frontend-Gestaltung.** Ohne Vorgabe entsteht laut Doku der generische „AI slop"-Look. Der Doku-Block `<frontend_aesthetics>` verlangt eigene Schriften (nicht Inter, Roboto, Arial, System-Fonts, auch nicht ständig Space Grotesk), ein festgelegtes Farbschema mit CSS-Variablen (keine lila Verläufe auf Weiß), gezielte Bewegung (ein orchestrierter Seitenaufbau statt verstreuter Mikro-Interaktionen) und Hintergründe mit Tiefe statt Volltonfarbe. Die vollständige Skill-Definition liegt im Claude-Code-Repo unter `plugins/frontend-design/skills/frontend-design/SKILL.md`. Hier nicht wörtlich übernommen, weil im Vault kein Frontend-Projekt läuft; bei Bedarf dort nachlesen.

## 7 Umstieg von früheren Generationen

Sieben Punkte der Doku: (1) Gewünschtes Verhalten genau beschreiben. (2) Qualitätsmodifikatoren anfügen („Include as many relevant features and interactions as possible. Go beyond the basics"). (3) Animationen und Interaktion ausdrücklich anfordern. (4) Thinking auf adaptiv umstellen, Tiefe über `effort`. (5) Prefill ersetzen. (6) **Anti-Faulheits-Prompting zurückdrehen** — 4.6-Modelle sind proaktiver und lösen auf alte Antreib-Anweisungen über. (7) Thinking-Blöcke unverändert zurückgeben, Verlauf nur anhängen — bei Fable 5.1 sonst Fehler (fable-5-1.md Abschnitt 4 und Teil B).

Für den Umstieg auf Sonnet 5 von Sonnet 4.5 oder älter verweist die Doku auf den eigenen Migrationsleitfaden (Effort-Standard geändert, `budget_tokens` entfernt) — eingearbeitet in [[AI/Regelwerk/sonnet-5|sonnet-5.md]], Teil C.

## Wohin die Punkte im Regelwerk zeigen

| Regelwerk-Datei | Verweist auf Abschnitt |
|---|---|
| [[CLAUDE|Claude.md]] (Stamm, Regelwerk-Liste) | Gesamtdatei |
| [[AI/Regelwerk/codeworkflow|codeworkflow.md]] (Rollen und Subagenten) | 3, 5 |
| [[AI/Regelwerk/fable-5-1|fable-5-1.md]] | gegenseitig |

## Referenzen

- [[CLAUDE|↑ Claude.md (Stamm)]]
- [[AI/Regelwerk/fable-5-1|fable-5-1.md]] — die modellspezifische Seite, die man laut Doku zuerst liest
- [[AI/Regelwerk/codeworkflow|codeworkflow.md]] — Standardschleife und Subagenten
- [[AI/Regelwerk/api-mechanik|api-mechanik.md]] — die API-Seite: Preserved Thinking, Effort, Compaction, Task Budgets, Fast Mode
- Anthropic-Doku: https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/claude-prompting-best-practices (Stand 2026-09-05)