cc-viewer 1.6.182 → 1.6.183

package/concepts/de/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+Listet alle Cron-Jobs auf, die in der aktuellen Sitzung via `CronCreate` geplant wurden. Gibt eine Zusammenfassung jedes aktiven Cron-Jobs zurück, einschliesslich `id`, Cron-Ausdruck, gekürztem `prompt`, `recurring`-Flag, `durable`-Flag und nächstem Ausführungszeitpunkt.
+
+## Wann verwenden
+
+- Um alle aktuell geplanten Jobs zu prüfen, bevor Änderungen vorgenommen oder die Sitzung beendet wird.
+- Um die korrekte `id` eines Jobs zu finden, bevor `CronDelete` aufgerufen wird.
+- Um zu debuggen, warum ein erwarteter Job nie ausgelöst wurde, indem seine Existenz und der nächste Ausführungszeitpunkt überprüft werden.
+- Um zu bestätigen, dass ein einmaliger (nicht wiederkehrender) Job noch nicht ausgelöst wurde und noch aussteht.
+
+## Parameter
+
+Keine.
+
+## Beispiele
+
+### Beispiel 1: Alle geplanten Jobs prüfen
+
+`CronList` ohne Argumente aufrufen, um die vollständige Liste aller aktiven Cron-Jobs abzurufen. Die Antwort enthält für jeden Job die `id`, den Cron-Ausdruck, eine gekürzte Version des `prompt`, ob er `recurring` (wiederkehrend) ist, ob er `durable` (persistent) ist und den nächsten geplanten Ausführungszeitpunkt.
+
+### Beispiel 2: Die id eines bestimmten wiederkehrenden Tasks finden
+
+Wenn mehrere Cron-Jobs erstellt wurden und einer davon gelöscht werden soll, zuerst `CronList` aufrufen. In der zurückgegebenen Liste nach dem Job suchen, dessen `prompt`-Zusammenfassung und Cron-Ausdruck zum Ziel-Task passen. Die `id` kopieren und an `CronDelete` übergeben.
+
+## Hinweise
+
+- Es werden nur Jobs der aktuellen Sitzung aufgelistet, es sei denn, sie wurden mit `durable: true` erstellt, wodurch sie Sitzungs-Neustarts überstehen.
+- Das `prompt`-Feld in der Zusammenfassung ist gekürzt; es zeigt nur den Anfang des vollständigen Prompttexts, nicht den gesamten Inhalt.
+- Einmalige Jobs (`recurring` ist `false`), die bereits ausgelöst wurden, werden automatisch gelöscht und erscheinen nicht mehr in der Liste.

package/concepts/de/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## Definition
+Führt eine exakte String-Ersetzung in einer vorhandenen Datei durch. Dies ist der bevorzugte Weg zur Änderung von Dateien, da nur das Diff übertragen wird, was Edits präzise und nachvollziehbar hält.
 
-Bearbeitet Dateien durch exakte Zeichenkettenersetzung. Ersetzt `old_string` in der Datei durch `new_string`.
+## Wann verwenden
 
-## Parameter
+- Beheben eines Fehlers in einer einzelnen Funktion, ohne die umgebende Datei neu zu schreiben
+- Aktualisieren eines Konfigurationswerts, Versionsstrings oder Import-Pfads
+- Umbenennen eines Symbols innerhalb einer Datei mit `replace_all`
+- Einfügen eines Blocks neben einem Anker (`old_string` erweitern, um umgebenden Kontext einzuschließen, und dann den Ersatztext angeben)
+- Anwenden kleiner, klar abgegrenzter Edits im Rahmen eines mehrstufigen Refactorings
 
-| Parameter | Typ | Erforderlich | Beschreibung |
-|-----------|-----|--------------|--------------|
-| `file_path` | string | Ja | Absoluter Pfad der zu ändernden Datei |
-| `old_string` | string | Ja | Der zu ersetzende Originaltext |
-| `new_string` | string | Ja | Der neue Ersetzungstext (muss sich von old_string unterscheiden) |
-| `replace_all` | boolean | Nein | Ob alle Vorkommen ersetzt werden sollen, Standard `false` |
+## Parameter
 
-## Anwendungsfälle
+- `file_path` (string, erforderlich): Absoluter Pfad der zu ändernden Datei.
+- `old_string` (string, erforderlich): Der exakte zu suchende Text. Muss zeichengenau übereinstimmen, einschließlich Leerraum und Einrückung.
+- `new_string` (string, erforderlich): Der Ersatztext. Muss sich von `old_string` unterscheiden.
+- `replace_all` (boolean, optional): Bei `true` wird jedes Vorkommen von `old_string` ersetzt. Standard ist `false`, was eine eindeutige Trefferstelle erfordert.
 
-**Geeignet für:**
-- Ändern bestimmter Codeabschnitte in vorhandenen Dateien
-- Bugfixes, Logik-Updates
-- Variablen umbenennen (mit `replace_all: true`)
-- Jedes Szenario, das präzise Dateiänderungen erfordert
+## Beispiele
 
-**Nicht geeignet für:**
-- Neue Dateien erstellen – dafür Write verwenden
-- Umfangreiche Neuschreibungen – möglicherweise Write zum Überschreiben der gesamten Datei erforderlich
+### Beispiel 1: Einen einzelnen Aufrufort korrigieren
+`old_string` auf die exakte Zeile `const port = 3000;` und `new_string` auf `const port = process.env.PORT ?? 3000;` setzen. Da der Treffer eindeutig ist, kann `replace_all` beim Standardwert bleiben.
 
