{"content_id":"z9qcc6lzi3","slug":"claude-code-loop-engineering-guide","locale":"de","schema_type":"TechArticle","category":"tutorial","category_name":"Tutorial","title":"Leitfaden für Claude Code Loop Engineering: 4 Loops und sichere Automatisierung","summary":"Ein Loop in Claude Code ist eine Kontrollstruktur, die einen Agent Beobachtung, Aktion und Validierung bis zum Erreichen einer Abbruchbedingung wiederholen lässt. Erläutert werden die Unterschiede zwischen den vier Loop-Typen sowie praxisnahe Entwurfsmethoden, die Validierungsnachweise, Zwangsabbruch, Idempotenz, Kosten und minimale Berechtigungen berücksichtigen.","sponsorship_disclosure":null,"author":{"name":"naikeu","url":"https://injoys.com/ko/about"},"key_points":["Ein Loop in Claude Code ist keine Programmierschleife, sondern eine Ausführungsstruktur für Agents, die Beobachtung, Aktion und Validierung bis zu einer Abbruchbedingung wiederholt.","Turn-based übergibt dem System das Validierungsverfahren, Goal-based die Entscheidung über den Abschluss, Time-based den Zeitpunkt der erneuten Ausführung und Proactive den Arbeitsbeginn sowie die Orchestrierung.","Ein guter Loop benötigt messbare Abschlussbedingungen, externe Validierungsnachweise, einen Zwangsabbruch, Idempotenz und minimale Berechtigungen.","Da das Bewertungsmodell von `/goal` nur die im Gespräch ersichtlichen Nachweise beurteilt, müssen Testausgaben, Exit-Codes und der Änderungsumfang eindeutig angegeben werden.","Deterministische Transformationen sollten mit einem Script verarbeitet werden; Dynamic Workflow und mehrere Agents sollten nur bei umfangreichen Aufgaben eingesetzt werden, die echte Parallelität erfordern."],"content_markdown":"Der Loop von Claude Code ist nicht einfach eine Funktion, mit der ein Modell länger ausgeführt wird. Im Kern geht es darum, rund um einen probabilistisch handelnden AI Agent **Trigger, Verifier, Success condition, Hard stop und Permission boundary** zu platzieren und so wiederkehrende Aufgaben in ein kontrollierbares System zu verwandeln. Dieser Artikel fasst die Unterschiede zwischen Turn-based, Goal-based, Time-based und Proactive Loop sowie praktische Gestaltungsprinzipien zusammen.\n\n## 1. Was ist ein Loop in Claude Code?\n\nEin Loop ist hier keine `for`- oder `while`-Anweisung einer Programmiersprache. Der vom Claude Code-Team beschriebene Loop ist eine Ausführungsstruktur, in der ein Agent den aktuellen Zustand beobachtet, handelt, das Ergebnis überprüft und die Arbeit wiederholt, bis die Abbruchbedingung erfüllt ist.\n\n```text\nAufgabe starten\n  ↓\nZustand und Code erfassen\n  ↓\nPlan erstellen\n  ↓\nCode ändern oder Tool ausführen\n  ↓\nTesten und überprüfen\n  ↓\nAbschlussbedingung erfüllt?\n  ├─ Nein: nächste Wiederholung\n  └─ Ja: beenden und Ergebnis melden\n```\n\nZur Unterscheidung von Loops sind die folgenden vier Fragen hilfreich.\n\n1. Was löst die Aufgabe aus?\n2. Was beendet die Aufgabe?\n3. Welche Funktion von Claude Code steuert die Wiederholung?\n4. Für welche Art von Aufgabe eignet sie sich?\n\nNicht jede Aufgabe muss in einen komplexen Loop umgewandelt werden. Bei Aufgaben, deren Ergebnis sofort überprüfbar ist, etwa der Korrektur eines Tippfehlers in einer Datei oder einer einfachen Umbenennung, ist ein normaler Prompt effizienter. Ein Loop sollte nur gewählt werden, wenn tatsächlich mehrere Beobachtungs-, Änderungs- und Überprüfungsdurchläufe erforderlich sind.\n\n## 2. Vergleich der vier Loop-Typen\n\n| Typ | Startbedingung | Abbruchbedingung | Hauptsächlich verwendete Funktionen | Geeignete Aufgaben | Vom Menschen übertragene Verantwortung |\n|---|---|---|---|---|---|\n| Turn-based | Prompt des Benutzers | Wenn Claude die Aufgabe für abgeschlossen hält oder zusätzliche Informationen benötigt | Normale Konversation, Skills, Test- und Browser-Tools | Kurze, einmalige Implementierungen und Änderungen | Wiederholter Überprüfungsprozess |\n| Goal-based | Benutzer legt Abschlussbedingungen fest | Evaluierungsmodell bestätigt die Erfüllung oder Benutzer bricht ab | `/goal`, bei Bedarf Auto mode | Aufgaben mit messbarem Abschlusszustand wie Tests, Builds und Migrationen | Entscheidung über den Abschluss |\n| Time-based | Festgelegte Zeit, Intervall oder Zeitplan | Benutzer bricht ab oder externe Aufgabe endet | `/loop`, `/schedule` | Überwachung von PR, CI und Deployments, regelmäßige Zusammenfassungen, Status-Polling | Zeitpunkt der nächsten Ausführung |\n| Proactive | Zeitplan, API, GitHub-Event usw. | Ziel der einzelnen Aufgabe erfüllt, Routine deaktiviert | Routines, `/goal`, Skills, Dynamic Workflows, Auto mode | Laufende Aufgaben wie Issue-Klassifizierung, Fehlerbehandlung und umfangreiche Migrationen | Erkennung von Aufgaben, Prompt-Ausführung, Orchestrierung |\n\nDer Kern dieser Einteilung ist nicht, „wie intelligent die AI ist“, sondern **welche Kontrollverantwortung der Mensch an das System überträgt**. Bei Turn-based erstellt der Mensch den nächsten Prompt, bei Goal-based überträgt er die Entscheidung über den Abschluss und bei Time-based den Zeitpunkt der erneuten Ausführung. In der Proactive-Stufe geht auch die Verantwortung dafür, das Auftreten einer Aufgabe zu erkennen und den passenden Prompt auszuführen, auf das System über.\n\n## 3. Turn-based Loop: Den Überprüfungsprozess übertragen\n\nDer Turn-based Loop ist die grundlegende Form, in der die meisten Entwickler Claude Code verwenden.\n\n```text\nMensch → Claude → Mensch → Claude\n```\n\nWenn der Benutzer eine Anfrage stellt, sucht Claude die relevanten Dateien, ändert den Code, führt Tests aus und meldet das Ergebnis. Intern können mehrere Beobachtungs-, Handlungs- und Überprüfungsschritte stattfinden, doch die Befugnis, die nächste Aufgabe zu starten, bleibt beim Benutzer.\n\n### Codeänderung und Funktionsabschluss sind nicht dasselbe\n\nAuch wenn Claude meldet, „Implementierung und Tests abgeschlossen“ zu haben, können im tatsächlichen Produkt noch folgende Probleme bestehen.\n\n- Nach einem Klick auf eine Schaltfläche ändert sich der Zustand nicht.\n- In der Browserkonsole tritt ein Fehler auf.\n- Das mobile Layout ist beschädigt.\n- Attribute für die Barrierefreiheit fehlen.\n- Die Tests bestehen, aber der tatsächliche Ablauf im Browser schlägt fehl.\n- Es wurden auch Dateien geändert, die nichts mit der Änderung zu tun haben.\n\nDas Abschlusskriterium sollte daher nicht lauten „Der Code wurde geändert“, sondern „Die Funktion wurde anhand externer Nachweise bestätigt“.\n\n### Überprüfungen mit `SKILL.md` wiederverwenden\n\nEin Skill ist eine Methode, wiederholt verwendete Anweisungen und Abläufe in `SKILL.md` zu speichern. Claude kann einen Skill automatisch laden, wenn es ihn für relevant hält, oder er kann direkt mit `/skill-name` ausgeführt werden. Statt lange Betriebsabläufe immer in `CLAUDE.md` aufzunehmen, lässt sich der Context effizienter nutzen, wenn sie getrennt und nur bei Bedarf als Skill geladen werden.\n\n```markdown\n---\nname: verify-ui-change\ndescription: Überprüft UI-Änderungen in der tatsächlichen Ausführungsumgebung, bevor sie als abgeschlossen gelten.\n---\n\n# Überprüfung von UI-Änderungen\n\n1. Den Entwicklungsserver starten.\n2. Die geänderte Ansicht im Browser öffnen.\n3. Das neue Steuerelement tatsächlich bedienen.\n4. Prüfen, ob die erwartete Zustandsänderung eintritt.\n5. Browserkonsole auf neue Fehler und Warnungen prüfen.\n6. Barrierefreiheit und wichtige Leistungskennzahlen prüfen.\n7. Bei einem Fehlschlag korrigieren und die Überprüfung von vorn beginnen.\n8. Nachweise wie ausgeführte Befehle, Ergebnisse und Screenshots melden.\n```\n\nEin guter Skill enthält keine abstrakten Ermahnungen, sondern eine ausführbare Checkliste. „Sorgfältiger prüfen“ ist eine wesentlich schwächere Regel als „Prüfen, ob `npm test` mit Exit-Code 0 endet“.\n\n### Aussagekraft von Überprüfungsnachweisen\n\n| Nachweis | Vertrauenswürdigkeit | Grund |\n|---|---:|---|\n| Erklärung des Agent „Es scheint ordnungsgemäß zu funktionieren“ | Niedrig | Nur eine Schlussfolgerung, kein Ausführungsergebnis |\n| Code-Diff und statische Prüfung | Mittel | Die Änderungen sind sichtbar, das Runtime-Verhalten wird jedoch nicht bestätigt |\n| Tatsächliche Testausgabe und Exit-Code | Hoch | Es liegt ein reproduzierbares externes Ergebnis vor |\n| Browserinteraktion, Screenshots, Konsolen- und Leistungsergebnisse | Sehr hoch | Benutzerpfad und Runtime-Zustand werden direkt überprüft |\n| Unabhängiger Review Agent und CI kommen zum gleichen Ergebnis | Sehr hoch | Verringert den Selbstbestätigungs-Bias des implementierenden Agent |\n\nIn der offiziellen Dokumentation von Claude Code werden auch bundled Skills wie `/run` zur Prüfung einer laufenden Anwendung und `/verify` zur Überprüfung von Änderungen in der tatsächlichen Ausführungsumgebung erläutert. Wenn die Ausführung eines Projekts komplex ist, ist es sicherer, den exakten Startbefehl, die Umgebungsvariablen und den Ablauf der Datenvorbereitung in einem teamspezifischen Skill festzuhalten.\n\n## 4. Goal-based Loop: Die Entscheidung über den Abschluss übertragen\n\nBei einem Goal-based Loop entscheidet der Benutzer nicht jedes Mal, ob „noch ein weiterer Durchlauf“ erfolgen soll. Der Benutzer definiert den Abschlusszustand, und Claude setzt die Arbeit über mehrere Turns fort, bis diese Bedingungen erfüllt sind.\n\n```text\nBenutzer legt Goal fest\n  ↓\nArbeits-Turn von Claude\n  ↓\nSeparates Evaluierungsmodell prüft Abschlussbedingungen\n  ├─ Nicht erfüllt: Grund wird an den nächsten Turn übergeben\n  └─ Erfüllt: Goal wird beendet\n```\n\n`/goal` ist laut Dokumentation ab Claude Code v2.1.139 verfügbar. In einer Session kann nur ein Goal aktiv sein.\n\n### Was das Evaluierungsmodell tatsächlich sieht\n\nAm Ende jedes Turns prüft ein separates small fast model die Abschlussbedingungen und den Inhalt der Konversation und entscheidet zwischen `erfüllt` und `nicht erfüllt`. Standardmäßig wird ein Evaluierungsmodell der Haiku-Familie verwendet. Eine wichtige Einschränkung besteht darin, dass das Evaluierungsmodell Dateien nicht direkt liest und Tests nicht separat ausführt.\n\nClaude, das die Aufgabe ausführt, muss daher die folgenden Nachweise deutlich in der Konversation hinterlassen.\n\n- Ausgeführte Befehle\n- Anzahl der Tests und Ergebnisse zu Erfolg oder Fehlschlag\n- Exit-Code\n- Build-Ergebnis\n- Liste der geänderten Dateien\n- Ursachen verbleibender Fehler\n- Bestätigung, dass die Bereichsbeschränkungen eingehalten wurden\n\nDas Evaluierungsmodell beurteilt nicht, „was tatsächlich geschehen ist“, sondern „welche Nachweise in der Konversation sichtbar sind“.\n\n### Die vier Elemente eines guten Goal\n\nEin gutes Goal enthält die folgenden vier Elemente.\n\n1. **Messbare Erfolgskriterien**: bestandene Tests, erfolgreicher Build, geleerte Queue, erreichter Schwellenwert\n2. **Überprüfungsmethode**: Festlegung, mit welchem Befehl oder Tool der Erfolg nachgewiesen wird\n3. **Beschränkung des Änderungsbereichs**: veränderbare Verzeichnisse, verbotene Dateien, zulässige Side effects\n4. **Erzwungene Abbruchbedingungen**: maximale Anzahl von Turns, maximale Dauer, Anzahl aufeinanderfolgender Fehlschläge, Abbruch bei Berechtigungsfehlern\n\n```text\n/goal Alle auth-bezogenen Tests und lint müssen erfolgreich sein,\nund git diff darf nur src/auth und die zugehörigen Testdateien enthalten.\nIn jedem Turn werden Ausführungsergebnisse und Exit-Codes gemeldet.\nBeim Erreichen von maximal 12 Turns oder 45 Minuten abbrechen\nund die verbleibenden Fehler zusammenfassen.\n```\n\nDie zentralen Abbruchbedingungen von `/goal` selbst sind die Erfolgsentscheidung des Evaluierungsmodells oder `/goal clear` durch den Benutzer. Um ein Turn- oder Zeitlimit zu erzwingen, muss es ausdrücklich in den Goal-Bedingungen angegeben werden.\n\n### Gute und schlechte Bedingungen\n\n| Gute Bedingung | Schlechte Bedingung |\n|---|---|\n| `npm test` endet mit Exit-Code 0 | Den Code perfekt machen |\n| Alle 48 Authentifizierungstests bestehen | Die Benutzererfahrung so weit wie möglich verbessern |\n| Alle API-Aufrufstellen wurden auf das neue Interface umgestellt und der Build ist erfolgreich | Zu einer besseren Struktur refaktorieren |\n| Die Queue der zu bearbeitenden Issues ist leer und für jedes Issue wurde das Ergebnis erfasst | So viele Issues wie möglich bearbeiten |\n\nMehrdeutige Ziele können zu früh beendet werden oder endlose Verbesserungsdurchläufe auslösen.\n\n### Statusprüfung und Abbruch\n\n- `/goal`: Aktive Bedingungen, Ausführungsdauer, Anzahl der Evaluierungs-Turns, Token-Nutzung und jüngste Evaluierungsgründe prüfen\n- `/goal clear`: Aktives Goal abbrechen\n- Neues Goal festlegen: Bestehendes Goal ersetzen\n- `--resume` oder `--continue`: Unvollständiges Goal wiederherstellen\n\nBei der Wiederaufnahme bleiben die Bedingungen erhalten, doch Turn-Anzahl, Zeit und Token-Basiswert können zurückgesetzt werden. Daher sollte der Hard stop zusammen mit Betriebskennzahlen verwaltet werden.\n\n### `/goal` und Berechtigungen sind getrennte Aspekte\n\n`/goal` startet lediglich automatisch den nächsten Turn und erweitert keine Tool-Berechtigungen. Wenn das Schreiben von Dateien, Testbefehle oder Git-Aktionen genehmigungspflichtig sind, kann auch während eines Goal eine Genehmigung erforderlich sein.\n\nFür eine unbeaufsichtigte Ausführung kann zusätzlich Auto mode verwendet werden. Auto mode bedeutet jedoch nicht, dass „alle Tools bedingungslos erlaubt“ sind. Ein Klassifikator blockiert Aktionen, die destruktiv, schwer rückgängig zu machen oder auf Ziele außerhalb der Vertrauensgrenze gerichtet sind. Explizite `ask`- und `deny`-Regeln werden vor dem Klassifikator angewendet.\n\n## 5. Time-based Loop: Den Zeitpunkt der erneuten Ausführung übertragen\n\nWährend ein Goal-based Loop die Frage „Wann soll die Arbeit enden?“ behandelt, befasst sich ein Time-based Loop mit der Frage „Wann soll sie erneut ausgeführt werden?“. Er eignet sich für Aufgaben, bei denen sich der Zustand eines externen Systems mit der Zeit verändert.\n\n- Prüfen, ob ein PR neue Reviews erhalten hat\n- Prüfen, ob CI oder Deployment abgeschlossen ist\n- Status eines lang laufenden Builds prüfen\n- Tägliche Zusammenfassung von Slack-Nachrichten\n- Prüfung neuer Einträge in einer Issue-Queue\n\n### `/loop`: Wiederholte Ausführung innerhalb der aktuellen Session\n\n```text\n/loop 10m Aktuellen PR prüfen und neue Reviews berücksichtigen.\nFalls CI fehlgeschlagen ist, Ursache analysieren und beheben.\n```\n\nDie wichtigsten in der aktuellen Dokumentation beschriebenen Formen sind folgende.\n\n| Eingabe | Verhalten |\n|---|---|\n| `/loop 5m \u003cprompt\u003e` | Prompt in einem festgelegten festen Intervall ausführen |\n| `/loop \u003cprompt\u003e` | Claude wählt bei jeder Wiederholung das Intervall |\n| `/loop` | built-in Wartungs-Prompt oder `loop.md` des Projekts ausführen |\n| `/loop 20m /review-pr 1234` | Zulässigen Skill im festgelegten Intervall erneut ausführen |\n\n`/loop` ist an die aktuelle Claude Code-Session gebunden. Computer und Session müssen weiterlaufen; beim Start einer neuen Konversation gehen die Aufgaben im Session-Umfang verloren. Nicht abgelaufene Aufgaben können mit `--resume` oder `--continue` wiederhergestellt werden, wiederkehrende Aufgaben laufen jedoch standardmäßig 7 Tage nach ihrer Erstellung ab. Verpasste Intervalle werden nicht vollständig nachträglich ausgeführt.\n\nDa der Session-Scheduler Jitter anwenden kann, eignet er sich möglicherweise nicht für betriebliche Anforderungen, bei denen eine Ausführung „zwingend zur exakten Uhrzeit“ erfolgen muss.\n\n### `/schedule`: Von Anthropic verwaltete Cloud Routine\n\n`/schedule` erstellt eine Routine, die Prompt, Repository, Connector und Trigger kombiniert und auf einer von Anthropic verwalteten Infrastruktur ausgeführt wird. Sie kann auch bei geschlossenem Notebook ausgeführt werden und wird in der offiziellen Dokumentation als Research Preview bezeichnet.\n\nEine Routine unterstützt folgende Trigger.\n\n- Wiederkehrender Zeitplan\n- Einmaliger Termin zu einem bestimmten zukünftigen Zeitpunkt\n- Authentifizierter API-Aufruf\n- GitHub Pull request- oder Release-Event\n\nMit einer Routine können mehrere Trigger verbunden werden. Beispielsweise kann eine PR Review Routine jede Nacht ausgeführt werden und zugleich auf das Event `pull_request.opened` reagieren.\n\n### Vergleich von `/loop` und `/schedule`\n\n| Kriterium | `/loop` | `/schedule` Routine |\n|---|---|---|\n| Ausführungsort | Aktueller Computer und aktuelle Session | Von Anthropic verwaltete Cloud |\n| Ausführung nach Ausschalten des Computers | Im Allgemeinen nicht möglich | Möglich |\n| Offene Session erforderlich | Erforderlich | Nicht erforderlich |\n| Lokale nicht committete Dateien | Zugriff möglich | Kein Zugriff, Repository wird bei jeder Ausführung neu geklont |\n| Mindestintervall | Laut offizieller Dokumentation 1 Minute | Laut offizieller Dokumentation 1 Stunde |\n| Persistenz | Session-zentriert, wiederkehrende Aufgaben laufen nach 7 Tagen ab | Im Konto gespeicherte Routine |\n| Berechtigungs-Prompt | Übernimmt Richtlinie der aktuellen Session | Autonome Ausführung ohne interaktive Genehmigung |\n| Geeigneter Einsatz | Kurzzeitige Überwachung von PR und Deployment | Kontinuierliche Betriebsautomatisierung |\n\n### Wann Events besser sind als Polling\n\nWird ein PR, der sich nur selten ändert, jede Minute geprüft, enden die meisten Ausführungen, ohne dass etwas geschieht. Wenn das externe System Events senden kann, ist folgende Struktur effizienter.\n\n```text\nCI-Fehler oder PR-Aktualisierung\n  ↓\nGitHub Trigger oder Routine API\n  ↓\nClaude nur bei Bedarf ausführen\n```\n\nEin Event-basiertes Design verringert Verzögerungen sowie unnötige Modellaufrufe und Token-Verbrauch. Wenn Polling unvermeidbar ist, sollte das Intervall an die tatsächliche Änderungshäufigkeit angepasst und bei längerer Inaktivität Backoff angewendet werden.\n\n### Unverzichtbare Bedingungen für zeitbasierte Aufgaben\n\n1. **Idempotenz**: Auch wenn dasselbe Event mehrfach empfangen wird, dürfen keine doppelten Kommentare, PRs oder Deployments entstehen.\n2. **Verarbeitungsstatus**: Die zuletzt verarbeitete Event ID, Commit SHA, Review Comment ID usw. müssen erfasst werden.\n3. **Abschlusszustand**: Der Abschluss muss anhand von Zuständen wie PR merge oder close, Queue empty, Deploy success oder rollback bestimmbar sein.\n4. **Schreibbereich**: Side effects müssen eingeschränkt werden, etwa Kommentare erlaubt, Merge verboten und Push nur auf einen `claude/*` Branch.\n5. **Fehlerbehandlung**: Bei Ausfällen externer Dienste, abgelaufener Authentifizierung, Rate limit oder unzureichenden Berechtigungen sind Regeln für Wiederholungsversuche und Escalation erforderlich.\n\n## 6. Proactive Loop: Aufgabenerkennung und Orchestrierung übertragen\n\nEin Proactive Loop ist kein einzelner Befehl, sondern eine Architektur für kontinuierliche Automatisierung, die mehrere Funktionen kombiniert.\n\n```text\nTrigger\n+ Goal\n+ Skills\n+ Dynamic Workflow\n+ Auto mode\n+ Repository-, Connector-, Browser- und CI-Tools\n```\n\nAuch ohne dass ein Mensch in Echtzeit einen Prompt eingibt, werden neue Aufgaben erkannt, verarbeitet und überprüft sowie die Ergebnisse gemeldet.\n\n### Beispiel: Automatische Verarbeitung von Fehlerfeedback\n\n```text\nGitHub Issue oder Slack-Feedback empfangen\n  ↓\nDuplikat, Priorität und Reproduzierbarkeit klassifizieren\n  ↓\nReproduktionstest erstellen\n  ↓\nLösungskandidaten untersuchen\n  ↓\nAusgewählte Lösung implementieren\n  ↓\nUnabhängiger Review Agent sucht Gegenbeispiele\n  ↓\nTests, Build und Sicherheitsprüfung\n  ↓\nDraft PR und Ergebnisbericht\n```\n\nDie Zuständigkeiten der einzelnen Komponenten sind folgende.\n\n| Komponente | Verantwortung |\n|---|---|\n| Trigger oder `/schedule` | Bestimmen, wann eine neue Aufgabe gestartet wird |\n| `/goal` | Definieren, was bei dieser Ausführung als abgeschlossen gilt |\n| Skill | Abläufe für Reproduktion, Implementierung, Überprüfung und Berichterstattung standardisieren |\n| Dynamic Workflow | Parallele Ausführung mehrerer Subagents und bedingte Verzweigung |\n| Auto mode | Zulässige Tool-Aufrufe ohne Warten auf eine Genehmigung ausführen |\n| Permission policy | Verbotene, genehmigungspflichtige und automatisch erlaubte Bereiche festlegen |\n\n### Dynamic Workflow und Worktree\n\nBei einem Dynamic Workflow führt die Runtime ein von Claude erstelltes JavaScript-Orchestrierungs-Script aus. Bei normalen Subagent-Aufrufen wählt Claude in jedem Turn den nächsten Agent aus. In einem Workflow werden Loop, Parallelverarbeitung, Verzweigungen und Speicherung von Zwischenergebnissen dagegen in das Script verlagert.\n\n```text\nWorkflow Script\n  ├─ Agent A: Anforderungsanalyse\n  ├─ Agent B: Testentwurf\n  ├─ Agent C: Untersuchung von Implementierungskandidaten\n  ├─ Agent D: Sicherheitsprüfung\n  └─ Judge: Evidenzbasierter Vergleich\n```\n\nDa Zwischenergebnisse nicht im Context der Hauptkonversation, sondern in Script-Variablen verbleiben, lassen sich umfangreiche Aufgaben reproduzierbarer organisieren. In der aktuellen Dokumentation werden Runtime-Grenzen von gleichzeitig bis zu 16 Agents und bis zu 1.000 Agents pro Ausführung genannt. Einschränkungen in der Preview-Phase des Produkts können sich jedoch ändern.\n\nWenn mehrere Implementierungskandidaten gleichzeitig getestet werden müssen, können die Arbeitsbereiche mit Git Worktree getrennt werden.\n\n```text\nrepo/\nworktree-solution-a/\nworktree-solution-b/\nworktree-solution-c/\n```\n\nWenn jeder Agent in einem unabhängigen Branch und Verzeichnis arbeitet, sinkt das Risiko, dass dieselben Dateien gleichzeitig überschrieben werden. Der Judge Agent sollte die Kandidaten anhand der Erfüllung der Anforderungen, der Testergebnisse, des Regressionsrisikos, des Änderungsumfangs, der Komplexität, der Leistung, der Sicherheit und der Konsistenz mit der bestehenden Architektur vergleichen.\n\n### Mehr Agents sind nicht immer besser\n\nWenn bei einer Aufgabe keine Parallelität möglich ist, erhöhen zusätzliche Agents lediglich Kosten und Verzögerungen. Teilen mehrere Agents dieselbe falsche Annahme, können sich Fehler sogar verstärken.\n\nEin Dynamic Workflow eignet sich für folgende Fälle.\n\n- Migration, bei der dieselbe Transformation auf Hunderte Dateien angewendet wird\n- Sicherheits- oder Qualitäts-Audit der gesamten Codebasis\n- Vergleich von Plans aus mehreren unabhängigen Perspektiven\n- Research, bei dem viele Elemente aufgeteilt verarbeitet und gegenseitig überprüft werden müssen\n- Aufgaben, bei denen nicht alle Zwischenergebnisse in den Context eines einzelnen Agent passen\n\nFür kleine Fehlerkorrekturen, Refaktorierungen einer einzelnen Datei oder einfache Ergänzungen von Tests sind ein normaler Turn-based Loop oder `/goal` besser geeignet.\n\n## 7. System zur Wahrung der Codequalität in Loops\n\nDie Qualität der Loop-Ergebnisse hängt nicht nur vom Modell selbst, sondern in hohem Maße auch vom Überprüfungssystem rund um das Modell ab.\n\n### 7.1 Die Codebasis aufräumen\n\nClaude orientiert sich stark an Mustern des bestehenden Codes. Wenn veraltete APIs, doppelte Implementierungen, unklare Teststrukturen, riesige Module oder inkonsistente Regeln für die Ausnahmebehandlung vorhanden sind, kann ein Loop diese Probleme schnell vervielfältigen.\n\nFolgende Grundlagen sind unverzichtbar.\n\n- Formatter und lint\n- Klare Verzeichnis- und Modulgrenzen\n- Vertrauenswürdige Unit-, Integration- und E2E Tests\n- Unterscheidung zwischen verwendeten APIs und Deprecated APIs\n- Projektspezifische Entwicklungsregeln\n- Reproduzierbare Build- und Dev-Umgebung\n\n### 7.2 Definition of Done nach Änderungstyp erstellen\n\n| Änderungstyp | Mindestüberprüfung |\n|---|---|\n| API | Vertragstests, Abwärtskompatibilität, Aktualisierung von Schema und Dokumentationsbeispielen |\n| Frontend | Tatsächliche Browserbedienung, Konsolenfehler, Barrierefreiheit, responsive Darstellung |\n| Database | Forward- und Rollback Migration, Lock-Umfang, Ausführungsplan |\n| Dependency | Build, wichtige Regressionstests, License- und Security-Prüfung |\n| Infrastructure | Plan Diff, geringstmögliche Berechtigungen, Rollback, Prüfung auf Offenlegung geheimer Informationen |\n\nStatt diese Kriterien in jedem Prompt ausführlich zu wiederholen, sollten sie besser in Skill, Hook, Script oder CI Rule festgeschrieben werden.\n\n### 7.3 Aktuelle Dokumentation und exakte Versionen bereitstellen\n\nEin Loop kann falsche Annahmen mehrfach wiederholen. Die im Projekt verwendete exakte Version, offizielle Dokumentation, interne Architecture-Dokumentation, API-Spezifikationen, Migration Guide und genehmigte Beispiele müssen leicht auffindbar sein.\n\n### 7.4 Implementierenden Agent und Review Agent trennen\n\nEin Agent, der etwas implementiert hat, ist bereits durch das gewählte Design und die zugrunde liegenden Schlussfolgerungen beeinflusst. Ein Review Agent mit neuem Context kann folgende Fragen unabhängiger stellen.\n\n- Wurden Tests abgeschwächt, damit sie bestehen?\n- Wurden Dateien außerhalb des vorgesehenen Bereichs geändert?\n- Wurde eine Sicherheitsgrenze verletzt?\n- Fehlen Tests für Fehlerpfade und Grenzwerte?\n- Sind Regressionen bestehender Funktionen entstanden?\n\nEin Review Prompt ist wirksamer, wenn er statt „Fasse die guten Aspekte zusammen“ etwa lautet: „Gehe davon aus, dass die Implementierung falsch ist, suche Gegenbeispiele und füge jedem Kritikpunkt reproduzierbare Nachweise hinzu.“\n\n### 7.5 Einzelne Fehlschläge in Systemverbesserungen überführen\n\nWenn derselbe Fehler wiederholt auftritt, reicht es nicht, nur das jeweilige Ergebnis zu korrigieren. Damit sich diese Fehlerart schwerer wiederholen kann, muss eines der folgenden Elemente geändert werden.\n\n- Regression Test hinzufügen\n- Überprüfungsprozess des Skill verschärfen\n- Regel zu `CLAUDE.md` hinzufügen\n- Hook oder lint Rule hinzufügen\n- Berechtigungsregel `deny` hinzufügen\n- Abschlussbedingungen des Goal verschärfen\n- Review Checklist ergänzen\n\nGutes Loop Engineering bedeutet nicht, einen einzelnen Fehler zu beheben, sondern **ein System zu schaffen, in dem diese Art von Fehler schwerer erneut auftreten kann**.\n\n## 8. Token- und Kostenmanagement\n\nDie Kosten eines Loop können deutlich höher sein als die eines einzelnen Prompt.\n\n```text\nGesamtkosten ≈\nKosten der Turns des Haupt-Agent\n+ Kosten der Goal-Evaluierung\n+ Kosten der Subagents\n+ Kosten der Workflow-Wiederholungen\n+ Context-Kosten für das Lesen von Tool-Ergebnissen\n+ Häufigkeit zeitbasierter Ausführungen\n```\n\nDie genaue Abrechnung hängt von Plan, Model und Provider ab, die Prinzipien zur Bestimmung der Kostenstruktur bleiben jedoch gleich.\n\n### Praktische Prinzipien zur Kostensenkung\n\n1. **Für kleine Aufgaben keinen Loop verwenden.** Tippfehler, Umbenennungen und Typfehler in einer Datei in einem einzelnen Turn bearbeiten.\n2. **Erfolgskriterien und Hard stop gemeinsam definieren.** Erfolg, maximale Anzahl von Turns, maximale Dauer, aufeinanderfolgende Fehlschläge und Berechtigungsfehler berücksichtigen.\n3. **Umfangreiche Workflows zunächst in kleinem Rahmen testen.** Kosten und Qualität mit 5 Dateien, einem Verzeichnis oder einigen Issues überprüfen und den Umfang erst danach erhöhen.\n4. **Deterministische Aufgaben mit einem Script bearbeiten.** AST-Ersetzungen, JSON-Transformationen, Formatting und die Erstellung fester Formate sind mit einem überprüften Script günstiger und reproduzierbarer.\n5. **Polling-Intervall an die tatsächliche Änderungshäufigkeit anpassen.** Wenn möglich, Event Trigger verwenden.\n6. **Laufende Nutzung beobachten.** In `/usage`, `/goal` und `/workflows` die Nutzung von Skills, Subagents, MCP, Turns und Tokens prüfen.\n7. **Bei wiederholtem Auftreten desselben Fehlers nicht unbegrenzt weiter versuchen.** Ein Limit für aufeinanderfolgende Fehlschläge festlegen und an einen Menschen eskalieren.\n\n### Model und Effort sind unterschiedliche Stellhebel\n\n- **Model** verändert die grundlegende Schlussfolgerungsfähigkeit und den Bereich lösbarer Probleme.\n- **Effort** verändert die Anzahl gelesener Dateien, die Anzahl verwendeter Tools, die Breite der Überprüfung und wie konsequent mehrstufige Aufgaben bis zum Ende ausgeführt werden.\n\nWenn Claude alle erforderlichen Dateien und Tests geprüft hat, die Entscheidung selbst aber weiterhin falsch ist, kann ein stärkeres Model erforderlich sein. Wenn dagegen wichtige Dateien nicht gelesen, Tests übersprungen oder Refaktorierungen vorzeitig beendet werden, kann eine Erhöhung von Effort sinnvoller sein.\n\n## 9. Berechtigungen und Sicherheitsgrenzen\n\nDas gefährlichste Design eines Proactive Loop besteht darin, einem Agent weitreichende Berechtigungen zu geben und Erfolgskriterien sowie Abbruchbedingungen locker zu definieren.\n\nAuto mode reduziert normale Berechtigungs-Prompts. Tool calls, die schwer rückgängig zu machen oder destruktiv sind beziehungsweise auf Ziele außerhalb der Vertrauensgrenze gerichtet sind, können jedoch vom Klassifikator blockiert werden. Außerdem haben explizite `permissions.ask` und `permissions.deny` Vorrang vor Auto mode.\n\n### Beispiel einer Berechtigungshierarchie\n\n| Stufe | Beispiel |\n|---|---|\n| Automatisch erlaubt | Code lesen, Tests, lint und Build ausführen, analysieren, `claude/*` Branch erstellen, Draft PR erstellen |\n| Genehmigung durch Menschen | Übernahme in den Default Branch, Deployment in die Produktion, Anwendung einer DB Migration, Versand von Nachrichten an externe Kunden |\n| Immer verboten | Force push, Ausgabe von Secrets, Löschen von Produktionsdaten, Umgehen von Berechtigungen, Entfernen von Audit-Logs |\n\nEs ist sicherer, dauerhafte `ask`- und `deny`-Regeln festzulegen, als in der Konversation einmal „Nicht pushen“ zu sagen. Durch Context-Komprimierung oder einen Session-Wechsel können Regeln aus der Konversation an Wirkung verlieren.\n\nEine Cloud Routine klont das Repository bei jeder Ausführung neu und arbeitet mit den verbundenen GitHub- und Connector-Berechtigungen. Folgende Bereiche müssen minimiert werden.\n\n- Zugängliche Repositorys und Branches\n- Zulässige Network Domains\n- Zu verwendende Connectoren\n- Umgebungsvariablen und Secrets\n- Schreibberechtigungen für externe Systeme\n- Umfang von PR-Erstellung, Push und Merge\n\nDer Status „ordnungsgemäß beendet“ in der Ausführungsliste einer Routine kann lediglich bedeuten, dass die Session ohne Infrastructure-Fehler beendet wurde. Er garantiert nicht, dass das fachliche Ziel erfolgreich erreicht wurde. Transcript, Test evidence und der erzeugte Diff müssen separat geprüft werden.\n\n## 10. Vorlage zur Loop-Gestaltung für Entwicklungsprojekte\n\nDas folgende YAML ist keine tatsächliche Syntax von Claude Code, sondern ein Template für die Designprüfung.\n\n```yaml\ntrigger:\n  type: manual | interval | schedule | github_event | api_event\n\nscope:\n  repositories:\n    - target-repository\n  allowed_paths:\n    - src/**\n    - tests/**\n  prohibited_paths:\n    - production/**\n    - secrets/**\n\ntask:\n  objective: Zu änderndes oder zu bearbeitendes Ziel\n  input: Neu eingehendes Issue, Event, File oder neuer Zustand\n\nverification:\n  commands:\n    - unit-test\n    - integration-test\n    - lint\n    - build\n  runtime_checks:\n    - browser-interaction\n    - console-errors\n    - accessibility\n  evidence:\n    - command-output\n    - exit-code\n    - test-summary\n    - screenshots\n\nsuccess:\n  condition: Abschlusszustand, der als wahr oder falsch bewertet werden kann\n\nstop:\n  max_turns: 12\n  max_duration_minutes: 45\n  max_consecutive_failures: 3\n  stop_on_permission_error: true\n  escalate_on_external_outage: true\n\nside_effects:\n  idempotency_key: event-id-or-commit-sha\n  allow_branch_push: claude/*\n  require_human_for_merge: true\n  require_human_for_deploy: true\n\nreview:\n  independent_agent: true\n  adversarial_review: true\n\nobservability:\n  report_progress: true\n  report_token_usage: true\n  report_changed_files: true\n  report_remaining_failures: true\n```\n\nWichtiger als die Formulierung des Prompt selbst sind die folgenden fünf Elemente.\n\n```text\nTrigger\nVerifier\nSuccess condition\nHard stop\nPermission boundary\n```\n\n## 11. Welcher Loop sollte gewählt werden?\n\n| Situation | Empfohlene Methode |\n|---|---|\n| Aufgabe, die mit einer einzelnen Änderung und Überprüfung endet | Turn-based |\n| Aufgabe, die mehrere Versuche erfordert, aber einen klaren Abschlusszustand hat | `/goal` |\n| Aufgabe, bei der kurz auf den Zustand von externer CI, PR oder Deployment gewartet werden muss | `/loop` |\n| Aufgabe, die auch bei geschlossenem Notebook wiederholt ausgeführt werden muss | `/schedule` Routine |\n| Aufgabe, die sofort auf GitHub-Events oder Alerts reagieren muss | Event-triggered Routine |\n| Aufgabe, bei der Hunderte Elemente parallel verarbeitet und gegenseitig überprüft werden müssen | Dynamic Workflow |\n| Transformation mit vollständig deterministischen Ein- und Ausgaberegeln | Script oder CI Job |\n\nDie Auswahl sollte sich nicht nach der „leistungsstärksten Funktion“, sondern nach der „einfachsten Kontrollstruktur, die das Ziel erreicht“ richten.\n\n## 12. Sichere Einführungsreihenfolge\n\n1. Eine Engpassaufgabe auswählen, die ein Mensch wiederholt kontrollieren muss.\n2. Zunächst den Überprüfungsprozess als Skill, Script oder CI umsetzen.\n3. Die Qualität der Überprüfung im Turn-based-Verfahren stabilisieren.\n4. Wenn der Abschlusszustand eindeutig ist, `/goal` ergänzen.\n5. `/loop` nur verwenden, wenn auf einen externen Zustand gewartet werden muss.\n6. Wenn eine langfristige Ausführung erforderlich ist, zu einer `/schedule` Routine wechseln.\n7. Erst nach Überprüfung von Idempotenz, Berechtigungen und Kosten auf Dynamic Workflow und Proactive Loop erweitern.\n\n## 13. Häufige Missverständnisse\n\n| Missverständnis | Korrekte Interpretation |\n|---|---|\n| Ein Loop läuft unendlich | Es handelt sich um eine begrenzte Wiederholungsstruktur mit Erfolgskriterien und Hard stop |\n| Die Abschlussmeldung eines Agent ist eine Überprüfung | Externe Befehlsausgaben, Exit-Codes und Runtime-Ergebnisse sind erforderlich |\n| `/goal` erlaubt automatisch alle Berechtigungen | Es startet nur automatisch den nächsten Turn; die Berechtigungsrichtlinie ist davon getrennt |\n| `/loop` ist ein langfristiger betrieblicher Scheduler | Es ist Session-zentriert und unterliegt einer Ablaufzeit von 7 Tagen sowie Einschränkungen der Ausführungsumgebung |\n| Mehr Agents führen zu besseren Ergebnissen | Parallelisierung ist nur wertvoll, wenn Rollen, Perspektiven und Überprüfungen unterschiedlich sind |\n| Alle wiederkehrenden Aufgaben müssen von einem LLM ausgeführt werden | Deterministische Teile sind mit einem Script günstiger und besser reproduzierbar |\n\n## Fazit\n\nLoop Engineering ist keine Technik, um AI länger laufen zu lassen, sondern die **Gestaltung eines Kontrollsystems, das dafür sorgt, dass AI eigene Fehler erkennt, sie innerhalb eines Kostenlimits korrigiert und an riskanten Stellen stoppt**.\n\nLLM sind stark bei Exploration, Schlussfolgerung, Implementierung, Ausnahmeanalysen und dem Vergleich von Alternativen. Das System muss den Ausführungszeitpunkt, den Änderungsumfang, die Überprüfungsmethode, die Abbruchkriterien, das Kostenlimit und die Genehmigungsgrenzen verwalten. Je klarer diese Rollenverteilung ist, desto mehr entwickelt sich die Automatisierung mit Claude Code von einem einfachen Tool zur Codegenerierung zu einem reproduzierbaren und auditierbaren System für den Entwicklungsbetrieb.","content_html":"\u003cp\u003eDer Loop von Claude Code ist nicht einfach eine Funktion, mit der ein Modell länger ausgeführt wird. Im Kern geht es darum, rund um einen probabilistisch handelnden AI Agent \u003cstrong\u003eTrigger, Verifier, Success condition, Hard stop und Permission boundary\u003c/strong\u003e zu platzieren und so wiederkehrende Aufgaben in ein kontrollierbares System zu verwandeln. Dieser Artikel fasst die Unterschiede zwischen Turn-based, Goal-based, Time-based und Proactive Loop sowie praktische Gestaltungsprinzipien zusammen.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#1-was-ist-ein-loop-in-claude-code\" class=\"anchor\" id=\"1-was-ist-ein-loop-in-claude-code\"\u003e\u003c/a\u003e1. Was ist ein Loop in Claude Code?\u003c/h2\u003e\n\u003cp\u003eEin Loop ist hier keine \u003ccode\u003efor\u003c/code\u003e- oder \u003ccode\u003ewhile\u003c/code\u003e-Anweisung einer Programmiersprache. Der vom Claude Code-Team beschriebene Loop ist eine Ausführungsstruktur, in der ein Agent den aktuellen Zustand beobachtet, handelt, das Ergebnis überprüft und die Arbeit wiederholt, bis die Abbruchbedingung erfüllt ist.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eAufgabe starten\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eZustand und Code erfassen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003ePlan erstellen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eCode ändern oder Tool ausführen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTesten und überprüfen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eAbschlussbedingung erfüllt?\n\u003c/span\u003e\u003cspan\u003e  ├─ Nein: nächste Wiederholung\n\u003c/span\u003e\u003cspan\u003e  └─ Ja: beenden und Ergebnis melden\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eZur Unterscheidung von Loops sind die folgenden vier Fragen hilfreich.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eWas löst die Aufgabe aus?\u003c/li\u003e\n\u003cli\u003eWas beendet die Aufgabe?\u003c/li\u003e\n\u003cli\u003eWelche Funktion von Claude Code steuert die Wiederholung?\u003c/li\u003e\n\u003cli\u003eFür welche Art von Aufgabe eignet sie sich?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNicht jede Aufgabe muss in einen komplexen Loop umgewandelt werden. Bei Aufgaben, deren Ergebnis sofort überprüfbar ist, etwa der Korrektur eines Tippfehlers in einer Datei oder einer einfachen Umbenennung, ist ein normaler Prompt effizienter. Ein Loop sollte nur gewählt werden, wenn tatsächlich mehrere Beobachtungs-, Änderungs- und Überprüfungsdurchläufe erforderlich sind.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#2-vergleich-der-vier-loop-typen\" class=\"anchor\" id=\"2-vergleich-der-vier-loop-typen\"\u003e\u003c/a\u003e2. Vergleich der vier Loop-Typen\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eTyp\u003c/th\u003e\n\u003cth\u003eStartbedingung\u003c/th\u003e\n\u003cth\u003eAbbruchbedingung\u003c/th\u003e\n\u003cth\u003eHauptsächlich verwendete Funktionen\u003c/th\u003e\n\u003cth\u003eGeeignete Aufgaben\u003c/th\u003e\n\u003cth\u003eVom Menschen übertragene Verantwortung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Typ\"\u003eTurn-based\u003c/td\u003e\n\u003ctd data-label=\"Startbedingung\"\u003ePrompt des Benutzers\u003c/td\u003e\n\u003ctd data-label=\"Abbruchbedingung\"\u003eWenn Claude die Aufgabe für abgeschlossen hält oder zusätzliche Informationen benötigt\u003c/td\u003e\n\u003ctd data-label=\"Hauptsächlich verwendete Funktionen\"\u003eNormale Konversation, Skills, Test- und Browser-Tools\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Aufgaben\"\u003eKurze, einmalige Implementierungen und Änderungen\u003c/td\u003e\n\u003ctd data-label=\"Vom Menschen übertragene Verantwortung\"\u003eWiederholter Überprüfungsprozess\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Typ\"\u003eGoal-based\u003c/td\u003e\n\u003ctd data-label=\"Startbedingung\"\u003eBenutzer legt Abschlussbedingungen fest\u003c/td\u003e\n\u003ctd data-label=\"Abbruchbedingung\"\u003eEvaluierungsmodell bestätigt die Erfüllung oder Benutzer bricht ab\u003c/td\u003e\n\u003ctd data-label=\"Hauptsächlich verwendete Funktionen\"\u003e\n\u003ccode\u003e/goal\u003c/code\u003e, bei Bedarf Auto mode\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Aufgaben\"\u003eAufgaben mit messbarem Abschlusszustand wie Tests, Builds und Migrationen\u003c/td\u003e\n\u003ctd data-label=\"Vom Menschen übertragene Verantwortung\"\u003eEntscheidung über den Abschluss\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Typ\"\u003eTime-based\u003c/td\u003e\n\u003ctd data-label=\"Startbedingung\"\u003eFestgelegte Zeit, Intervall oder Zeitplan\u003c/td\u003e\n\u003ctd data-label=\"Abbruchbedingung\"\u003eBenutzer bricht ab oder externe Aufgabe endet\u003c/td\u003e\n\u003ctd data-label=\"Hauptsächlich verwendete Funktionen\"\u003e\n\u003ccode\u003e/loop\u003c/code\u003e, \u003ccode\u003e/schedule\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Aufgaben\"\u003eÜberwachung von PR, CI und Deployments, regelmäßige Zusammenfassungen, Status-Polling\u003c/td\u003e\n\u003ctd data-label=\"Vom Menschen übertragene Verantwortung\"\u003eZeitpunkt der nächsten Ausführung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Typ\"\u003eProactive\u003c/td\u003e\n\u003ctd data-label=\"Startbedingung\"\u003eZeitplan, API, GitHub-Event usw.\u003c/td\u003e\n\u003ctd data-label=\"Abbruchbedingung\"\u003eZiel der einzelnen Aufgabe erfüllt, Routine deaktiviert\u003c/td\u003e\n\u003ctd data-label=\"Hauptsächlich verwendete Funktionen\"\u003eRoutines, \u003ccode\u003e/goal\u003c/code\u003e, Skills, Dynamic Workflows, Auto mode\u003c/td\u003e\n\u003ctd data-label=\"Geeignete Aufgaben\"\u003eLaufende Aufgaben wie Issue-Klassifizierung, Fehlerbehandlung und umfangreiche Migrationen\u003c/td\u003e\n\u003ctd data-label=\"Vom Menschen übertragene Verantwortung\"\u003eErkennung von Aufgaben, Prompt-Ausführung, Orchestrierung\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDer Kern dieser Einteilung ist nicht, „wie intelligent die AI ist“, sondern \u003cstrong\u003ewelche Kontrollverantwortung der Mensch an das System überträgt\u003c/strong\u003e. Bei Turn-based erstellt der Mensch den nächsten Prompt, bei Goal-based überträgt er die Entscheidung über den Abschluss und bei Time-based den Zeitpunkt der erneuten Ausführung. In der Proactive-Stufe geht auch die Verantwortung dafür, das Auftreten einer Aufgabe zu erkennen und den passenden Prompt auszuführen, auf das System über.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#3-turn-based-loop-den-%C3%BCberpr%C3%BCfungsprozess-%C3%BCbertragen\" class=\"anchor\" id=\"3-turn-based-loop-den-überprüfungsprozess-übertragen\"\u003e\u003c/a\u003e3. Turn-based Loop: Den Überprüfungsprozess übertragen\u003c/h2\u003e\n\u003cp\u003eDer Turn-based Loop ist die grundlegende Form, in der die meisten Entwickler Claude Code verwenden.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eMensch → Claude → Mensch → Claude\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWenn der Benutzer eine Anfrage stellt, sucht Claude die relevanten Dateien, ändert den Code, führt Tests aus und meldet das Ergebnis. Intern können mehrere Beobachtungs-, Handlungs- und Überprüfungsschritte stattfinden, doch die Befugnis, die nächste Aufgabe zu starten, bleibt beim Benutzer.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#code%C3%A4nderung-und-funktionsabschluss-sind-nicht-dasselbe\" class=\"anchor\" id=\"codeänderung-und-funktionsabschluss-sind-nicht-dasselbe\"\u003e\u003c/a\u003eCodeänderung und Funktionsabschluss sind nicht dasselbe\u003c/h3\u003e\n\u003cp\u003eAuch wenn Claude meldet, „Implementierung und Tests abgeschlossen“ zu haben, können im tatsächlichen Produkt noch folgende Probleme bestehen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNach einem Klick auf eine Schaltfläche ändert sich der Zustand nicht.\u003c/li\u003e\n\u003cli\u003eIn der Browserkonsole tritt ein Fehler auf.\u003c/li\u003e\n\u003cli\u003eDas mobile Layout ist beschädigt.\u003c/li\u003e\n\u003cli\u003eAttribute für die Barrierefreiheit fehlen.\u003c/li\u003e\n\u003cli\u003eDie Tests bestehen, aber der tatsächliche Ablauf im Browser schlägt fehl.\u003c/li\u003e\n\u003cli\u003eEs wurden auch Dateien geändert, die nichts mit der Änderung zu tun haben.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDas Abschlusskriterium sollte daher nicht lauten „Der Code wurde geändert“, sondern „Die Funktion wurde anhand externer Nachweise bestätigt“.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#%C3%BCberpr%C3%BCfungen-mit-skillmd-wiederverwenden\" class=\"anchor\" id=\"überprüfungen-mit-skillmd-wiederverwenden\"\u003e\u003c/a\u003eÜberprüfungen mit \u003ccode\u003eSKILL.md\u003c/code\u003e wiederverwenden\u003c/h3\u003e\n\u003cp\u003eEin Skill ist eine Methode, wiederholt verwendete Anweisungen und Abläufe in \u003ccode\u003eSKILL.md\u003c/code\u003e zu speichern. Claude kann einen Skill automatisch laden, wenn es ihn für relevant hält, oder er kann direkt mit \u003ccode\u003e/skill-name\u003c/code\u003e ausgeführt werden. Statt lange Betriebsabläufe immer in \u003ccode\u003eCLAUDE.md\u003c/code\u003e aufzunehmen, lässt sich der Context effizienter nutzen, wenn sie getrennt und nur bei Bedarf als Skill geladen werden.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003ename: verify-ui-change\n\u003c/span\u003e\u003cspan\u003edescription: Überprüft UI-Änderungen in der tatsächlichen Ausführungsumgebung, bevor sie als abgeschlossen gelten.\n\u003c/span\u003e\u003cspan\u003e---\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e# Überprüfung von UI-Änderungen\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003e1. Den Entwicklungsserver starten.\n\u003c/span\u003e\u003cspan\u003e2. Die geänderte Ansicht im Browser öffnen.\n\u003c/span\u003e\u003cspan\u003e3. Das neue Steuerelement tatsächlich bedienen.\n\u003c/span\u003e\u003cspan\u003e4. Prüfen, ob die erwartete Zustandsänderung eintritt.\n\u003c/span\u003e\u003cspan\u003e5. Browserkonsole auf neue Fehler und Warnungen prüfen.\n\u003c/span\u003e\u003cspan\u003e6. Barrierefreiheit und wichtige Leistungskennzahlen prüfen.\n\u003c/span\u003e\u003cspan\u003e7. Bei einem Fehlschlag korrigieren und die Überprüfung von vorn beginnen.\n\u003c/span\u003e\u003cspan\u003e8. Nachweise wie ausgeführte Befehle, Ergebnisse und Screenshots melden.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEin guter Skill enthält keine abstrakten Ermahnungen, sondern eine ausführbare Checkliste. „Sorgfältiger prüfen“ ist eine wesentlich schwächere Regel als „Prüfen, ob \u003ccode\u003enpm test\u003c/code\u003e mit Exit-Code 0 endet“.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#aussagekraft-von-%C3%BCberpr%C3%BCfungsnachweisen\" class=\"anchor\" id=\"aussagekraft-von-überprüfungsnachweisen\"\u003e\u003c/a\u003eAussagekraft von Überprüfungsnachweisen\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eNachweis\u003c/th\u003e\n\u003cth\u003eVertrauenswürdigkeit\u003c/th\u003e\n\u003cth\u003eGrund\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Nachweis\"\u003eErklärung des Agent „Es scheint ordnungsgemäß zu funktionieren“\u003c/td\u003e\n\u003ctd data-label=\"Vertrauenswürdigkeit\"\u003eNiedrig\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eNur eine Schlussfolgerung, kein Ausführungsergebnis\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Nachweis\"\u003eCode-Diff und statische Prüfung\u003c/td\u003e\n\u003ctd data-label=\"Vertrauenswürdigkeit\"\u003eMittel\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eDie Änderungen sind sichtbar, das Runtime-Verhalten wird jedoch nicht bestätigt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Nachweis\"\u003eTatsächliche Testausgabe und Exit-Code\u003c/td\u003e\n\u003ctd data-label=\"Vertrauenswürdigkeit\"\u003eHoch\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eEs liegt ein reproduzierbares externes Ergebnis vor\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Nachweis\"\u003eBrowserinteraktion, Screenshots, Konsolen- und Leistungsergebnisse\u003c/td\u003e\n\u003ctd data-label=\"Vertrauenswürdigkeit\"\u003eSehr hoch\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eBenutzerpfad und Runtime-Zustand werden direkt überprüft\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Nachweis\"\u003eUnabhängiger Review Agent und CI kommen zum gleichen Ergebnis\u003c/td\u003e\n\u003ctd data-label=\"Vertrauenswürdigkeit\"\u003eSehr hoch\u003c/td\u003e\n\u003ctd data-label=\"Grund\"\u003eVerringert den Selbstbestätigungs-Bias des implementierenden Agent\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eIn der offiziellen Dokumentation von Claude Code werden auch bundled Skills wie \u003ccode\u003e/run\u003c/code\u003e zur Prüfung einer laufenden Anwendung und \u003ccode\u003e/verify\u003c/code\u003e zur Überprüfung von Änderungen in der tatsächlichen Ausführungsumgebung erläutert. Wenn die Ausführung eines Projekts komplex ist, ist es sicherer, den exakten Startbefehl, die Umgebungsvariablen und den Ablauf der Datenvorbereitung in einem teamspezifischen Skill festzuhalten.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#4-goal-based-loop-die-entscheidung-%C3%BCber-den-abschluss-%C3%BCbertragen\" class=\"anchor\" id=\"4-goal-based-loop-die-entscheidung-über-den-abschluss-übertragen\"\u003e\u003c/a\u003e4. Goal-based Loop: Die Entscheidung über den Abschluss übertragen\u003c/h2\u003e\n\u003cp\u003eBei einem Goal-based Loop entscheidet der Benutzer nicht jedes Mal, ob „noch ein weiterer Durchlauf“ erfolgen soll. Der Benutzer definiert den Abschlusszustand, und Claude setzt die Arbeit über mehrere Turns fort, bis diese Bedingungen erfüllt sind.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eBenutzer legt Goal fest\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eArbeits-Turn von Claude\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eSeparates Evaluierungsmodell prüft Abschlussbedingungen\n\u003c/span\u003e\u003cspan\u003e  ├─ Nicht erfüllt: Grund wird an den nächsten Turn übergeben\n\u003c/span\u003e\u003cspan\u003e  └─ Erfüllt: Goal wird beendet\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e ist laut Dokumentation ab Claude Code v2.1.139 verfügbar. In einer Session kann nur ein Goal aktiv sein.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#was-das-evaluierungsmodell-tats%C3%A4chlich-sieht\" class=\"anchor\" id=\"was-das-evaluierungsmodell-tatsächlich-sieht\"\u003e\u003c/a\u003eWas das Evaluierungsmodell tatsächlich sieht\u003c/h3\u003e\n\u003cp\u003eAm Ende jedes Turns prüft ein separates small fast model die Abschlussbedingungen und den Inhalt der Konversation und entscheidet zwischen \u003ccode\u003eerfüllt\u003c/code\u003e und \u003ccode\u003enicht erfüllt\u003c/code\u003e. Standardmäßig wird ein Evaluierungsmodell der Haiku-Familie verwendet. Eine wichtige Einschränkung besteht darin, dass das Evaluierungsmodell Dateien nicht direkt liest und Tests nicht separat ausführt.\u003c/p\u003e\n\u003cp\u003eClaude, das die Aufgabe ausführt, muss daher die folgenden Nachweise deutlich in der Konversation hinterlassen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eAusgeführte Befehle\u003c/li\u003e\n\u003cli\u003eAnzahl der Tests und Ergebnisse zu Erfolg oder Fehlschlag\u003c/li\u003e\n\u003cli\u003eExit-Code\u003c/li\u003e\n\u003cli\u003eBuild-Ergebnis\u003c/li\u003e\n\u003cli\u003eListe der geänderten Dateien\u003c/li\u003e\n\u003cli\u003eUrsachen verbleibender Fehler\u003c/li\u003e\n\u003cli\u003eBestätigung, dass die Bereichsbeschränkungen eingehalten wurden\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDas Evaluierungsmodell beurteilt nicht, „was tatsächlich geschehen ist“, sondern „welche Nachweise in der Konversation sichtbar sind“.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#die-vier-elemente-eines-guten-goal\" class=\"anchor\" id=\"die-vier-elemente-eines-guten-goal\"\u003e\u003c/a\u003eDie vier Elemente eines guten Goal\u003c/h3\u003e\n\u003cp\u003eEin gutes Goal enthält die folgenden vier Elemente.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eMessbare Erfolgskriterien\u003c/strong\u003e: bestandene Tests, erfolgreicher Build, geleerte Queue, erreichter Schwellenwert\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eÜberprüfungsmethode\u003c/strong\u003e: Festlegung, mit welchem Befehl oder Tool der Erfolg nachgewiesen wird\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBeschränkung des Änderungsbereichs\u003c/strong\u003e: veränderbare Verzeichnisse, verbotene Dateien, zulässige Side effects\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eErzwungene Abbruchbedingungen\u003c/strong\u003e: maximale Anzahl von Turns, maximale Dauer, Anzahl aufeinanderfolgender Fehlschläge, Abbruch bei Berechtigungsfehlern\u003c/li\u003e\n\u003c/ol\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/goal Alle auth-bezogenen Tests und lint müssen erfolgreich sein,\n\u003c/span\u003e\u003cspan\u003eund git diff darf nur src/auth und die zugehörigen Testdateien enthalten.\n\u003c/span\u003e\u003cspan\u003eIn jedem Turn werden Ausführungsergebnisse und Exit-Codes gemeldet.\n\u003c/span\u003e\u003cspan\u003eBeim Erreichen von maximal 12 Turns oder 45 Minuten abbrechen\n\u003c/span\u003e\u003cspan\u003eund die verbleibenden Fehler zusammenfassen.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDie zentralen Abbruchbedingungen von \u003ccode\u003e/goal\u003c/code\u003e selbst sind die Erfolgsentscheidung des Evaluierungsmodells oder \u003ccode\u003e/goal clear\u003c/code\u003e durch den Benutzer. Um ein Turn- oder Zeitlimit zu erzwingen, muss es ausdrücklich in den Goal-Bedingungen angegeben werden.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#gute-und-schlechte-bedingungen\" class=\"anchor\" id=\"gute-und-schlechte-bedingungen\"\u003e\u003c/a\u003eGute und schlechte Bedingungen\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eGute Bedingung\u003c/th\u003e\n\u003cth\u003eSchlechte Bedingung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gute Bedingung\"\u003e\n\u003ccode\u003enpm test\u003c/code\u003e endet mit Exit-Code 0\u003c/td\u003e\n\u003ctd data-label=\"Schlechte Bedingung\"\u003eDen Code perfekt machen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gute Bedingung\"\u003eAlle 48 Authentifizierungstests bestehen\u003c/td\u003e\n\u003ctd data-label=\"Schlechte Bedingung\"\u003eDie Benutzererfahrung so weit wie möglich verbessern\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gute Bedingung\"\u003eAlle API-Aufrufstellen wurden auf das neue Interface umgestellt und der Build ist erfolgreich\u003c/td\u003e\n\u003ctd data-label=\"Schlechte Bedingung\"\u003eZu einer besseren Struktur refaktorieren\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Gute Bedingung\"\u003eDie Queue der zu bearbeitenden Issues ist leer und für jedes Issue wurde das Ergebnis erfasst\u003c/td\u003e\n\u003ctd data-label=\"Schlechte Bedingung\"\u003eSo viele Issues wie möglich bearbeiten\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eMehrdeutige Ziele können zu früh beendet werden oder endlose Verbesserungsdurchläufe auslösen.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#statuspr%C3%BCfung-und-abbruch\" class=\"anchor\" id=\"statusprüfung-und-abbruch\"\u003e\u003c/a\u003eStatusprüfung und Abbruch\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003ccode\u003e/goal\u003c/code\u003e: Aktive Bedingungen, Ausführungsdauer, Anzahl der Evaluierungs-Turns, Token-Nutzung und jüngste Evaluierungsgründe prüfen\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003e/goal clear\u003c/code\u003e: Aktives Goal abbrechen\u003c/li\u003e\n\u003cli\u003eNeues Goal festlegen: Bestehendes Goal ersetzen\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003e--resume\u003c/code\u003e oder \u003ccode\u003e--continue\u003c/code\u003e: Unvollständiges Goal wiederherstellen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBei der Wiederaufnahme bleiben die Bedingungen erhalten, doch Turn-Anzahl, Zeit und Token-Basiswert können zurückgesetzt werden. Daher sollte der Hard stop zusammen mit Betriebskennzahlen verwaltet werden.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#goal-und-berechtigungen-sind-getrennte-aspekte\" class=\"anchor\" id=\"goal-und-berechtigungen-sind-getrennte-aspekte\"\u003e\u003c/a\u003e\u003ccode\u003e/goal\u003c/code\u003e und Berechtigungen sind getrennte Aspekte\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/goal\u003c/code\u003e startet lediglich automatisch den nächsten Turn und erweitert keine Tool-Berechtigungen. Wenn das Schreiben von Dateien, Testbefehle oder Git-Aktionen genehmigungspflichtig sind, kann auch während eines Goal eine Genehmigung erforderlich sein.\u003c/p\u003e\n\u003cp\u003eFür eine unbeaufsichtigte Ausführung kann zusätzlich Auto mode verwendet werden. Auto mode bedeutet jedoch nicht, dass „alle Tools bedingungslos erlaubt“ sind. Ein Klassifikator blockiert Aktionen, die destruktiv, schwer rückgängig zu machen oder auf Ziele außerhalb der Vertrauensgrenze gerichtet sind. Explizite \u003ccode\u003eask\u003c/code\u003e- und \u003ccode\u003edeny\u003c/code\u003e-Regeln werden vor dem Klassifikator angewendet.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#5-time-based-loop-den-zeitpunkt-der-erneuten-ausf%C3%BChrung-%C3%BCbertragen\" class=\"anchor\" id=\"5-time-based-loop-den-zeitpunkt-der-erneuten-ausführung-übertragen\"\u003e\u003c/a\u003e5. Time-based Loop: Den Zeitpunkt der erneuten Ausführung übertragen\u003c/h2\u003e\n\u003cp\u003eWährend ein Goal-based Loop die Frage „Wann soll die Arbeit enden?“ behandelt, befasst sich ein Time-based Loop mit der Frage „Wann soll sie erneut ausgeführt werden?“. Er eignet sich für Aufgaben, bei denen sich der Zustand eines externen Systems mit der Zeit verändert.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePrüfen, ob ein PR neue Reviews erhalten hat\u003c/li\u003e\n\u003cli\u003ePrüfen, ob CI oder Deployment abgeschlossen ist\u003c/li\u003e\n\u003cli\u003eStatus eines lang laufenden Builds prüfen\u003c/li\u003e\n\u003cli\u003eTägliche Zusammenfassung von Slack-Nachrichten\u003c/li\u003e\n\u003cli\u003ePrüfung neuer Einträge in einer Issue-Queue\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#loop-wiederholte-ausf%C3%BChrung-innerhalb-der-aktuellen-session\" class=\"anchor\" id=\"loop-wiederholte-ausführung-innerhalb-der-aktuellen-session\"\u003e\u003c/a\u003e\u003ccode\u003e/loop\u003c/code\u003e: Wiederholte Ausführung innerhalb der aktuellen Session\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003e/loop 10m Aktuellen PR prüfen und neue Reviews berücksichtigen.\n\u003c/span\u003e\u003cspan\u003eFalls CI fehlgeschlagen ist, Ursache analysieren und beheben.\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDie wichtigsten in der aktuellen Dokumentation beschriebenen Formen sind folgende.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eEingabe\u003c/th\u003e\n\u003cth\u003eVerhalten\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Eingabe\"\u003e\u003ccode\u003e/loop 5m \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Verhalten\"\u003ePrompt in einem festgelegten festen Intervall ausführen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Eingabe\"\u003e\u003ccode\u003e/loop \u0026lt;prompt\u0026gt;\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Verhalten\"\u003eClaude wählt bei jeder Wiederholung das Intervall\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Eingabe\"\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Verhalten\"\u003ebuilt-in Wartungs-Prompt oder \u003ccode\u003eloop.md\u003c/code\u003e des Projekts ausführen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Eingabe\"\u003e\u003ccode\u003e/loop 20m /review-pr 1234\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Verhalten\"\u003eZulässigen Skill im festgelegten Intervall erneut ausführen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003e\u003ccode\u003e/loop\u003c/code\u003e ist an die aktuelle Claude Code-Session gebunden. Computer und Session müssen weiterlaufen; beim Start einer neuen Konversation gehen die Aufgaben im Session-Umfang verloren. Nicht abgelaufene Aufgaben können mit \u003ccode\u003e--resume\u003c/code\u003e oder \u003ccode\u003e--continue\u003c/code\u003e wiederhergestellt werden, wiederkehrende Aufgaben laufen jedoch standardmäßig 7 Tage nach ihrer Erstellung ab. Verpasste Intervalle werden nicht vollständig nachträglich ausgeführt.\u003c/p\u003e\n\u003cp\u003eDa der Session-Scheduler Jitter anwenden kann, eignet er sich möglicherweise nicht für betriebliche Anforderungen, bei denen eine Ausführung „zwingend zur exakten Uhrzeit“ erfolgen muss.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#schedule-von-anthropic-verwaltete-cloud-routine\" class=\"anchor\" id=\"schedule-von-anthropic-verwaltete-cloud-routine\"\u003e\u003c/a\u003e\u003ccode\u003e/schedule\u003c/code\u003e: Von Anthropic verwaltete Cloud Routine\u003c/h3\u003e\n\u003cp\u003e\u003ccode\u003e/schedule\u003c/code\u003e erstellt eine Routine, die Prompt, Repository, Connector und Trigger kombiniert und auf einer von Anthropic verwalteten Infrastruktur ausgeführt wird. Sie kann auch bei geschlossenem Notebook ausgeführt werden und wird in der offiziellen Dokumentation als Research Preview bezeichnet.\u003c/p\u003e\n\u003cp\u003eEine Routine unterstützt folgende Trigger.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWiederkehrender Zeitplan\u003c/li\u003e\n\u003cli\u003eEinmaliger Termin zu einem bestimmten zukünftigen Zeitpunkt\u003c/li\u003e\n\u003cli\u003eAuthentifizierter API-Aufruf\u003c/li\u003e\n\u003cli\u003eGitHub Pull request- oder Release-Event\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eMit einer Routine können mehrere Trigger verbunden werden. Beispielsweise kann eine PR Review Routine jede Nacht ausgeführt werden und zugleich auf das Event \u003ccode\u003epull_request.opened\u003c/code\u003e reagieren.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#vergleich-von-loop-und-schedule\" class=\"anchor\" id=\"vergleich-von-loop-und-schedule\"\u003e\u003c/a\u003eVergleich von \u003ccode\u003e/loop\u003c/code\u003e und \u003ccode\u003e/schedule\u003c/code\u003e\n\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKriterium\u003c/th\u003e\n\u003cth\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/th\u003e\n\u003cth\u003e\n\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eAusführungsort\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eAktueller Computer und aktuelle Session\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eVon Anthropic verwaltete Cloud\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eAusführung nach Ausschalten des Computers\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eIm Allgemeinen nicht möglich\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eMöglich\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eOffene Session erforderlich\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eErforderlich\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eNicht erforderlich\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eLokale nicht committete Dateien\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eZugriff möglich\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eKein Zugriff, Repository wird bei jeder Ausführung neu geklont\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eMindestintervall\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eLaut offizieller Dokumentation 1 Minute\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eLaut offizieller Dokumentation 1 Stunde\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003ePersistenz\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eSession-zentriert, wiederkehrende Aufgaben laufen nach 7 Tagen ab\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eIm Konto gespeicherte Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eBerechtigungs-Prompt\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eÜbernimmt Richtlinie der aktuellen Session\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eAutonome Ausführung ohne interaktive Genehmigung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Kriterium\"\u003eGeeigneter Einsatz\u003c/td\u003e\n\u003ctd data-label=\"/loop\"\u003eKurzzeitige Überwachung von PR und Deployment\u003c/td\u003e\n\u003ctd data-label=\"/schedule Routine\"\u003eKontinuierliche Betriebsautomatisierung\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#wann-events-besser-sind-als-polling\" class=\"anchor\" id=\"wann-events-besser-sind-als-polling\"\u003e\u003c/a\u003eWann Events besser sind als Polling\u003c/h3\u003e\n\u003cp\u003eWird ein PR, der sich nur selten ändert, jede Minute geprüft, enden die meisten Ausführungen, ohne dass etwas geschieht. Wenn das externe System Events senden kann, ist folgende Struktur effizienter.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eCI-Fehler oder PR-Aktualisierung\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eGitHub Trigger oder Routine API\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eClaude nur bei Bedarf ausführen\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eEin Event-basiertes Design verringert Verzögerungen sowie unnötige Modellaufrufe und Token-Verbrauch. Wenn Polling unvermeidbar ist, sollte das Intervall an die tatsächliche Änderungshäufigkeit angepasst und bei längerer Inaktivität Backoff angewendet werden.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#unverzichtbare-bedingungen-f%C3%BCr-zeitbasierte-aufgaben\" class=\"anchor\" id=\"unverzichtbare-bedingungen-für-zeitbasierte-aufgaben\"\u003e\u003c/a\u003eUnverzichtbare Bedingungen für zeitbasierte Aufgaben\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eIdempotenz\u003c/strong\u003e: Auch wenn dasselbe Event mehrfach empfangen wird, dürfen keine doppelten Kommentare, PRs oder Deployments entstehen.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eVerarbeitungsstatus\u003c/strong\u003e: Die zuletzt verarbeitete Event ID, Commit SHA, Review Comment ID usw. müssen erfasst werden.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eAbschlusszustand\u003c/strong\u003e: Der Abschluss muss anhand von Zuständen wie PR merge oder close, Queue empty, Deploy success oder rollback bestimmbar sein.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eSchreibbereich\u003c/strong\u003e: Side effects müssen eingeschränkt werden, etwa Kommentare erlaubt, Merge verboten und Push nur auf einen \u003ccode\u003eclaude/*\u003c/code\u003e Branch.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eFehlerbehandlung\u003c/strong\u003e: Bei Ausfällen externer Dienste, abgelaufener Authentifizierung, Rate limit oder unzureichenden Berechtigungen sind Regeln für Wiederholungsversuche und Escalation erforderlich.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\n\u003ca href=\"#6-proactive-loop-aufgabenerkennung-und-orchestrierung-%C3%BCbertragen\" class=\"anchor\" id=\"6-proactive-loop-aufgabenerkennung-und-orchestrierung-übertragen\"\u003e\u003c/a\u003e6. Proactive Loop: Aufgabenerkennung und Orchestrierung übertragen\u003c/h2\u003e\n\u003cp\u003eEin Proactive Loop ist kein einzelner Befehl, sondern eine Architektur für kontinuierliche Automatisierung, die mehrere Funktionen kombiniert.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003e+ Goal\n\u003c/span\u003e\u003cspan\u003e+ Skills\n\u003c/span\u003e\u003cspan\u003e+ Dynamic Workflow\n\u003c/span\u003e\u003cspan\u003e+ Auto mode\n\u003c/span\u003e\u003cspan\u003e+ Repository-, Connector-, Browser- und CI-Tools\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eAuch ohne dass ein Mensch in Echtzeit einen Prompt eingibt, werden neue Aufgaben erkannt, verarbeitet und überprüft sowie die Ergebnisse gemeldet.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiel-automatische-verarbeitung-von-fehlerfeedback\" class=\"anchor\" id=\"beispiel-automatische-verarbeitung-von-fehlerfeedback\"\u003e\u003c/a\u003eBeispiel: Automatische Verarbeitung von Fehlerfeedback\u003c/h3\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eGitHub Issue oder Slack-Feedback empfangen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDuplikat, Priorität und Reproduzierbarkeit klassifizieren\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eReproduktionstest erstellen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eLösungskandidaten untersuchen\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eAusgewählte Lösung implementieren\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eUnabhängiger Review Agent sucht Gegenbeispiele\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eTests, Build und Sicherheitsprüfung\n\u003c/span\u003e\u003cspan\u003e  ↓\n\u003c/span\u003e\u003cspan\u003eDraft PR und Ergebnisbericht\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDie Zuständigkeiten der einzelnen Komponenten sind folgende.\u003c/p\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eKomponente\u003c/th\u003e\n\u003cth\u003eVerantwortung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Komponente\"\u003eTrigger oder \u003ccode\u003e/schedule\u003c/code\u003e\n\u003c/td\u003e\n\u003ctd data-label=\"Verantwortung\"\u003eBestimmen, wann eine neue Aufgabe gestartet wird\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Komponente\"\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003ctd data-label=\"Verantwortung\"\u003eDefinieren, was bei dieser Ausführung als abgeschlossen gilt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Komponente\"\u003eSkill\u003c/td\u003e\n\u003ctd data-label=\"Verantwortung\"\u003eAbläufe für Reproduktion, Implementierung, Überprüfung und Berichterstattung standardisieren\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Komponente\"\u003eDynamic Workflow\u003c/td\u003e\n\u003ctd data-label=\"Verantwortung\"\u003eParallele Ausführung mehrerer Subagents und bedingte Verzweigung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Komponente\"\u003eAuto mode\u003c/td\u003e\n\u003ctd data-label=\"Verantwortung\"\u003eZulässige Tool-Aufrufe ohne Warten auf eine Genehmigung ausführen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Komponente\"\u003ePermission policy\u003c/td\u003e\n\u003ctd data-label=\"Verantwortung\"\u003eVerbotene, genehmigungspflichtige und automatisch erlaubte Bereiche festlegen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch3\u003e\n\u003ca href=\"#dynamic-workflow-und-worktree\" class=\"anchor\" id=\"dynamic-workflow-und-worktree\"\u003e\u003c/a\u003eDynamic Workflow und Worktree\u003c/h3\u003e\n\u003cp\u003eBei einem Dynamic Workflow führt die Runtime ein von Claude erstelltes JavaScript-Orchestrierungs-Script aus. Bei normalen Subagent-Aufrufen wählt Claude in jedem Turn den nächsten Agent aus. In einem Workflow werden Loop, Parallelverarbeitung, Verzweigungen und Speicherung von Zwischenergebnissen dagegen in das Script verlagert.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eWorkflow Script\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent A: Anforderungsanalyse\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent B: Testentwurf\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent C: Untersuchung von Implementierungskandidaten\n\u003c/span\u003e\u003cspan\u003e  ├─ Agent D: Sicherheitsprüfung\n\u003c/span\u003e\u003cspan\u003e  └─ Judge: Evidenzbasierter Vergleich\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDa Zwischenergebnisse nicht im Context der Hauptkonversation, sondern in Script-Variablen verbleiben, lassen sich umfangreiche Aufgaben reproduzierbarer organisieren. In der aktuellen Dokumentation werden Runtime-Grenzen von gleichzeitig bis zu 16 Agents und bis zu 1.000 Agents pro Ausführung genannt. Einschränkungen in der Preview-Phase des Produkts können sich jedoch ändern.\u003c/p\u003e\n\u003cp\u003eWenn mehrere Implementierungskandidaten gleichzeitig getestet werden müssen, können die Arbeitsbereiche mit Git Worktree getrennt werden.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003erepo/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-a/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-b/\n\u003c/span\u003e\u003cspan\u003eworktree-solution-c/\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWenn jeder Agent in einem unabhängigen Branch und Verzeichnis arbeitet, sinkt das Risiko, dass dieselben Dateien gleichzeitig überschrieben werden. Der Judge Agent sollte die Kandidaten anhand der Erfüllung der Anforderungen, der Testergebnisse, des Regressionsrisikos, des Änderungsumfangs, der Komplexität, der Leistung, der Sicherheit und der Konsistenz mit der bestehenden Architektur vergleichen.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#mehr-agents-sind-nicht-immer-besser\" class=\"anchor\" id=\"mehr-agents-sind-nicht-immer-besser\"\u003e\u003c/a\u003eMehr Agents sind nicht immer besser\u003c/h3\u003e\n\u003cp\u003eWenn bei einer Aufgabe keine Parallelität möglich ist, erhöhen zusätzliche Agents lediglich Kosten und Verzögerungen. Teilen mehrere Agents dieselbe falsche Annahme, können sich Fehler sogar verstärken.\u003c/p\u003e\n\u003cp\u003eEin Dynamic Workflow eignet sich für folgende Fälle.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eMigration, bei der dieselbe Transformation auf Hunderte Dateien angewendet wird\u003c/li\u003e\n\u003cli\u003eSicherheits- oder Qualitäts-Audit der gesamten Codebasis\u003c/li\u003e\n\u003cli\u003eVergleich von Plans aus mehreren unabhängigen Perspektiven\u003c/li\u003e\n\u003cli\u003eResearch, bei dem viele Elemente aufgeteilt verarbeitet und gegenseitig überprüft werden müssen\u003c/li\u003e\n\u003cli\u003eAufgaben, bei denen nicht alle Zwischenergebnisse in den Context eines einzelnen Agent passen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eFür kleine Fehlerkorrekturen, Refaktorierungen einer einzelnen Datei oder einfache Ergänzungen von Tests sind ein normaler Turn-based Loop oder \u003ccode\u003e/goal\u003c/code\u003e besser geeignet.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#7-system-zur-wahrung-der-codequalit%C3%A4t-in-loops\" class=\"anchor\" id=\"7-system-zur-wahrung-der-codequalität-in-loops\"\u003e\u003c/a\u003e7. System zur Wahrung der Codequalität in Loops\u003c/h2\u003e\n\u003cp\u003eDie Qualität der Loop-Ergebnisse hängt nicht nur vom Modell selbst, sondern in hohem Maße auch vom Überprüfungssystem rund um das Modell ab.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#71-die-codebasis-aufr%C3%A4umen\" class=\"anchor\" id=\"71-die-codebasis-aufräumen\"\u003e\u003c/a\u003e7.1 Die Codebasis aufräumen\u003c/h3\u003e\n\u003cp\u003eClaude orientiert sich stark an Mustern des bestehenden Codes. Wenn veraltete APIs, doppelte Implementierungen, unklare Teststrukturen, riesige Module oder inkonsistente Regeln für die Ausnahmebehandlung vorhanden sind, kann ein Loop diese Probleme schnell vervielfältigen.\u003c/p\u003e\n\u003cp\u003eFolgende Grundlagen sind unverzichtbar.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFormatter und lint\u003c/li\u003e\n\u003cli\u003eKlare Verzeichnis- und Modulgrenzen\u003c/li\u003e\n\u003cli\u003eVertrauenswürdige Unit-, Integration- und E2E Tests\u003c/li\u003e\n\u003cli\u003eUnterscheidung zwischen verwendeten APIs und Deprecated APIs\u003c/li\u003e\n\u003cli\u003eProjektspezifische Entwicklungsregeln\u003c/li\u003e\n\u003cli\u003eReproduzierbare Build- und Dev-Umgebung\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch3\u003e\n\u003ca href=\"#72-definition-of-done-nach-%C3%A4nderungstyp-erstellen\" class=\"anchor\" id=\"72-definition-of-done-nach-änderungstyp-erstellen\"\u003e\u003c/a\u003e7.2 Definition of Done nach Änderungstyp erstellen\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eÄnderungstyp\u003c/th\u003e\n\u003cth\u003eMindestüberprüfung\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Änderungstyp\"\u003eAPI\u003c/td\u003e\n\u003ctd data-label=\"Mindestüberprüfung\"\u003eVertragstests, Abwärtskompatibilität, Aktualisierung von Schema und Dokumentationsbeispielen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Änderungstyp\"\u003eFrontend\u003c/td\u003e\n\u003ctd data-label=\"Mindestüberprüfung\"\u003eTatsächliche Browserbedienung, Konsolenfehler, Barrierefreiheit, responsive Darstellung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Änderungstyp\"\u003eDatabase\u003c/td\u003e\n\u003ctd data-label=\"Mindestüberprüfung\"\u003eForward- und Rollback Migration, Lock-Umfang, Ausführungsplan\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Änderungstyp\"\u003eDependency\u003c/td\u003e\n\u003ctd data-label=\"Mindestüberprüfung\"\u003eBuild, wichtige Regressionstests, License- und Security-Prüfung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Änderungstyp\"\u003eInfrastructure\u003c/td\u003e\n\u003ctd data-label=\"Mindestüberprüfung\"\u003ePlan Diff, geringstmögliche Berechtigungen, Rollback, Prüfung auf Offenlegung geheimer Informationen\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eStatt diese Kriterien in jedem Prompt ausführlich zu wiederholen, sollten sie besser in Skill, Hook, Script oder CI Rule festgeschrieben werden.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#73-aktuelle-dokumentation-und-exakte-versionen-bereitstellen\" class=\"anchor\" id=\"73-aktuelle-dokumentation-und-exakte-versionen-bereitstellen\"\u003e\u003c/a\u003e7.3 Aktuelle Dokumentation und exakte Versionen bereitstellen\u003c/h3\u003e\n\u003cp\u003eEin Loop kann falsche Annahmen mehrfach wiederholen. Die im Projekt verwendete exakte Version, offizielle Dokumentation, interne Architecture-Dokumentation, API-Spezifikationen, Migration Guide und genehmigte Beispiele müssen leicht auffindbar sein.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#74-implementierenden-agent-und-review-agent-trennen\" class=\"anchor\" id=\"74-implementierenden-agent-und-review-agent-trennen\"\u003e\u003c/a\u003e7.4 Implementierenden Agent und Review Agent trennen\u003c/h3\u003e\n\u003cp\u003eEin Agent, der etwas implementiert hat, ist bereits durch das gewählte Design und die zugrunde liegenden Schlussfolgerungen beeinflusst. Ein Review Agent mit neuem Context kann folgende Fragen unabhängiger stellen.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWurden Tests abgeschwächt, damit sie bestehen?\u003c/li\u003e\n\u003cli\u003eWurden Dateien außerhalb des vorgesehenen Bereichs geändert?\u003c/li\u003e\n\u003cli\u003eWurde eine Sicherheitsgrenze verletzt?\u003c/li\u003e\n\u003cli\u003eFehlen Tests für Fehlerpfade und Grenzwerte?\u003c/li\u003e\n\u003cli\u003eSind Regressionen bestehender Funktionen entstanden?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eEin Review Prompt ist wirksamer, wenn er statt „Fasse die guten Aspekte zusammen“ etwa lautet: „Gehe davon aus, dass die Implementierung falsch ist, suche Gegenbeispiele und füge jedem Kritikpunkt reproduzierbare Nachweise hinzu.“\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#75-einzelne-fehlschl%C3%A4ge-in-systemverbesserungen-%C3%BCberf%C3%BChren\" class=\"anchor\" id=\"75-einzelne-fehlschläge-in-systemverbesserungen-überführen\"\u003e\u003c/a\u003e7.5 Einzelne Fehlschläge in Systemverbesserungen überführen\u003c/h3\u003e\n\u003cp\u003eWenn derselbe Fehler wiederholt auftritt, reicht es nicht, nur das jeweilige Ergebnis zu korrigieren. Damit sich diese Fehlerart schwerer wiederholen kann, muss eines der folgenden Elemente geändert werden.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eRegression Test hinzufügen\u003c/li\u003e\n\u003cli\u003eÜberprüfungsprozess des Skill verschärfen\u003c/li\u003e\n\u003cli\u003eRegel zu \u003ccode\u003eCLAUDE.md\u003c/code\u003e hinzufügen\u003c/li\u003e\n\u003cli\u003eHook oder lint Rule hinzufügen\u003c/li\u003e\n\u003cli\u003eBerechtigungsregel \u003ccode\u003edeny\u003c/code\u003e hinzufügen\u003c/li\u003e\n\u003cli\u003eAbschlussbedingungen des Goal verschärfen\u003c/li\u003e\n\u003cli\u003eReview Checklist ergänzen\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eGutes Loop Engineering bedeutet nicht, einen einzelnen Fehler zu beheben, sondern \u003cstrong\u003eein System zu schaffen, in dem diese Art von Fehler schwerer erneut auftreten kann\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#8-token--und-kostenmanagement\" class=\"anchor\" id=\"8-token--und-kostenmanagement\"\u003e\u003c/a\u003e8. Token- und Kostenmanagement\u003c/h2\u003e\n\u003cp\u003eDie Kosten eines Loop können deutlich höher sein als die eines einzelnen Prompt.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eGesamtkosten ≈\n\u003c/span\u003e\u003cspan\u003eKosten der Turns des Haupt-Agent\n\u003c/span\u003e\u003cspan\u003e+ Kosten der Goal-Evaluierung\n\u003c/span\u003e\u003cspan\u003e+ Kosten der Subagents\n\u003c/span\u003e\u003cspan\u003e+ Kosten der Workflow-Wiederholungen\n\u003c/span\u003e\u003cspan\u003e+ Context-Kosten für das Lesen von Tool-Ergebnissen\n\u003c/span\u003e\u003cspan\u003e+ Häufigkeit zeitbasierter Ausführungen\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eDie genaue Abrechnung hängt von Plan, Model und Provider ab, die Prinzipien zur Bestimmung der Kostenstruktur bleiben jedoch gleich.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#praktische-prinzipien-zur-kostensenkung\" class=\"anchor\" id=\"praktische-prinzipien-zur-kostensenkung\"\u003e\u003c/a\u003ePraktische Prinzipien zur Kostensenkung\u003c/h3\u003e\n\u003col\u003e\n\u003cli\u003e\n\u003cstrong\u003eFür kleine Aufgaben keinen Loop verwenden.\u003c/strong\u003e Tippfehler, Umbenennungen und Typfehler in einer Datei in einem einzelnen Turn bearbeiten.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eErfolgskriterien und Hard stop gemeinsam definieren.\u003c/strong\u003e Erfolg, maximale Anzahl von Turns, maximale Dauer, aufeinanderfolgende Fehlschläge und Berechtigungsfehler berücksichtigen.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eUmfangreiche Workflows zunächst in kleinem Rahmen testen.\u003c/strong\u003e Kosten und Qualität mit 5 Dateien, einem Verzeichnis oder einigen Issues überprüfen und den Umfang erst danach erhöhen.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eDeterministische Aufgaben mit einem Script bearbeiten.\u003c/strong\u003e AST-Ersetzungen, JSON-Transformationen, Formatting und die Erstellung fester Formate sind mit einem überprüften Script günstiger und reproduzierbarer.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003ePolling-Intervall an die tatsächliche Änderungshäufigkeit anpassen.\u003c/strong\u003e Wenn möglich, Event Trigger verwenden.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eLaufende Nutzung beobachten.\u003c/strong\u003e In \u003ccode\u003e/usage\u003c/code\u003e, \u003ccode\u003e/goal\u003c/code\u003e und \u003ccode\u003e/workflows\u003c/code\u003e die Nutzung von Skills, Subagents, MCP, Turns und Tokens prüfen.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eBei wiederholtem Auftreten desselben Fehlers nicht unbegrenzt weiter versuchen.\u003c/strong\u003e Ein Limit für aufeinanderfolgende Fehlschläge festlegen und an einen Menschen eskalieren.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch3\u003e\n\u003ca href=\"#model-und-effort-sind-unterschiedliche-stellhebel\" class=\"anchor\" id=\"model-und-effort-sind-unterschiedliche-stellhebel\"\u003e\u003c/a\u003eModel und Effort sind unterschiedliche Stellhebel\u003c/h3\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cstrong\u003eModel\u003c/strong\u003e verändert die grundlegende Schlussfolgerungsfähigkeit und den Bereich lösbarer Probleme.\u003c/li\u003e\n\u003cli\u003e\n\u003cstrong\u003eEffort\u003c/strong\u003e verändert die Anzahl gelesener Dateien, die Anzahl verwendeter Tools, die Breite der Überprüfung und wie konsequent mehrstufige Aufgaben bis zum Ende ausgeführt werden.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eWenn Claude alle erforderlichen Dateien und Tests geprüft hat, die Entscheidung selbst aber weiterhin falsch ist, kann ein stärkeres Model erforderlich sein. Wenn dagegen wichtige Dateien nicht gelesen, Tests übersprungen oder Refaktorierungen vorzeitig beendet werden, kann eine Erhöhung von Effort sinnvoller sein.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#9-berechtigungen-und-sicherheitsgrenzen\" class=\"anchor\" id=\"9-berechtigungen-und-sicherheitsgrenzen\"\u003e\u003c/a\u003e9. Berechtigungen und Sicherheitsgrenzen\u003c/h2\u003e\n\u003cp\u003eDas gefährlichste Design eines Proactive Loop besteht darin, einem Agent weitreichende Berechtigungen zu geben und Erfolgskriterien sowie Abbruchbedingungen locker zu definieren.\u003c/p\u003e\n\u003cp\u003eAuto mode reduziert normale Berechtigungs-Prompts. Tool calls, die schwer rückgängig zu machen oder destruktiv sind beziehungsweise auf Ziele außerhalb der Vertrauensgrenze gerichtet sind, können jedoch vom Klassifikator blockiert werden. Außerdem haben explizite \u003ccode\u003epermissions.ask\u003c/code\u003e und \u003ccode\u003epermissions.deny\u003c/code\u003e Vorrang vor Auto mode.\u003c/p\u003e\n\u003ch3\u003e\n\u003ca href=\"#beispiel-einer-berechtigungshierarchie\" class=\"anchor\" id=\"beispiel-einer-berechtigungshierarchie\"\u003e\u003c/a\u003eBeispiel einer Berechtigungshierarchie\u003c/h3\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eStufe\u003c/th\u003e\n\u003cth\u003eBeispiel\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Stufe\"\u003eAutomatisch erlaubt\u003c/td\u003e\n\u003ctd data-label=\"Beispiel\"\u003eCode lesen, Tests, lint und Build ausführen, analysieren, \u003ccode\u003eclaude/*\u003c/code\u003e Branch erstellen, Draft PR erstellen\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Stufe\"\u003eGenehmigung durch Menschen\u003c/td\u003e\n\u003ctd data-label=\"Beispiel\"\u003eÜbernahme in den Default Branch, Deployment in die Produktion, Anwendung einer DB Migration, Versand von Nachrichten an externe Kunden\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Stufe\"\u003eImmer verboten\u003c/td\u003e\n\u003ctd data-label=\"Beispiel\"\u003eForce push, Ausgabe von Secrets, Löschen von Produktionsdaten, Umgehen von Berechtigungen, Entfernen von Audit-Logs\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eEs ist sicherer, dauerhafte \u003ccode\u003eask\u003c/code\u003e- und \u003ccode\u003edeny\u003c/code\u003e-Regeln festzulegen, als in der Konversation einmal „Nicht pushen“ zu sagen. Durch Context-Komprimierung oder einen Session-Wechsel können Regeln aus der Konversation an Wirkung verlieren.\u003c/p\u003e\n\u003cp\u003eEine Cloud Routine klont das Repository bei jeder Ausführung neu und arbeitet mit den verbundenen GitHub- und Connector-Berechtigungen. Folgende Bereiche müssen minimiert werden.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eZugängliche Repositorys und Branches\u003c/li\u003e\n\u003cli\u003eZulässige Network Domains\u003c/li\u003e\n\u003cli\u003eZu verwendende Connectoren\u003c/li\u003e\n\u003cli\u003eUmgebungsvariablen und Secrets\u003c/li\u003e\n\u003cli\u003eSchreibberechtigungen für externe Systeme\u003c/li\u003e\n\u003cli\u003eUmfang von PR-Erstellung, Push und Merge\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eDer Status „ordnungsgemäß beendet“ in der Ausführungsliste einer Routine kann lediglich bedeuten, dass die Session ohne Infrastructure-Fehler beendet wurde. Er garantiert nicht, dass das fachliche Ziel erfolgreich erreicht wurde. Transcript, Test evidence und der erzeugte Diff müssen separat geprüft werden.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#10-vorlage-zur-loop-gestaltung-f%C3%BCr-entwicklungsprojekte\" class=\"anchor\" id=\"10-vorlage-zur-loop-gestaltung-für-entwicklungsprojekte\"\u003e\u003c/a\u003e10. Vorlage zur Loop-Gestaltung für Entwicklungsprojekte\u003c/h2\u003e\n\u003cp\u003eDas folgende YAML ist keine tatsächliche Syntax von Claude Code, sondern ein Template für die Designprüfung.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003etrigger\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003etype\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003emanual | interval | schedule | github_event | api_event\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003escope\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erepositories\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etarget-repository\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallowed_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esrc/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etests/**\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eprohibited_paths\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eproduction/**\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003esecrets/**\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003etask\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eobjective\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eZu änderndes oder zu bearbeitendes Ziel\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003einput\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eNeu eingehendes Issue, Event, File oder neuer Zustand\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003everification\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ecommands\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eunit-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eintegration-test\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003elint\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebuild\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eruntime_checks\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ebrowser-interaction\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003econsole-errors\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eaccessibility\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eevidence\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003ecommand-output\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003eexit-code\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003etest-summary\n\u003c/span\u003e\u003cspan\u003e    - \u003c/span\u003e\u003cspan\u003escreenshots\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003esuccess\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003econdition\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eAbschlusszustand, der als wahr oder falsch bewertet werden kann\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003estop\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_turns\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e12\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_duration_minutes\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e45\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003emax_consecutive_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003e3\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003estop_on_permission_error\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eescalate_on_external_outage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eside_effects\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eidempotency_key\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eevent-id-or-commit-sha\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eallow_branch_push\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003eclaude/*\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_merge\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003erequire_human_for_deploy\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003ereview\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eindependent_agent\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003eadversarial_review\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e\n\u003c/span\u003e\u003cspan\u003eobservability\u003c/span\u003e\u003cspan\u003e:\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_progress\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_token_usage\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_changed_files\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003cspan\u003e  \u003c/span\u003e\u003cspan\u003ereport_remaining_failures\u003c/span\u003e\u003cspan\u003e: \u003c/span\u003e\u003cspan\u003etrue\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003cp\u003eWichtiger als die Formulierung des Prompt selbst sind die folgenden fünf Elemente.\u003c/p\u003e\n\u003cpre\u003e\u003ccode\u003e\u003cspan\u003eTrigger\n\u003c/span\u003e\u003cspan\u003eVerifier\n\u003c/span\u003e\u003cspan\u003eSuccess condition\n\u003c/span\u003e\u003cspan\u003eHard stop\n\u003c/span\u003e\u003cspan\u003ePermission boundary\n\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\n\u003ch2\u003e\n\u003ca href=\"#11-welcher-loop-sollte-gew%C3%A4hlt-werden\" class=\"anchor\" id=\"11-welcher-loop-sollte-gewählt-werden\"\u003e\u003c/a\u003e11. Welcher Loop sollte gewählt werden?\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eSituation\u003c/th\u003e\n\u003cth\u003eEmpfohlene Methode\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAufgabe, die mit einer einzelnen Änderung und Überprüfung endet\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003eTurn-based\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAufgabe, die mehrere Versuche erfordert, aber einen klaren Abschlusszustand hat\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003e\u003ccode\u003e/goal\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAufgabe, bei der kurz auf den Zustand von externer CI, PR oder Deployment gewartet werden muss\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003e\u003ccode\u003e/loop\u003c/code\u003e\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAufgabe, die auch bei geschlossenem Notebook wiederholt ausgeführt werden muss\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003e\n\u003ccode\u003e/schedule\u003c/code\u003e Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAufgabe, die sofort auf GitHub-Events oder Alerts reagieren muss\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003eEvent-triggered Routine\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eAufgabe, bei der Hunderte Elemente parallel verarbeitet und gegenseitig überprüft werden müssen\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003eDynamic Workflow\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Situation\"\u003eTransformation mit vollständig deterministischen Ein- und Ausgaberegeln\u003c/td\u003e\n\u003ctd data-label=\"Empfohlene Methode\"\u003eScript oder CI Job\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003cp\u003eDie Auswahl sollte sich nicht nach der „leistungsstärksten Funktion“, sondern nach der „einfachsten Kontrollstruktur, die das Ziel erreicht“ richten.\u003c/p\u003e\n\u003ch2\u003e\n\u003ca href=\"#12-sichere-einf%C3%BChrungsreihenfolge\" class=\"anchor\" id=\"12-sichere-einführungsreihenfolge\"\u003e\u003c/a\u003e12. Sichere Einführungsreihenfolge\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eEine Engpassaufgabe auswählen, die ein Mensch wiederholt kontrollieren muss.\u003c/li\u003e\n\u003cli\u003eZunächst den Überprüfungsprozess als Skill, Script oder CI umsetzen.\u003c/li\u003e\n\u003cli\u003eDie Qualität der Überprüfung im Turn-based-Verfahren stabilisieren.\u003c/li\u003e\n\u003cli\u003eWenn der Abschlusszustand eindeutig ist, \u003ccode\u003e/goal\u003c/code\u003e ergänzen.\u003c/li\u003e\n\u003cli\u003e\n\u003ccode\u003e/loop\u003c/code\u003e nur verwenden, wenn auf einen externen Zustand gewartet werden muss.\u003c/li\u003e\n\u003cli\u003eWenn eine langfristige Ausführung erforderlich ist, zu einer \u003ccode\u003e/schedule\u003c/code\u003e Routine wechseln.\u003c/li\u003e\n\u003cli\u003eErst nach Überprüfung von Idempotenz, Berechtigungen und Kosten auf Dynamic Workflow und Proactive Loop erweitern.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2\u003e\n\u003ca href=\"#13-h%C3%A4ufige-missverst%C3%A4ndnisse\" class=\"anchor\" id=\"13-häufige-missverständnisse\"\u003e\u003c/a\u003e13. Häufige Missverständnisse\u003c/h2\u003e\n\u003cdiv class=\"overflow-x-auto\"\u003e\u003ctable\u003e\n\u003cthead\u003e\n\u003ctr\u003e\n\u003cth\u003eMissverständnis\u003c/th\u003e\n\u003cth\u003eKorrekte Interpretation\u003c/th\u003e\n\u003c/tr\u003e\n\u003c/thead\u003e\n\u003ctbody\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Missverständnis\"\u003eEin Loop läuft unendlich\u003c/td\u003e\n\u003ctd data-label=\"Korrekte Interpretation\"\u003eEs handelt sich um eine begrenzte Wiederholungsstruktur mit Erfolgskriterien und Hard stop\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Missverständnis\"\u003eDie Abschlussmeldung eines Agent ist eine Überprüfung\u003c/td\u003e\n\u003ctd data-label=\"Korrekte Interpretation\"\u003eExterne Befehlsausgaben, Exit-Codes und Runtime-Ergebnisse sind erforderlich\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Missverständnis\"\u003e\n\u003ccode\u003e/goal\u003c/code\u003e erlaubt automatisch alle Berechtigungen\u003c/td\u003e\n\u003ctd data-label=\"Korrekte Interpretation\"\u003eEs startet nur automatisch den nächsten Turn; die Berechtigungsrichtlinie ist davon getrennt\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Missverständnis\"\u003e\n\u003ccode\u003e/loop\u003c/code\u003e ist ein langfristiger betrieblicher Scheduler\u003c/td\u003e\n\u003ctd data-label=\"Korrekte Interpretation\"\u003eEs ist Session-zentriert und unterliegt einer Ablaufzeit von 7 Tagen sowie Einschränkungen der Ausführungsumgebung\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Missverständnis\"\u003eMehr Agents führen zu besseren Ergebnissen\u003c/td\u003e\n\u003ctd data-label=\"Korrekte Interpretation\"\u003eParallelisierung ist nur wertvoll, wenn Rollen, Perspektiven und Überprüfungen unterschiedlich sind\u003c/td\u003e\n\u003c/tr\u003e\n\u003ctr\u003e\n\u003ctd data-label=\"Missverständnis\"\u003eAlle wiederkehrenden Aufgaben müssen von einem LLM ausgeführt werden\u003c/td\u003e\n\u003ctd data-label=\"Korrekte Interpretation\"\u003eDeterministische Teile sind mit einem Script günstiger und besser reproduzierbar\u003c/td\u003e\n\u003c/tr\u003e\n\u003c/tbody\u003e\n\u003c/table\u003e\u003c/div\u003e\n\u003ch2\u003e\n\u003ca href=\"#fazit\" class=\"anchor\" id=\"fazit\"\u003e\u003c/a\u003eFazit\u003c/h2\u003e\n\u003cp\u003eLoop Engineering ist keine Technik, um AI länger laufen zu lassen, sondern die \u003cstrong\u003eGestaltung eines Kontrollsystems, das dafür sorgt, dass AI eigene Fehler erkennt, sie innerhalb eines Kostenlimits korrigiert und an riskanten Stellen stoppt\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eLLM sind stark bei Exploration, Schlussfolgerung, Implementierung, Ausnahmeanalysen und dem Vergleich von Alternativen. Das System muss den Ausführungszeitpunkt, den Änderungsumfang, die Überprüfungsmethode, die Abbruchkriterien, das Kostenlimit und die Genehmigungsgrenzen verwalten. Je klarer diese Rollenverteilung ist, desto mehr entwickelt sich die Automatisierung mit Claude Code von einem einfachen Tool zur Codegenerierung zu einem reproduzierbaren und auditierbaren System für den Entwicklungsbetrieb.\u003c/p\u003e\n","tags":["Claude Code","Loop Engineering","AI Agent","Development Automation","Agent Workflow"],"faqs":[{"question":"Wie unterscheidet sich der Loop von Claude Code von gewöhnlichen for- und while-Schleifen?","answer":"Gewöhnliche Schleifen wiederholen die im Code definierten Anweisungen deterministisch. Der Loop von Claude Code ist eine Agenten-Kontrollstruktur, bei der der Agent den Code und den externen Zustand beobachtet, die nächste Aktion ableitet, Werkzeuge ausführt, die Ergebnisse überprüft und die Arbeit abhängig von der Abbruchbedingung erneut aufnimmt."},{"question":"Wann ist ein Turn-based Loop am besten geeignet?","answer":"Er eignet sich für kurze, einmalige Aufgaben, deren Ergebnisse der Benutzer sofort überprüfen kann. Wenn sich jedoch Prüfabläufe etwa für eine UI, API oder Datenbank wiederholen, empfiehlt es sich, diese Abläufe als Skill oder Script anzulegen, damit Claude sie selbst nach denselben Kriterien überprüfen kann."},{"question":"Prüft das Bewertungsmodell von `/goal` Dateien und Testergebnisse direkt?","answer":"Nein. Das Bewertungsmodell ruft keine Werkzeuge auf und liest Dateien nicht direkt, sondern beurteilt die Goal-Bedingungen und die aus dem Gespräch ersichtlichen Nachweise. Der ausführende Claude muss Testbefehle, Exit-Codes, geänderte Dateien und Fehlerursachen im Ergebnis eindeutig festhalten."},{"question":"Was sollte eine gute `/goal`-Bedingung enthalten?","answer":"Erforderlich sind ein messbarer Abschlusszustand, Befehle oder Werkzeuge zum Nachweis dieses Zustands, zulässige und verbotene Änderungsbereiche sowie Hard Stops wie eine maximale Anzahl an Turns, eine maximale Dauer oder eine maximale Anzahl aufeinanderfolgender Fehlschläge. Statt „sauber refaktorieren“ ist „Tests und lint enden mit Exit-Code 0 und es gibt keinen Diff außerhalb des angegebenen Pfads“ eine gute Bedingung."},{"question":"Gibt es bei `/goal` automatisch eine maximale Anzahl an Turns oder ein Zeitlimit?","answer":"Goal läuft weiter, bis das Bewertungsmodell den Erfolg feststellt oder der Benutzer es mit `/goal clear` abbricht. Um das Ausführungsbudget zu begrenzen, müssen Turn- und Zeitvorgaben wie „nach maximal 12 Turns oder 45 Minuten abbrechen“ direkt in die Goal-Bedingungen aufgenommen werden."},{"question":"Werden bei Verwendung von `/goal` auch Werkzeugberechtigungen automatisch erteilt?","answer":"Nein. `/goal` startet den nächsten Turn automatisch, doch die Berechtigungsrichtlinien für das Schreiben von Dateien, Shell, Git und externe Connectoren bleiben unverändert. Wenn eine unbeaufsichtigte Ausführung erforderlich ist, sollte der Auto mode erwogen werden; riskante Vorgänge müssen dabei jedoch separat durch `ask`- und `deny`-Regeln kontrolliert werden."},{"question":"Was ist der größte Unterschied zwischen `/loop` und `/schedule`?","answer":"`/loop` ist ein kurzfristiges Polling-Mittel, das wiederholt in der aktuellen Claude Code-Sitzung und auf dem aktuellen Computer ausgeführt wird. `/schedule` speichert Prompt, Repository, Connector und Trigger als Cloud Routine und führt sie auf der von Anthropic verwalteten Infrastruktur aus, sodass weder eine geöffnete Sitzung noch ein eingeschalteter Laptop erforderlich ist."},{"question":"Wird `/loop` weiter ausgeführt, wenn der Computer ausgeschaltet wird?","answer":"Im Allgemeinen nicht. `/loop` ist eine auf die Sitzung beschränkte Aufgabe, und Claude Code muss ausgeführt werden. Für langfristige Automatisierungen sollte ein dauerhaft verfügbarer Scheduler wie Cloud Routine, eine geplante Desktop-Aufgabe oder GitHub Actions verwendet werden."},{"question":"Warum ist ein Event Trigger besser als zeitbasiertes Polling?","answer":"Weil dadurch bei ausbleibenden Änderungen keine unnötigen Modellaufrufe entstehen und die Ausführung unmittelbar nach einer tatsächlichen Änderung erfolgen kann. Systeme, die Ereignisse wie CI-Fehler, PR-Aktualisierungen oder Alerts ausgeben können, lassen sich besser über einen GitHub Trigger oder eine Routine API anbinden, da dies sowohl bei den Kosten als auch bei der Latenz vorteilhaft ist."},{"question":"Warum sollte der Prüfablauf in `SKILL.md` statt in `CLAUDE.md` abgelegt werden?","answer":"`CLAUDE.md` eignet sich für kurze Regeln, die stets für das gesamte Projekt gelten, während ein Skill geeignet ist, um nur für bestimmte Aufgaben erforderliche Abläufe und unterstützende Dateien zusammenzufassen. Wird eine lange Prüfcheckliste in einen Skill ausgelagert, kann sie nur bei relevanten Aufgaben geladen und direkt erneut ausgeführt werden."},{"question":"Wie unterscheidet sich ein Dynamic Workflow von einem gewöhnlichen Subagent-Aufruf?","answer":"Beim gewöhnlichen Subagent-Ansatz wählt Claude in jedem Turn den nächsten Bearbeiter aus, und die Ergebnisse sammeln sich im Context an. Bei einem Dynamic Workflow verwaltet ein JavaScript Script die parallele Ausführung, Verzweigungen, Wiederholungen und Zwischenergebnisse, sodass sich umfangreiche Migrationen, Audits und Kreuzprüfungen reproduzierbarer organisieren lassen."},{"question":"Verbessert der Einsatz mehrerer Agenten immer die Qualität?","answer":"Nein. Wenn sich Rollen und Perspektiven überschneiden, können dieselben Fehler wiederholt werden, während lediglich die Kosten steigen. Der Wert paralleler Agenten entsteht erst, wenn die Verantwortlichkeiten etwa in Implementierung, Testkonzeption, Sicherheitsprüfung, Regressionsanalyse und Judge aufgeteilt und für jede Schlussfolgerung unabhängige Nachweise verlangt werden."},{"question":"Wie lassen sich doppelte Arbeiten in einem Time-based oder Proactive Loop verhindern?","answer":"Idempotency Keys wie Event ID, Commit SHA und Review Comment ID sowie der letzte Verarbeitungsstatus müssen gespeichert werden. In die Prüfphase muss eine Regel aufgenommen werden, die verhindert, dass bereits beantwortete Nachrichten, bereits erstellte PRs und bereits verarbeitete Commits erneut verarbeitet werden."},{"question":"Welche Aufgabe eignet sich für den ersten zu automatisierenden Loop?","answer":"Geeignet sind Aufgaben, die von Menschen wiederholt überprüft werden, aber nur wenige riskante Side Effects haben und deren Abschlussstatus sich eindeutig messen lässt. Sicher ist es beispielsweise, zunächst die Ursachen fehlgeschlagener CI in PRs zusammenzufassen, Abweichungen zwischen Dokumentation und Code zu erkennen und festgelegte Tests und lint-Prüfungen durchzuführen und anschließend die Berechtigungen zum Ändern und Pushen schrittweise zu erweitern."}],"sources":[{"url":"https://claude.com/blog/getting-started-with-loops","title":"Loop-Engineering: Erste Schritte mit Schleifen | Claude von Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/skills","title":"Claude mit Skills erweitern – Claude Code-Dokumentation","type":"source"},{"url":"https://code.claude.com/docs/en/goal","title":"Claude kontinuierlich auf ein Ziel hinarbeiten lassen – Claude Code-Dokumentation","type":"source"},{"url":"https://code.claude.com/docs/en/scheduled-tasks","title":"Prompts nach einem Zeitplan ausführen – Claude Code-Dokumentation","type":"source"},{"url":"https://code.claude.com/docs/en/routines","title":"Arbeit mit Routinen automatisieren – Claude Code-Dokumentation","type":"source"},{"url":"https://code.claude.com/docs/en/workflows","title":"Subagenten in großem Maßstab mit dynamischen Workflows orchestrieren – Claude Code-Dokumentation","type":"source"},{"url":"https://claude.com/blog/claude-model-and-effort-level-in-claude-code","title":"Auswahl eines Claude-Modells und einer Aufwandsstufe in Claude Code | Claude von Anthropic","type":"source"},{"url":"https://code.claude.com/docs/en/auto-mode-config","title":"Automatikmodus konfigurieren – Claude Code-Dokumentation","type":"source"}],"images":[{"id":195,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTg3OSwicHVyIjoiYmxvYl9pZCJ9fQ==--cac49ec584371c2261bd3272e7574ca38ecc1f85/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2006_56_28.webp","is_representative":true,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 06_56_28.png","translations":{"ko":{"alt":"AI 로봇과 코드 화면을 중심으로 반복 화살표, 목표·시간·보안·비용 아이콘이 연결된 자동화 구조","caption":"관찰·실행·검증을 반복하는 AI 에이전트와 목표, 일정, 권한, 강제 종료, 비용 제어 요소를 함께 보여준다.","description":null},"en":{"alt":"AI robot and code dashboard surrounded by loop arrows, goal, schedule, security, and cost control icons","caption":"The illustration shows an AI agent repeating observation, action, and verification within goal, timing, permission, stop, and cost controls.","description":null},"ja":{"alt":"AIロボットとコード画面を中心に、循環矢印、目標、時間、安全、コスト管理のアイコンが連結された構成","caption":"観察・実行・検証を繰り返すAIエージェントを、目標、実行時期、権限、停止、コストの制御要素とともに示している。","description":null},"es":{"alt":"Robot de IA y panel de código rodeados por flechas de ciclo e iconos de objetivo, tiempo, seguridad y coste","caption":"La ilustración muestra un agente de IA que repite observación, acción y verificación bajo controles de objetivo, tiempo, permisos, parada y coste.","description":null},"id":{"alt":"Robot AI dan dasbor kode dikelilingi panah loop serta ikon tujuan, waktu, keamanan, dan biaya","caption":"Ilustrasi menampilkan agen AI yang mengulang observasi, tindakan, dan verifikasi dengan kontrol tujuan, waktu, izin, penghentian, dan biaya.","description":null},"pt":{"alt":"Robô de IA e painel de código cercados por setas de ciclo e ícones de meta, tempo, segurança e custo","caption":"A ilustração mostra um agente de IA repetindo observação, ação e verificação sob controles de objetivo, tempo, permissão, parada e custo.","description":null},"zh-hant":{"alt":"AI 機器人與程式碼面板置於循環箭頭中央，周圍連結目標、時間、安全與成本控制圖示","caption":"圖中呈現 AI 代理在目標、排程、權限、強制停止與成本控制下反覆觀察、執行與驗證。","description":null},"de":{"alt":"Automatisierungsstruktur mit einem AI-Roboter und einer Codeanzeige im Zentrum, verbunden mit Wiederholungspfeilen sowie Symbolen für Ziel, Zeit, Sicherheit und Kosten","caption":"Zeigt einen AI-Agenten, der Beobachtung, Ausführung und Validierung wiederholt, zusammen mit Elementen für Ziel, Zeitplan, Berechtigungen, erzwungenen Abbruch und Kostenkontrolle.","description":null}}},{"id":196,"url":"https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTg4NiwicHVyIjoiYmxvYl9pZCJ9fQ==--e5ead4b7a604375b9c6a192eb3a981cf4c93b3c9/ChatGPT%20Image%202026%E1%84%82%E1%85%A7%E1%86%AB%207%E1%84%8B%E1%85%AF%E1%86%AF%2016%E1%84%8B%E1%85%B5%E1%86%AF%20%E1%84%8B%E1%85%A9%E1%84%92%E1%85%AE%2007_02_56.webp","is_representative":false,"generation_method":"upload","mime_type":"image/webp","original_filename":"ChatGPT Image 2026년 7월 16일 오후 07_02_56.png","translations":{"ko":{"alt":"보호 울타리 안의 AI 에이전트가 검증, 중단 장치, 권한 게이트와 비용 계측을 거쳐 작업하는 자동화 구조","caption":"트리거부터 검증과 강제 중단, 자원 관리, 승인된 결과 출력까지 안전하게 통제되는 에이전트 워크플로를 보여준다.","description":null},"en":{"alt":"AI agent inside a guarded workspace with verification, stop controls, permission gates, and resource monitoring","caption":"The illustration shows an agent workflow controlled from triggers through validation, hard stops, resource checks, and approved output.","description":null},"ja":{"alt":"検証、強制停止、権限ゲート、資源監視に囲まれた保護領域内のAIエージェント","caption":"トリガーから検証、停止制御、コスト管理、承認済み出力まで安全に統制されたエージェント処理を表している。","description":null},"es":{"alt":"Agente de IA en un entorno protegido con verificación, parada forzada, permisos y control de recursos","caption":"La ilustración muestra un flujo de agente controlado desde los disparadores hasta la validación, los límites y la salida aprobada.","description":null},"id":{"alt":"Agen AI dalam area terlindungi dengan verifikasi, penghentian paksa, gerbang izin, dan pemantauan sumber daya","caption":"Ilustrasi ini menunjukkan alur agen yang dikendalikan dari pemicu hingga validasi, batas aman, pemantauan biaya, dan keluaran yang disetujui.","description":null},"pt":{"alt":"Agente de IA em área protegida com verificação, parada forçada, controle de permissões e monitoramento de recursos","caption":"A ilustração mostra um fluxo de agente controlado desde os gatilhos até a validação, os limites de segurança e a saída aprovada.","description":null},"zh-hant":{"alt":"受保護工作區中的AI代理，周圍設有驗證、強制停止、權限閘門與資源監控","caption":"圖中呈現從觸發、驗證、停止控制與成本監測，到核准輸出的安全代理工作流程。","description":null},"de":{"alt":"Automatisierungsstruktur, in der ein AI-Agent innerhalb von Schutzvorkehrungen Aufgaben über Validierung, Abbruchmechanismus, Berechtigungsschranke und Kostenmessung ausführt","caption":"Zeigt einen sicher kontrollierten Agenten-Workflow vom Auslöser über Validierung, erzwungenen Abbruch, Ressourcenverwaltung und die Ausgabe genehmigter Ergebnisse.","description":null}}}],"published_at":"2026-07-17T09:40:17+09:00","updated_at":"2026-07-17T09:40:17+09:00","license":"cc_by","translation_status":"reviewed","available_locales":["ko","en","ja","es"],"data_locales":["ko","en","ja","es","id","pt","zh-hant","de"],"url":"https://injoys.com/en/articles/claude-code-loop-engineering-guide"}