-## Hinweise
+### Beispiel 2: Ein Symbol innerhalb einer Datei umbenennen
+Um `getUser` in `api.ts` überall in `fetchUser` umzubenennen, `old_string: "getUser"`, `new_string: "fetchUser"` und `replace_all: true` setzen.
 
-- Vor der Verwendung muss die Datei über Read gelesen worden sein, sonst tritt ein Fehler auf
-- `old_string` muss in der Datei eindeutig sein, sonst schlägt die Bearbeitung fehl. Bei Nicht-Eindeutigkeit mehr Kontext angeben oder `replace_all` verwenden
-- Beim Bearbeiten von Text muss die ursprüngliche Einrückung (Tab/Leerzeichen) beibehalten werden; das Zeilennummernpräfix der Read-Ausgabe nicht einschließen
-- Vorhandene Dateien bearbeiten hat Vorrang vor dem Erstellen neuer Dateien
-- `new_string` muss sich von `old_string` unterscheiden
+### Beispiel 3: Ein mehrfach vorkommendes Snippet eindeutig machen
+Falls `return null;` in mehreren Branches auftaucht, `old_string` um umgebenden Kontext erweitern (zum Beispiel die vorhergehende `if`-Zeile), damit der Treffer eindeutig ist. Andernfalls schlägt das Tool fehl, statt zu raten.
 
-## Originaltext
-
-<textarea readonly>Performs exact string replacements in files.
+## Hinweise
 
-Usage:
-- You must use your `Read` tool at least once in the conversation before editing. This tool will error if you attempt an edit without reading the file. 
-- When editing text from Read tool output, ensure you preserve the exact indentation (tabs/spaces) as it appears AFTER the line number prefix. The line number prefix format is: spaces + line number + tab. Everything after that tab is the actual file content to match. Never include any part of the line number prefix in the old_string or new_string.
-- ALWAYS prefer editing existing files in the codebase. NEVER write new files unless explicitly required.
-- Only use emojis if the user explicitly requests it. Avoid adding emojis to files unless asked.
-- The edit will FAIL if `old_string` is not unique in the file. Either provide a larger string with more surrounding context to make it unique or use `replace_all` to change every instance of `old_string`.
-- Use `replace_all` for replacing and renaming strings across the file. This parameter is useful if you want to rename a variable for instance.</textarea>
+- Sie müssen `Read` für die Datei in der aktuellen Sitzung mindestens einmal aufgerufen haben, bevor `Edit` Änderungen akzeptiert. Die Zeilennummern-Präfixe aus der `Read`-Ausgabe sind nicht Teil des Dateiinhalts; schließen Sie sie nicht in `old_string` oder `new_string` ein.
+- Leerraum muss exakt übereinstimmen. Achten Sie auf Tabs versus Leerzeichen und nachgestellte Leerzeichen, besonders in YAML, Makefiles und Python.
+- Wenn `old_string` nicht eindeutig ist und `replace_all` auf `false` steht, schlägt das Edit fehl. Entweder den Kontext erweitern oder `replace_all` aktivieren.
+- Bevorzugen Sie `Edit` gegenüber `Write`, wenn die Datei bereits existiert; `Write` überschreibt die gesamte Datei und verliert unbeteiligten Inhalt, wenn nicht sorgfältig vorgegangen wird.
+- Für mehrere voneinander unabhängige Edits in derselben Datei mehrere `Edit`-Aufrufe nacheinander absetzen, statt einer großen, fragilen Ersetzung.
+- Vermeiden Sie das Einführen von Emojis, Marketing-Texten oder unerwünschten Dokumentationsblöcken beim Bearbeiten von Quelldateien.

package/concepts/de/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## Definition
+Versetzt die Sitzung in den Planmodus, eine Nur-Lese-Explorationsphase, in der der Assistent den Codebase untersucht und einen konkreten Implementierungsplan entwirft, den der Benutzer freigeben muss, bevor Dateien geändert werden.
 
-Schaltet Claude Code in den Planungsmodus um, um vor der Implementierung die Codebasis zu erkunden und einen Plan zu entwerfen.
+## Wann verwenden
+
+- Der Benutzer fordert eine nicht triviale Änderung, die mehrere Dateien oder Subsysteme umfasst.
+- Die Anforderungen sind mehrdeutig und der Assistent muss Code lesen, bevor er sich auf einen Ansatz festlegt.
+- Ein Refactoring, eine Migration oder ein Abhängigkeits-Upgrade wird vorgeschlagen und der Wirkungsradius ist unklar.
+- Der Benutzer sagt ausdrücklich "plan dies", "lass uns erst planen" oder bittet um eine Design-Review.
+- Das Risiko ist hoch genug, dass ein direktes Bearbeiten Arbeit verschwenden oder den Zustand beschädigen könnte.
 
 ## Parameter
 
-Keine Parameter.
+Keine. `EnterPlanMode` nimmt keine Argumente entgegen – rufen Sie es mit einem leeren Parameterobjekt auf.
 
-## Anwendungsfälle
+## Beispiele
 
-**Geeignet für:**
-- Neue Feature-Implementierung – erfordert Architekturentscheidungen
-- Mehrere mögliche Ansätze – Benutzerauswahl erforderlich
-- Codeänderungen beeinflussen bestehendes Verhalten oder Struktur
-- Änderungen an mehreren Dateien – möglicherweise 2–3 oder mehr Dateien betroffen
-- Unklare Anforderungen – erst erkunden, dann Umfang verstehen
-- Benutzerpräferenzen sind wichtig – die Implementierung kann mehrere sinnvolle Richtungen haben
+### Beispiel 1: Große Feature-Anfrage
 
-**Nicht geeignet für:**
-- Einzeilige oder wenige Zeilen umfassende Korrekturen (Tippfehler, offensichtliche Bugs)
-- Der Benutzer hat sehr spezifische Anweisungen gegeben
-- Reine Recherche-/Erkundungsaufgaben – dafür Task (Explore-Typ) verwenden
+Der Benutzer fragt: "SSO über Okta zum Admin-Panel hinzufügen." Der Assistent ruft `EnterPlanMode` auf und verbringt dann mehrere Turns mit dem Lesen von Auth-Middleware, Session-Speicher, Route-Guards und der bestehenden Login-UI. Er schreibt einen Plan, der die erforderlichen Änderungen, Migrationsschritte und Testabdeckung beschreibt, und reicht ihn über `ExitPlanMode` zur Freigabe ein.
 
-## Verhalten im Planungsmodus
+### Beispiel 2: Riskantes Refactoring
 
-Nach dem Eintritt in den Planungsmodus wird Claude Code:
-1. Mit Glob, Grep, Read Tools die Codebasis eingehend erkunden
-2. Bestehende Muster und Architektur verstehen
-3. Einen Implementierungsplan entwerfen
-4. Den Plan dem Benutzer zur Genehmigung vorlegen
-5. Bei Bedarf AskUserQuestion zur Klärung verwenden
-6. Nach Fertigstellung des Plans über ExitPlanMode den Modus verlassen
+Der Benutzer sagt: "Konvertiere die REST-Controller zu tRPC." Der Assistent betritt den Planmodus, untersucht jeden Controller, katalogisiert den öffentlichen Vertrag, listet Rollout-Phasen (Shim, Dual-Read, Cutover) auf und schlägt einen Sequenzplan vor, bevor irgendeine Datei angefasst wird.
 
 ## Hinweise
 
-- Dieses Tool erfordert die Zustimmung des Benutzers zum Eintritt in den Planungsmodus
-- Im Zweifelsfall lieber planen – frühzeitige Abstimmung ist besser als Nacharbeit
-
-## Originaltext
-
-<textarea readonly>Use this tool proactively when you're about to start a non-trivial implementation task. Getting user sign-off on your approach before writing code prevents wasted effort and ensures alignment. This tool transitions you into plan mode where you can explore the codebase and design an implementation approach for user approval.
-
-## When to Use This Tool
-
-**Prefer using EnterPlanMode** for implementation tasks unless they're simple. Use it when ANY of these conditions apply:
-
-1. **New Feature Implementation**: Adding meaningful new functionality
-   - Example: "Add a logout button" - where should it go? What should happen on click?
-   - Example: "Add form validation" - what rules? What error messages?
-
-2. **Multiple Valid Approaches**: The task can be solved in several different ways
-   - Example: "Add caching to the API" - could use Redis, in-memory, file-based, etc.
-   - Example: "Improve performance" - many optimization strategies possible
-
-3. **Code Modifications**: Changes that affect existing behavior or structure
-   - Example: "Update the login flow" - what exactly should change?
-   - Example: "Refactor this component" - what's the target architecture?
-
-4. **Architectural Decisions**: The task requires choosing between patterns or technologies
-   - Example: "Add real-time updates" - WebSockets vs SSE vs polling
-   - Example: "Implement state management" - Redux vs Context vs custom solution
-
-5. **Multi-File Changes**: The task will likely touch more than 2-3 files
-   - Example: "Refactor the authentication system"
-   - Example: "Add a new API endpoint with tests"
-
-6. **Unclear Requirements**: You need to explore before understanding the full scope
-   - Example: "Make the app faster" - need to profile and identify bottlenecks
-   - Example: "Fix the bug in checkout" - need to investigate root cause
-
-7. **User Preferences Matter**: The implementation could reasonably go multiple ways
-   - If you would use AskUserQuestion to clarify the approach, use EnterPlanMode instead
-   - Plan mode lets you explore first, then present options with context
-
-## When NOT to Use This Tool
-
-Only skip EnterPlanMode for simple tasks:
-- Single-line or few-line fixes (typos, obvious bugs, small tweaks)
-- Adding a single function with clear requirements
-- Tasks where the user has given very specific, detailed instructions
-- Pure research/exploration tasks (use the Agent tool with explore agent instead)
-
-## What Happens in Plan Mode
-
-In plan mode, you'll:
-1. Thoroughly explore the codebase using Glob, Grep, and Read tools
-2. Understand existing patterns and architecture
-3. Design an implementation approach
-4. Present your plan to the user for approval
-5. Use AskUserQuestion if you need to clarify approaches
-6. Exit plan mode with ExitPlanMode when ready to implement
-
-## Examples
-
-### GOOD - Use EnterPlanMode:
-User: "Add user authentication to the app"
-- Requires architectural decisions (session vs JWT, where to store tokens, middleware structure)
-
-User: "Optimize the database queries"
-- Multiple approaches possible, need to profile first, significant impact
-
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
-
-User: "Add a delete button to the user profile"
-- Seems simple but involves: where to place it, confirmation dialog, API call, error handling, state updates
-
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
-
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
-
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
-
-User: "What files handle routing?"
-- Research task, not implementation planning
-
-## Important Notes
-
-- This tool REQUIRES user approval - they must consent to entering plan mode
-- If unsure whether to use it, err on the side of planning - it's better to get alignment upfront than to redo work
-- Users appreciate being consulted before significant changes are made to their codebase
-</textarea>
+- Der Planmodus ist vertraglich schreibgeschützt. Während er aktiv ist, darf der Assistent weder `Edit`, `Write`, `NotebookEdit` noch irgendeinen verändernden Shell-Befehl ausführen. Nur `Read`, `Grep`, `Glob` und nicht-destruktive `Bash`-Befehle verwenden.
+- Planmodus nicht für triviale Einzeiler-Edits, reine Recherchefragen oder Aufgaben einsetzen, bei denen der Benutzer die Änderung bereits vollständig detailliert hat. Der Overhead schadet dort mehr, als er nützt.
+- Im Auto-Modus wird der Planmodus abgeraten, sofern der Benutzer ihn nicht ausdrücklich anfordert – Auto-Modus bevorzugt Aktion vor vorgelagerter Planung.
+- Planmodus einsetzen, um Kurskorrekturen bei aufwendiger Arbeit zu reduzieren. Ein fünfminütiger Plan spart oft eine Stunde fehlgeleiteter Edits.
+- Einmal im Planmodus die Untersuchung auf die Teile des Systems fokussieren, die sich tatsächlich ändern werden. Erschöpfende Rundgänge durch das Repository vermeiden, die mit der aktuellen Aufgabe nichts zu tun haben.
+- Der Plan selbst muss an dem vom Harness erwarteten Pfad auf die Festplatte geschrieben werden, damit `ExitPlanMode` ihn einreichen kann. Der Plan muss konkrete Dateipfade, Funktionsnamen und Verifikationsschritte enthalten, nicht vage Absichten.
+- Der Benutzer kann den Plan ablehnen und Überarbeitungen anfordern. Im Planmodus iterieren, bis der Plan akzeptiert wird; erst dann verlassen.

package/concepts/de/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## Definition
+Erstellt einen isolierten Git-Worktree auf einem neuen Branch oder wechselt die Sitzung in einen bestehenden Worktree des aktuellen Repositorys, sodass parallele oder experimentelle Arbeit fortschreiten kann, ohne den primären Checkout zu berühren.
 
-Creates an isolated git worktree and switches the current session into it. Only used when the user explicitly asks to work in a worktree.
+## Wann verwenden
 
-## Parameter
-
-| Name | Type | Required | Description |
-|---|---|---|---|
-| name | string | No | A name for the worktree. If not provided, a random name is generated. |
-
-## Anwendungsfälle
+- Der Benutzer sagt ausdrücklich "worktree" – zum Beispiel "einen worktree starten", "einen worktree erstellen" oder "in einem worktree arbeiten".
+- Projektanweisungen in `CLAUDE.md` oder persistenter Speicher weisen Sie an, einen Worktree für die aktuelle Aufgabe zu verwenden.
+- Sie möchten eine Aufgabe fortsetzen, die zuvor als Worktree eingerichtet wurde (`path` übergeben, um erneut einzutreten).
+- Mehrere experimentelle Branches müssen auf der Festplatte koexistieren, ohne ständiges Checkout-Hin-und-Her.
+- Eine langlaufende Aufgabe soll von unbeteiligten Edits im Haupt-Working-Tree isoliert werden.
 
-**Geeignet für:**
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree")
-
-**Nicht geeignet für:**
-- The user asks to create/switch branches — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-
-## Hinweise
-
-- Must be in a git repository, or have WorktreeCreate/WorktreeRemove hooks configured
-- Must not already be in a worktree
-
-## Originaltext
-
-<textarea readonly>Use this tool ONLY when the user explicitly asks to work in a worktree. This tool creates an isolated git worktree and switches the current session into it.
+## Parameter
 
-## When to Use
+- `name` (string, optional): Ein Name für ein neues Worktree-Verzeichnis. Jedes durch `/` getrennte Segment darf nur Buchstaben, Ziffern, Punkte, Unterstriche und Bindestriche enthalten; die gesamte Zeichenkette ist auf 64 Zeichen begrenzt. Wenn weder angegeben noch `path` gesetzt ist, wird ein zufälliger Name generiert. Schließt `path` aus.
+- `path` (string, optional): Der Dateisystempfad eines bestehenden Worktrees des aktuellen Repositorys, in den gewechselt werden soll. Muss in `git worktree list` für dieses Repo auftauchen; Pfade, die keine registrierten Worktrees des aktuellen Repos sind, werden abgelehnt. Schließt `name` aus.
 
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree")
+## Beispiele
 
-## When NOT to Use
+### Beispiel 1: Neuen Worktree mit beschreibendem Namen erstellen
 
-- The user asks to create a branch, switch branches, or work on a different branch — use git commands instead
-- The user asks to fix a bug or work on a feature — use normal git workflow unless they specifically mention worktrees
-- Never use this tool unless the user explicitly mentions "worktree"
+```
+EnterWorktree(name="feat/okta-sso")
+```
 
-## Requirements
+Erstellt `.claude/worktrees/feat/okta-sso` auf einem neuen Branch basierend auf `HEAD` und wechselt dann das Arbeitsverzeichnis der Sitzung hinein. Alle nachfolgenden Datei-Edits und Shell-Befehle operieren innerhalb dieses Worktrees, bis Sie ihn verlassen.
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### Beispiel 2: In einen bestehenden Worktree zurückkehren
 
-## Behavior
+```
+EnterWorktree(path="/Users/me/repo/.claude/worktrees/feat/okta-sso")
+```
 
-- In a git repository: creates a new git worktree inside `.claude/worktrees/` with a new branch based on HEAD
-- Outside a git repository: delegates to WorktreeCreate/WorktreeRemove hooks for VCS-agnostic isolation
-- Switches the session's working directory to the new worktree
-- On session exit, the user will be prompted to keep or remove the worktree
+Setzt die Arbeit in einem zuvor erstellten Worktree fort. Da Sie ihn über `path` betreten haben, löscht `ExitWorktree` ihn nicht automatisch – das Verlassen mit `action: "keep"` kehrt einfach zum ursprünglichen Verzeichnis zurück.
 
-## Parameters
+## Hinweise
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- Rufen Sie `EnterWorktree` nicht auf, sofern der Benutzer es nicht ausdrücklich verlangt hat oder Projektanweisungen es vorschreiben. Gewöhnliche Branch-Wechsel oder Bugfix-Anfragen sollten normale Git-Befehle verwenden, keine Worktrees.
+- Innerhalb eines Git-Repositorys aufgerufen, legt das Tool einen Worktree unter `.claude/worktrees/` an und registriert einen neuen Branch basierend auf `HEAD`. Außerhalb eines Git-Repositorys delegiert es an konfigurierte `WorktreeCreate` / `WorktreeRemove` Hooks in `settings.json` für VCS-agnostische Isolation.
+- Nur eine Worktree-Sitzung ist gleichzeitig aktiv. Das Tool verweigert die Ausführung, wenn Sie sich bereits in einer Worktree-Sitzung befinden; beenden Sie zuerst mit `ExitWorktree`.
+- Verwenden Sie `ExitWorktree`, um mitten in der Sitzung zu verlassen. Wenn die Sitzung endet, während Sie sich noch in einem neu erstellten Worktree befinden, wird der Benutzer aufgefordert, ihn zu behalten oder zu entfernen.
+- Über `path` betretene Worktrees gelten als extern – `ExitWorktree` mit `action: "remove"` löscht diese nicht. Das ist eine Sicherheitsschiene zum Schutz von Worktrees, die der Benutzer manuell verwaltet.
+- Ein neuer Worktree erbt den Inhalt des aktuellen Branches, hat aber ein eigenständiges Arbeitsverzeichnis und einen eigenen Index. Staged und unstaged Änderungen im Haupt-Checkout sind innerhalb des Worktrees nicht sichtbar.
+- Namenstipp: Mit der Art der Arbeit als Präfix (`feat/`, `fix/`, `spike/`) versehen, damit sich mehrere gleichzeitige Worktrees in `git worktree list` gut unterscheiden lassen.

package/concepts/de/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## Definition
+Reicht den während des Planmodus entworfenen Implementierungsplan zur Genehmigung durch den Benutzer ein und führt die Sitzung – bei Genehmigung – aus dem Planmodus heraus, sodass Edits beginnen können.
 
-Verlässt den Planungsmodus und reicht den Plan zur Benutzerfreigabe ein. Der Planinhalt wird aus der zuvor geschriebenen Plandatei gelesen.
+## Wann verwenden
 
-## Parameter
-
-| Parameter | Typ | Erforderlich | Beschreibung |
-|-----------|-----|--------------|--------------|
-| `allowedPrompts` | array | Nein | Liste der für die Planumsetzung benötigten Berechtigungsbeschreibungen |
-
-Jedes Element im `allowedPrompts`-Array:
-
-| Feld | Typ | Erforderlich | Beschreibung |
-|------|-----|--------------|--------------|
-| `tool` | enum | Ja | Das zutreffende Tool, derzeit nur `Bash` unterstützt |
-| `prompt` | string | Ja | Semantische Beschreibung der Operation (z.B. "run tests", "install dependencies") |
-
-## Anwendungsfälle
+- Ein während `EnterPlanMode` geschriebener Plan ist fertig und bereit zur Überprüfung.
+- Die Aufgabe ist umsetzungsorientiert (Code- oder Konfigurationsänderungen), keine reine Recherche, sodass ein expliziter Plan angebracht ist.
+- Alle vorbereitende Lektüre und Analyse sind erledigt; vor der Benutzerentscheidung ist keine weitere Untersuchung nötig.
+- Der Assistent hat konkrete Dateipfade, Funktionen und Schritte aufgezählt – nicht nur Ziele.
+- Der Benutzer hat um den Plan gebeten, oder der Planmodus-Workflow ist kurz davor, an Edit-Tools zu übergeben.
 
-**Geeignet für:**
-- Der Plan im Planungsmodus ist fertig und bereit zur Benutzerfreigabe
-- Nur für Implementierungsaufgaben, die Code schreiben erfordern
-
-**Nicht geeignet für:**
-- Reine Recherche-/Erkundungsaufgaben – kein Verlassen des Planungsmodus nötig
-- Den Benutzer fragen „Ist der Plan in Ordnung?" – genau das ist die Funktion dieses Tools, verwenden Sie nicht AskUserQuestion dafür
-
-## Hinweise
+## Parameter
 
-- Dieses Tool akzeptiert keinen Planinhalt als Parameter – es liest aus der zuvor geschriebenen Plandatei
-- Der Benutzer sieht den Inhalt der Plandatei zur Genehmigung
-- Verwenden Sie nicht AskUserQuestion vor dem Aufruf dieses Tools, um zu fragen „Ist der Plan in Ordnung?" – das wäre redundant
-- Erwähnen Sie den „Plan" nicht in Fragen, da der Benutzer den Planinhalt vor ExitPlanMode nicht sehen kann
+- `allowedPrompts` (array, optional): Prompts, die der Benutzer im Freigabedialog eingeben darf, um den Plan automatisch zu genehmigen oder zu verändern. Jedes Element spezifiziert eine begrenzte Berechtigung (zum Beispiel einen Operationsnamen und das Tool, auf das sie zutrifft). Nicht setzen, um den Standard-Freigabeablauf zu verwenden.
 
-## Originaltext
+## Beispiele
 
-<textarea readonly>Use this tool when you are in plan mode and have finished writing your plan to the plan file and are ready for user approval.
+### Beispiel 1: Standard-Einreichung
 
-## How This Tool Works
-- You should have already written your plan to the plan file specified in the plan mode system message
-- This tool does NOT take the plan content as a parameter - it will read the plan from the file you wrote
-- This tool simply signals that you're done planning and ready for the user to review and approve
-- The user will see the contents of your plan file when they review it
+Nachdem der Assistent im Planmodus ein Authentifizierungs-Refactoring untersucht und die Plandatei auf die Festplatte geschrieben hat, ruft er `ExitPlanMode` ohne Argumente auf. Der Harness liest den Plan aus seinem kanonischen Ort, zeigt ihn dem Benutzer an und wartet auf Genehmigung oder Ablehnung.
 
-## When to Use This Tool
-IMPORTANT: Only use this tool when the task requires planning the implementation steps of a task that requires writing code. For research tasks where you're gathering information, searching files, reading files or in general trying to understand the codebase - do NOT use this tool.
+### Beispiel 2: Vorab genehmigte Schnellaktionen
 
-## Before Using This Tool
-Ensure your plan is complete and unambiguous:
-- If you have unresolved questions about requirements or approach, use AskUserQuestion first (in earlier phases)
-- Once your plan is finalized, use THIS tool to request approval
+```
+ExitPlanMode(allowedPrompts=[
+  {"tool": "Bash", "prompt": "run tests"},
+  {"tool": "Bash", "prompt": "install dependencies"}
+])
+```
 
-**Important:** Do NOT use AskUserQuestion to ask "Is this plan okay?" or "Should I proceed?" - that's exactly what THIS tool does. ExitPlanMode inherently requests user approval of your plan.
+Erlaubt dem Benutzer, für routinemäßige Folge-Befehle im Voraus die Erlaubnis zu erteilen, damit der Assistent bei der Implementierung nicht für jede Berechtigungsabfrage pausieren muss.
 
-## Examples
+## Hinweise
 
-1. Initial task: "Search for and understand the implementation of vim mode in the codebase" - Do not use the exit plan mode tool because you are not planning the implementation steps of a task.
-2. Initial task: "Help me implement yank mode for vim" - Use the exit plan mode tool after you have finished planning the implementation steps of the task.
-3. Initial task: "Add a new feature to handle user authentication" - If unsure about auth method (OAuth, JWT, etc.), use AskUserQuestion first, then use exit plan mode tool after clarifying the approach.
-</textarea>
+- `ExitPlanMode` ist nur für umsetzungsartige Arbeit sinnvoll. Handelt es sich bei der Anfrage des Benutzers um eine Recherche- oder Erklärungsaufgabe ohne Dateiänderungen, antworten Sie direkt – routen Sie nicht über den Planmodus, nur um ihn zu verlassen.
+- Der Plan muss bereits auf die Festplatte geschrieben sein, bevor dieses Tool aufgerufen wird. `ExitPlanMode` akzeptiert den Planinhalt nicht als Parameter; es liest vom Pfad, den der Harness erwartet.
+- Lehnt der Benutzer den Plan ab, kehren Sie in den Planmodus zurück. Überarbeiten Sie basierend auf dem Feedback und reichen Sie erneut ein; beginnen Sie nicht mit Datei-Edits, solange der Plan nicht genehmigt ist.
+- Die Genehmigung erteilt die Erlaubnis, den Planmodus zu verlassen und verändernde Tools (`Edit`, `Write`, `Bash` und so weiter) für den im Plan beschriebenen Umfang zu verwenden. Eine nachträgliche Ausweitung des Umfangs erfordert einen neuen Plan oder die ausdrückliche Zustimmung des Benutzers.
+- Verwenden Sie `AskUserQuestion` nicht, um vor dem Aufruf dieses Tools "sieht dieser Plan gut aus?" zu fragen – die Plan-Genehmigung anzufordern ist genau das, was `ExitPlanMode` tut, und der Benutzer kann den Plan erst nach der Einreichung sehen.
+- Halten Sie den Plan minimal und umsetzbar. Ein Reviewer sollte ihn in unter einer Minute überfliegen und genau verstehen können, was geändert wird.
+- Erkennen Sie während der Implementierung, dass der Plan falsch war, stoppen Sie und melden Sie dies dem Benutzer, statt stillschweigend abzuweichen. Das erneute Betreten des Planmodus ist ein gültiger nächster Schritt.

package/concepts/de/Tool-ExitWorktree.md

@@ -0,0 +1,41 @@
+# ExitWorktree
+
+Beendet eine zuvor von `EnterWorktree` erstellte Worktree-Sitzung und kehrt zum ursprünglichen Arbeitsverzeichnis zurück. Dieses Tool wirkt ausschließlich auf Worktrees, die in der aktuellen Sitzung von `EnterWorktree` erstellt wurden. Ist keine solche Sitzung aktiv, ist der Aufruf wirkungslos.
+
+## Wann verwenden
+
+- Die Arbeit in einem isolierten Worktree ist abgeschlossen und Sie möchten zum Hauptarbeitsverzeichnis zurückkehren.
+- Eine Aufgabe in einem Feature-Branch-Worktree ist erledigt und nach dem Mergen soll der Branch mitsamt Verzeichnis bereinigt werden.
+- Der Worktree soll für eine spätere Nutzung erhalten bleiben, ohne dass dabei etwas gelöscht wird.
+- Ein experimenteller oder temporärer Branch soll verworfen werden, ohne Artefakte auf der Festplatte zu hinterlassen.
+- Vor dem Start einer neuen `EnterWorktree`-Sitzung muss die aktuelle zuerst beendet werden.
+
+## Parameter
+
+- `action` (Zeichenkette, erforderlich): `"keep"` belässt das Worktree-Verzeichnis und den Branch auf der Festplatte, sodass später zurückgekehrt werden kann; `"remove"` löscht sowohl das Verzeichnis als auch den Branch für einen sauberen Abschluss.
+- `discard_changes` (Boolescher Wert, optional, Standard `false`): Nur relevant, wenn `action` den Wert `"remove"` hat. Enthält der Worktree nicht committete Dateien oder Commits, die nicht im ursprünglichen Branch vorhanden sind, verweigert das Tool das Entfernen, sofern `discard_changes` nicht auf `true` gesetzt wird. Die Fehlerantwort listet die betreffenden Änderungen auf, damit vor einem erneuten Aufruf die Bestätigung des Benutzers eingeholt werden kann.
+
+## Beispiele
+
+### Beispiel 1: Sauberer Abschluss nach dem Mergen von Änderungen
+
+Nach Abschluss der Arbeit im Worktree und dem Mergen des Branches in den Hauptbranch wird `ExitWorktree` mit `action: "remove"` aufgerufen. Das Worktree-Verzeichnis und der Branch werden gelöscht, und die Sitzung kehrt zum ursprünglichen Arbeitsverzeichnis zurück.
+
+```
+ExitWorktree(action: "remove")
+```
+
+### Beispiel 2: Verwerfen eines temporären Worktrees mit nicht committeten experimentellen Änderungen
+
+Enthält ein Worktree experimentelle, nicht committete Änderungen, die vollständig verworfen werden sollen, wird zunächst `action: "remove"` versucht. Das Tool verweigert den Vorgang und listet die nicht committeten Änderungen auf. Nach Bestätigung durch den Benutzer wird mit `discard_changes: true` erneut aufgerufen.
+
+```
+ExitWorktree(action: "remove", discard_changes: true)
+```
+
+## Hinweise
+
+- Dieses Tool wirkt ausschließlich auf Worktrees, die in der aktuellen Sitzung von `EnterWorktree` erstellt wurden. Worktrees, die mit `git worktree add` angelegt wurden, Worktrees aus früheren Sitzungen oder das normale Arbeitsverzeichnis, falls `EnterWorktree` nie aufgerufen wurde, werden nicht berührt — in diesen Fällen ist der Aufruf wirkungslos.
+- `action: "remove"` wird verweigert, wenn der Worktree nicht committete Änderungen oder Commits enthält, die nicht im ursprünglichen Branch vorhanden sind, sofern `discard_changes: true` nicht explizit angegeben wird. Da die Daten nicht wiederhergestellt werden können, ist vor dem Setzen von `discard_changes: true` stets die Bestätigung des Benutzers einzuholen.
+- Ist eine tmux-Sitzung an den Worktree gebunden, wird sie bei `remove` beendet; bei `keep` läuft sie weiter, und ihr Name wird zurückgegeben, damit der Benutzer sich später wieder verbinden kann.
+- Nach Abschluss von `ExitWorktree` kann `EnterWorktree` erneut aufgerufen werden, um eine neue Worktree-Sitzung zu starten.

package/concepts/de/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## Definition
+Gleicht Dateinamen gegen ein Glob-Muster ab und gibt die Pfade zurück, sortiert nach neuester Änderungszeit zuerst. Optimiert, um Dateien in Codebases jeder Größe schnell zu finden, ohne auf `find` zurückzugreifen.
 
-Schnelles Dateinamen-Musterabgleich-Tool, das mit Codebasen jeder Größe funktioniert. Gibt übereinstimmende Dateipfade sortiert nach Änderungszeit zurück.
+## Wann verwenden
 
-## Parameter
+- Aufzählen aller Dateien einer bestimmten Erweiterung (zum Beispiel alle `*.ts`-Dateien unter `src`)
+- Auffinden von Konfigurations- oder Fixture-Dateien anhand von Namenskonventionen (`**/jest.config.*`, `**/*.test.tsx`)
+- Einschränken der Suchfläche, bevor ein gezieltes `Grep` ausgeführt wird
+- Prüfen, ob eine Datei unter einem bekannten Muster bereits existiert, bevor `Write` aufgerufen wird
+- Auffinden kürzlich geänderter Dateien, indem die Sortierung nach Änderungszeit genutzt wird
 
-| Parameter | Typ | Erforderlich | Beschreibung |
-|-----------|-----|--------------|--------------|
-| `pattern` | string | Ja | Glob-Muster (z.B. `**/*.js`, `src/**/*.ts`) |
-| `path` | string | Nein | Suchverzeichnis, Standard ist das aktuelle Arbeitsverzeichnis. Nicht "undefined" oder "null" übergeben |
+## Parameter
 
-## Anwendungsfälle
+- `pattern` (string, erforderlich): Der Glob-Ausdruck zum Abgleich. Unterstützt `*` für Einzelsegment-Wildcards, `**` für rekursive Treffer und `{a,b}` für Alternativen, zum Beispiel `src/**/*.{ts,tsx}`.
+- `path` (string, optional): Verzeichnis, in dem die Suche ausgeführt wird. Muss bei Angabe ein gültiger Verzeichnispfad sein. Feld ganz weglassen, um das aktuelle Arbeitsverzeichnis zu durchsuchen. Nicht die Zeichenketten `"undefined"` oder `"null"` übergeben.
 
-**Geeignet für:**
-- Dateien nach Dateinamenmuster suchen
-- Alle Dateien eines bestimmten Typs finden (z.B. alle `.tsx`-Dateien)
-- Beim Suchen einer bestimmten Klassendefinition (z.B. `class Foo`) zuerst die Datei lokalisieren
-- Mehrere Glob-Aufrufe können in einer einzelnen Nachricht parallel gestartet werden
+## Beispiele
 
-**Nicht geeignet für:**
-- Dateiinhalte durchsuchen – dafür Grep verwenden
-- Offene Erkundung mit mehreren Suchrunden – dafür Task (Explore-Typ) verwenden
+### Beispiel 1: Jede TypeScript-Quelldatei
+`Glob` mit `pattern: "src/**/*.ts"` aufrufen. Das Ergebnis ist eine nach mtime sortierte Liste, sodass zuletzt bearbeitete Dateien zuerst erscheinen, was nützlich ist, um sich auf Brennpunkte zu konzentrieren.
 
-## Hinweise
+### Beispiel 2: Einen Kandidaten für eine Klassendefinition finden
+Wenn Sie vermuten, dass eine Klasse in einer Datei wohnt, deren Name Sie nicht kennen, mit `pattern: "**/*UserService*"` suchen, um die Kandidaten einzugrenzen, und dann mit `Read` oder `Grep` folgen.
 
-- Unterstützt Standard-Glob-Syntax: `*` matcht eine Ebene, `**` matcht mehrere Ebenen, `{}` matcht Alternativen
-- Ergebnisse sind nach Änderungszeit sortiert
-- Wird gegenüber dem `find`-Befehl in Bash bevorzugt
+### Beispiel 3: Parallele Erkundung vor einer größeren Aufgabe
+In einer einzigen Nachricht mehrere `Glob`-Aufrufe absetzen (zum Beispiel einen für `**/*.test.ts` und einen für `**/fixtures/**`), damit beide parallel laufen und ihre Ergebnisse korreliert werden können.
 
-## Originaltext
+## Hinweise
 
-<textarea readonly>- Fast file pattern matching tool that works with any codebase size
-- Supports glob patterns like "**/*.js" or "src/**/*.ts"
-- Returns matching file paths sorted by modification time
-- Use this tool when you need to find files by name patterns
-- When you are doing an open ended search that may require multiple rounds of globbing and grepping, use the Agent tool instead
-- You can call multiple tools in a single response. It is always better to speculatively perform multiple searches in parallel if they are potentially useful.</textarea>
+- Die Ergebnisse sind nach Dateimodifikationszeit sortiert (neueste zuerst), nicht alphabetisch. Sortieren Sie nachgelagert, wenn Sie eine stabile Reihenfolge benötigen.
+- Muster werden vom Tool ausgewertet, nicht von der Shell; Sie müssen sie nicht so quotieren oder escapen wie in der Kommandozeile.
+- Für offene Exploration, die mehrere Runden Suche und Reasoning erfordert, delegieren Sie an eine `Agent` mit dem Explore-Agenten-Typ, statt viele `Glob`-Aufrufe zu verketten.
+- Bevorzugen Sie `Glob` gegenüber `Bash`-Aufrufen von `find` oder `ls` für die Dateinamensfindung; es behandelt Berechtigungen konsistent und gibt strukturierte Ausgabe zurück.
+- Wenn Sie nach Inhalten innerhalb von Dateien statt nach Dateinamen suchen, verwenden Sie stattdessen `Grep`.