cc-viewer 1.6.182 → 1.6.183

package/concepts/da/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## Definition
+Opretter et isoleret Git-worktree på en ny branch, eller skifter sessionen til et eksisterende worktree i det aktuelle repository, så parallelt eller eksperimentelt arbejde kan fortsætte uden at røre det primære checkout.
 
-Creates an isolated git worktree and switches the current session into it. Only used when the user explicitly asks to work in a worktree.
+## Hvornår skal den bruges
 
-## Parametre
-
-| Name | Type | Required | Description |
-|---|---|---|---|
-| name | string | No | A name for the worktree. If not provided, a random name is generated. |
-
-## Anvendelsestilfælde
-
-**Egnet til:**
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree")
-
-**Ikke egnet til:**
-- 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
+- Brugeren siger udtrykkeligt "worktree" — for eksempel "start et worktree", "opret et worktree" eller "arbejd i et worktree".
+- Projektinstruktioner i `CLAUDE.md` eller vedvarende hukommelse anviser dig at bruge et worktree til den aktuelle opgave.
+- Du vil fortsætte en opgave, der tidligere blev sat op som et worktree (send `path` for at gå ind i det igen).
+- Flere eksperimentelle branches skal sameksistere på disken uden konstant checkout-churn.
+- En langvarig opgave bør isoleres fra urelaterede redigeringer i hovedarbejdstræet.
 
-## Bemærkninger
-
-- Must be in a git repository, or have WorktreeCreate/WorktreeRemove hooks configured
-- Must not already be in a worktree
-
-## Originaltekst
-
-<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.
+## Parametre
 
-## When to Use
+- `name` (string, valgfri): Et navn til en ny worktree-mappe. Hvert `/`-separeret segment må kun indeholde bogstaver, cifre, prikker, understregninger og bindestreger; hele strengen er begrænset til 64 tegn. Hvis udeladt, og `path` også er udeladt, genereres et tilfældigt navn. Gensidigt udelukkende med `path`.
+- `path` (string, valgfri): Filsystemstien til et eksisterende worktree af det aktuelle repository, der skal skiftes til. Skal fremgå af `git worktree list` for dette repo; stier, der ikke er registrerede worktrees af det aktuelle repo, afvises. Gensidigt udelukkende med `name`.
 
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree", "use a worktree")
+## Eksempler
 
-## When NOT to Use
+### Eksempel 1: Opret et nyt worktree med et beskrivende navn
 
-- 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
+Opretter `.claude/worktrees/feat/okta-sso` på en ny branch baseret på `HEAD` og skifter derefter sessionens arbejdsmappe ind i det. Alle efterfølgende filredigeringer og shell-kommandoer opererer inde i det worktree, indtil du afslutter.
 
-- Must be in a git repository, OR have WorktreeCreate/WorktreeRemove hooks configured in settings.json
-- Must not already be in a worktree
+### Eksempel 2: Gå ind i et eksisterende worktree igen
 
-## 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
+Genoptager arbejde i et tidligere oprettet worktree. Fordi du gik ind via `path`, vil `ExitWorktree` ikke slette det automatisk — forlader du det med `action: "keep"`, returneres du blot til den oprindelige mappe.
 
-## Parameters
+## Noter
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- Kald ikke `EnterWorktree`, medmindre brugeren udtrykkeligt har bedt om det, eller projektinstruktioner kræver det. Almindelige branch-skift eller fejlrettelsesanmodninger bør bruge normale Git-kommandoer, ikke worktrees.
+- Når værktøjet kaldes inde i et Git-repository, opretter det et worktree under `.claude/worktrees/` og registrerer en ny branch baseret på `HEAD`. Uden for et Git-repository delegerer det til konfigurerede `WorktreeCreate` / `WorktreeRemove`-hooks i `settings.json` for VCS-agnostisk isolation.
+- Kun én worktree-session er aktiv ad gangen. Værktøjet nægter at køre, hvis du allerede er inde i en worktree-session; afslut først med `ExitWorktree`.
+- Brug `ExitWorktree` til at forlade midt i en session. Hvis sessionen slutter, mens du stadig er inde i et nyoprettet worktree, bliver brugeren bedt om at beholde eller fjerne det.
+- Worktrees, der er tilgået via `path`, betragtes som eksterne — `ExitWorktree` med `action: "remove"` vil ikke slette dem. Dette er et sikkerhedsrækværk for at beskytte worktrees, brugeren håndterer manuelt.
+- Et nyt worktree arver den aktuelle branchs indhold, men har en uafhængig arbejdsmappe og indeks. Staged og unstaged ændringer i hovedcheckout'et er ikke synlige inde i worktree'et.
+- Navngivningstip: præfiks med typen af arbejde (`feat/`, `fix/`, `spike/`), så flere samtidige worktrees er nemme at skelne i `git worktree list`.

package/concepts/da/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## Definition
+Indsender implementeringsplanen, der blev udarbejdet under plantilstand, til brugergodkendelse og — hvis godkendt — skifter sessionen ud af plantilstand, så redigeringer kan begynde.
 
-Forlader planlægningstilstand og indsender planen til brugerens godkendelse. Planens indhold læses fra den tidligere skrevne planfil.
+## Hvornår skal den bruges
 
-## Parametre
-
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `allowedPrompts` | array | Nej | Liste over tilladelsebeskrivelser nødvendige for at implementere planen |
-
-Hvert element i `allowedPrompts`-arrayet:
-
-| Felt | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `tool` | enum | Ja | Det gældende værktøj, understøtter i øjeblikket kun `Bash` |
-| `prompt` | string | Ja | Semantisk beskrivelse af operationen (f.eks. "run tests", "install dependencies") |
+- En plan, der blev skrevet under `EnterPlanMode`, er færdig og klar til gennemgang.
+- Opgaven er implementeringsfokuseret (kode- eller konfigurationsændringer), ikke ren research, så en eksplicit plan er passende.
+- Al forudgående læsning og analyse er udført; ingen yderligere undersøgelse er nødvendig, før brugeren beslutter sig.
+- Assistenten har opregnet konkrete filstier, funktioner og trin — ikke blot mål.
+- Brugeren har bedt om at se planen, eller plantilstand-workflowet er ved at overdrage til redigeringsværktøjer.
 
-## Brugsscenarier
-
-**Egnet til:**
-- I planlægningstilstand er planen færdig og klar til brugerens godkendelse
-- Kun til implementeringsopgaver der kræver kodeskrivning
-
-**Ikke egnet til:**
-- Rene forsknings-/udforskningsopgaver — det er ikke nødvendigt at forlade planlægningstilstand
-- At ville spørge brugeren "er planen OK?" — det er præcis dette værktøjs funktion, brug ikke AskUserQuestion til at spørge
-
-## Bemærkninger
+## Parametre
 
-- Dette værktøj accepterer ikke planindhold som parameter — det læser fra den tidligere skrevne planfil
-- Brugeren vil se planfilens indhold til godkendelse
-- Brug ikke AskUserQuestion til at spørge "er planen OK?" før du kalder dette værktøj, det er overflødigt
-- Nævn ikke "planen" i spørgsmål, da brugeren ikke kan se planindholdet før ExitPlanMode
+- `allowedPrompts` (array, valgfri): Forespørgsler, som brugeren må skrive på godkendelsesskærmen for at auto-godkende eller ændre planen. Hvert element angiver en afgrænset tilladelse (for eksempel et operationsnavn og det værktøj, det gælder for). Lad være med at sætte for at bruge standardgodkendelsesflowet.
 
-## Originaltekst
+## Eksempler
 
-<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.
+### Eksempel 1: Standardindsendelse
 
-## 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
+Efter at have undersøgt en godkendelsesrefaktorering inde i plantilstand og skrevet planfilen til disk, kalder assistenten `ExitPlanMode` uden argumenter. Rammen læser planen fra dens kanoniske placering, viser den til brugeren og venter på godkendelse eller afvisning.
 
-## 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.
+### Eksempel 2: Forhåndsgodkendte hurtighandlinger
 
-## 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.
+Lader brugeren give tilladelse på forhånd til rutinemæssige opfølgningskommandoer, så assistenten ikke behøver at pause ved hver tilladelsesforespørgsel under implementeringen.
 
-## Examples
+## Noter
 
-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` giver kun mening for implementeringslignende arbejde. Hvis brugerens anmodning er en research- eller forklaringsopgave uden filændringer, svar direkte i stedet — dirigér ikke gennem plantilstand blot for at afslutte den.
+- Planen skal allerede være skrevet til disk, før dette værktøj kaldes. `ExitPlanMode` accepterer ikke planteksten som en parameter; den læser fra den sti, rammen forventer.
+- Hvis brugeren afviser planen, vender du tilbage til plantilstand. Revidér ud fra feedbacken og indsend igen; begynd ikke at redigere filer, mens planen er ugodkendt.
+- Godkendelse giver tilladelse til at forlade plantilstand og bruge muterende værktøjer (`Edit`, `Write`, `Bash` og så videre) inden for det omfang, der er beskrevet i planen. Udvidelse af omfang bagefter kræver en ny plan eller eksplicit brugersamtykke.
+- Brug ikke `AskUserQuestion` til at spørge "ser denne plan god ud?", før dette værktøj kaldes — at anmode om plangodkendelse er præcis, hvad `ExitPlanMode` gør, og brugeren kan ikke se planen, før den er indsendt.
+- Hold planen minimal og handlingsorienteret. En anmelder bør kunne skimme den på under et minut og forstå præcis, hvad der vil ændre sig.
+- Hvis du midt i implementeringen indser, at planen var forkert, stop og rapportér tilbage til brugeren i stedet for stille at afvige. At gå i plantilstand igen er et gyldigt næste skridt.

package/concepts/da/Tool-ExitWorktree.md

@@ -0,0 +1,41 @@
+# ExitWorktree
+
+Afslutter en worktree-session, der tidligere er oprettet af `EnterWorktree`, og returnerer sessionen til den oprindelige arbejdsmappe. Dette værktøj virker udelukkende på worktrees, der er oprettet af `EnterWorktree` i den aktuelle session; er ingen sådan session aktiv, er kaldet uden effekt.
+
+## Hvornår skal den bruges
+
+- Arbejdet i en isoleret worktree er afsluttet, og du ønsker at vende tilbage til den primære arbejdsmappe.
+- En opgave i en feature-branch-worktree er fuldført og er merget, og du ønsker at rydde op i branchen og mappen.
+- Du ønsker at bevare worktreeet til senere brug og blot vende tilbage til den oprindelige mappe uden at slette noget.
+- Du ønsker at opgive en eksperimentel eller midlertidig branch uden at efterlade artefakter på disken.
+- Du skal starte en ny `EnterWorktree`-session, hvilket kræver, at du først afslutter den nuværende.
+
+## Parametre
+
+- `action` (streng, påkrævet): `"keep"` bevarer worktree-mappen og branchen på disken, så du kan vende tilbage senere; `"remove"` sletter både mappen og branchen for en ren afslutning.
+- `discard_changes` (boolesk, valgfri, standard `false`): Kun relevant, når `action` er `"remove"`. Indeholder worktreeet ucommittede filer eller commits, der ikke findes i den oprindelige branch, nægter værktøjet at fjerne det, medmindre `discard_changes` er sat til `true`. Fejlsvaret viser de berørte ændringer, så du kan bekræfte med brugeren, inden du kalder igen.
+
+## Eksempler
+
+### Eksempel 1: ren afslutning efter merging af ændringer
+
+Efter at have afsluttet arbejdet i en worktree og merget branchen ind i main, kald `ExitWorktree` med `action: "remove"` for at slette worktree-mappen og branchen og vende tilbage til den oprindelige arbejdsmappe.
+
+```
+ExitWorktree(action: "remove")
+```
+
+### Eksempel 2: kassér en midlertidig worktree med ucommittet eksperimentel kode
+
+Indeholder en worktree eksperimentelle, ucommittede ændringer, der skal kasseres fuldstændigt, forsøg først `action: "remove"`. Værktøjet nægter og viser de ucommittede ændringer. Efter bekræftelse fra brugeren om, at ændringerne kan kasseres, kald igen med `discard_changes: true`.
+
+```
+ExitWorktree(action: "remove", discard_changes: true)
+```
+
+## Noter
+
+- Dette værktøj virker udelukkende på worktrees oprettet af `EnterWorktree` i den aktuelle session. Det berører ikke worktrees oprettet med `git worktree add`, worktrees fra tidligere sessioner eller den almindelige arbejdsmappe, hvis `EnterWorktree` aldrig er blevet kaldt — i disse tilfælde er kaldet uden effekt.
+- `action: "remove"` afvises, hvis worktreeet har ucommittede ændringer eller commits, der ikke er til stede i den oprindelige branch, medmindre `discard_changes: true` angives eksplicit. Bekræft altid med brugeren, inden du sætter `discard_changes: true`, da data ikke kan gendannes.
+- Er en tmux-session tilknyttet worktreeet: ved `remove` afbrydes den; ved `keep` fortsætter den, og dens navn returneres, så brugeren kan tilslutte sig igen senere.
+- Når `ExitWorktree` er afsluttet, kan `EnterWorktree` kaldes igen for at starte en ny worktree-session.

package/concepts/da/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## Definition
+Matcher filnavne mod et glob-mønster og returnerer stierne sorteret efter seneste ændringstidspunkt først. Optimeret til hurtigt at lokalisere filer i kodebaser af enhver størrelse uden at skulle gå til `find` via shell.
 
-Hurtigt filnavnsmønster-matchningsværktøj, der understøtter kodebaser af enhver størrelse. Returnerer matchende filstier sorteret efter ændringstidspunkt.
+## Hvornår skal den bruges
 
-## Parametre
+- Opremse hver fil af en specifik udvidelse (for eksempel alle `*.ts`-filer under `src`)
+- Opdage konfigurations- eller fixture-filer ved navnekonvention (`**/jest.config.*`, `**/*.test.tsx`)
+- Indsnævre et søgeoverflade før en målrettet `Grep`
+- Tjekke om en fil allerede eksisterer ved et kendt mønster før kald af `Write`
+- Finde nyligt ændrede filer ved at læne sig op ad ændringstidssorteringen
 
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `pattern` | string | Ja | Glob-mønster (f.eks. `**/*.js`, `src/**/*.ts`) |
-| `path` | string | Nej | Søgemappe, standard er den aktuelle arbejdsmappe. Send ikke "undefined" eller "null" |
+## Parametre
 
-## Brugsscenarier
+- `pattern` (string, påkrævet): Det glob-udtryk, der skal matches. Understøtter `*` for enkeltsegments-wildcards, `**` for rekursive match og `{a,b}` for alternativer, for eksempel `src/**/*.{ts,tsx}`.
+- `path` (string, valgfri): Mappe, som søgningen køres i. Skal være en gyldig mappesti, når angivet. Udelad feltet helt for at søge i den aktuelle arbejdsmappe. Send ikke strengene `"undefined"` eller `"null"`.
 
-**Egnet til:**
-- Søge filer efter filnavnsmønster
-- Finde alle filer af en bestemt type (f.eks. alle `.tsx`-filer)
-- Lokalisere filer når man søger efter en bestemt klassedefinition (f.eks. `class Foo`)
-- Man kan starte flere Glob-kald parallelt i en enkelt besked
+## Eksempler
 
-**Ikke egnet til:**
-- Søge filindhold — brug Grep
-- Åben udforskning der kræver flere søgerunder — brug Task (Explore-type)
+### Eksempel 1: Hver TypeScript-kildefil
+Kald `Glob` med `pattern: "src/**/*.ts"`. Resultatet er en mtime-sorteret liste, så de senest redigerede filer vises først, hvilket er nyttigt til at fokusere på hotspots.
 
-## Bemærkninger
+### Eksempel 2: Find en kandidat til en klassedefinition
+Når du mistænker, at en klasse ligger i en fil, hvis navn du ikke kender, så søg med `pattern: "**/*UserService*"` for at indsnævre kandidaterne, og følg op med `Read` eller `Grep`.
 
-- Understøtter standard glob-syntaks: `*` matcher ét niveau, `**` matcher flere niveauer, `{}` matcher flervalg
-- Resultater sorteres efter ændringstidspunkt
-- Mere anbefalet end Bashs `find`-kommando
+### Eksempel 3: Parallel opdagelse før en større opgave
+I en enkelt besked kan du udstede flere `Glob`-kald (for eksempel et for `**/*.test.ts` og et for `**/fixtures/**`), så begge kører parallelt, og deres resultater kan korreleres.
 
-## Originaltekst
+## Noter
 
-<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>
+- Resultater er sorteret efter filens ændringstid (nyeste først), ikke alfabetisk. Sortér nedstrøms, hvis du har brug for stabil rækkefølge.
+- Mønstre evalueres af værktøjet, ikke af skallen; du behøver ikke at sætte dem i anførselstegn eller escape dem som på kommandolinjen.
+- Til åben udforskning, der kræver flere runder af søgning og ræsonnement, delegér til en `Agent` med Explore-agenttypen i stedet for at kæde mange `Glob`-kald.
+- Foretræk `Glob` frem for `Bash`-kald af `find` eller `ls` til filnavnsopdagelse; det håndterer tilladelser konsekvent og returnerer struktureret output.
+- Når du leder efter indhold inde i filer frem for filnavne, brug `Grep` i stedet.

package/concepts/da/Tool-Grep.md

@@ -1,57 +1,46 @@
 # Grep
 
-## Definition
+Søger i filindhold ved hjælp af ripgrep-motoren. Tilbyder fuld understøttelse af regulære udtryk, filtrering efter filtype og tre output-tilstande, så du kan afveje præcision mod kompakthed.
 
-Kraftfuldt indholdssøgningsværktøj baseret på ripgrep. Understøtter regulære udtryk, filtypefiltring og flere outputtilstande.
+## Hvornår skal den bruges
+
+- Lokalisering af hvert kaldssted for en funktion eller hver reference til en identifikator
+- Tjekke om en streng eller fejlmeddelelse forekommer nogen steder i kodebasen
+- Tælle forekomster af et mønster for at vurdere påvirkning før refaktorering
+- Indsnævre en søgning til en filtype (`type: "ts"`) eller glob (`glob: "**/*.tsx"`)
+- Hente match på tværs af linjer, såsom multi-linje-struct-definitioner eller JSX-blokke, med `multiline: true`
 
 ## Parametre
 
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `pattern` | string | Ja | Søgemønster med regulært udtryk |
-| `path` | string | Nej | Søgesti (fil eller mappe), standard er den aktuelle arbejdsmappe |
-| `glob` | string | Nej | Filnavnsfilter (f.eks. `*.js`, `*.{ts,tsx}`) |
-| `type` | string | Nej | Filtypefilter (f.eks. `js`, `py`, `rust`), mere effektivt end glob |
-| `output_mode` | enum | Nej | Outputtilstand: `files_with_matches` (standard), `content`, `count` |
-| `-i` | boolean | Nej | Søgning uden forskel på store/små bogstaver |
-| `-n` | boolean | Nej | Vis linjenumre (kun content-tilstand), standard true |
-| `-A` | number | Nej | Antal linjer der vises efter match |
-| `-B` | number | Nej | Antal linjer der vises før match |
-| `-C` / `context` | number | Nej | Antal linjer der vises før og efter match |
-| `head_limit` | number | Nej | Begræns antal outputposter, standard 0 (ubegrænset) |
-| `offset` | number | Nej | Spring de første N resultater over |
-| `multiline` | boolean | Nej | Aktiver flerlinjet matchningstilstand, standard false |
-
-## Brugsscenarier
-
-**Egnet til:**
-- Søge efter specifikke strenge eller mønstre i kodebasen
-- Finde hvor funktioner/variabler bruges
-- Filtrere søgeresultater efter filtype
-- Tælle antal matches
-
-**Ikke egnet til:**
-- Søge filer efter filnavn — brug Glob
-- Åben udforskning der kræver flere søgerunder — brug Task (Explore-type)
-
-## Bemærkninger
-
-- Bruger ripgrep-syntaks (ikke grep), specialtegn som krøllede parenteser skal escapes
-- `files_with_matches`-tilstand returnerer kun filstier, mest effektiv
-- `content`-tilstand returnerer matchende linjeindhold, understøtter kontekstlinjer
-- Flerlinjet matching kræver indstillingen `multiline: true`
-- Brug altid Grep-værktøjet frem for `grep`- eller `rg`-kommandoer i Bash
-
-## Originaltekst
-
-<textarea readonly>A powerful search tool built on ripgrep
-
-  Usage:
-  - ALWAYS use Grep for search tasks. NEVER invoke `grep` or `rg` as a Bash command. The Grep tool has been optimized for correct permissions and access.
-  - Supports full regex syntax (e.g., "log.*Error", "function\s+\w+")
-  - Filter files with glob parameter (e.g., "*.js", "**/*.tsx") or type parameter (e.g., "js", "py", "rust")
-  - Output modes: "content" shows matching lines, "files_with_matches" shows only file paths (default), "count" shows match counts
-  - Use Agent tool for open-ended searches requiring multiple rounds
-  - Pattern syntax: Uses ripgrep (not grep) - literal braces need escaping (use `interface\{\}` to find `interface{}` in Go code)
-  - Multiline matching: By default patterns match within single lines only. For cross-line patterns like `struct \{[\s\S]*?field`, use `multiline: true`
-</textarea>
+- `pattern` (string, påkrævet): Det regulære udtryk, der skal søges efter. Bruger ripgrep-syntaks, så literale tuborgklammer skal escapes (for eksempel `interface\{\}` for at finde `interface{}`).
+- `path` (string, valgfri): Fil eller mappe, der skal søges i. Standard er den aktuelle arbejdsmappe.
+- `glob` (string, valgfri): Filnavnsfilter som `*.js` eller `*.{ts,tsx}`.
+- `type` (string, valgfri): Genvej til filtype som `js`, `py`, `rust`, `go`. Mere effektivt end `glob` for standardsprog.
+- `output_mode` (enum, valgfri): `files_with_matches` (standard, returnerer kun stier), `content` (returnerer matchende linjer) eller `count` (returnerer matchantal).
+- `-i` (boolean, valgfri): Case-insensitiv matchning.
+- `-n` (boolean, valgfri): Inkludér linjenumre i `content`-tilstand. Standard er `true`.
+- `-A` (number, valgfri): Linjer med kontekst, der vises efter hvert match (kræver `content`-tilstand).
+- `-B` (number, valgfri): Linjer med kontekst før hvert match (kræver `content`-tilstand).
+- `-C` / `context` (number, valgfri): Linjer med kontekst på begge sider af hvert match.
+- `multiline` (boolean, valgfri): Tillad mønstre at spænde over linjeskift (`.` matcher `\n`). Standard er `false`.
+- `head_limit` (number, valgfri): Begræns returnerede linjer, filstier eller tælleposter. Standard er 250; send `0` for ubegrænset (brug sparsomt).
+- `offset` (number, valgfri): Spring de første N resultater over, før `head_limit` anvendes. Standard er `0`.
+
+## Eksempler
+
+### Eksempel 1: Find alle kaldssteder for en funktion
+Sæt `pattern: "registerHandler\\("`, `output_mode: "content"` og `-C: 2` for at se de omgivende linjer for hvert kald.
+
+### Eksempel 2: Tæl match på tværs af en type
+Sæt `pattern: "TODO"`, `type: "py"` og `output_mode: "count"` for at se TODO-totaler pr. fil på tværs af Python-kilder.
+
+### Eksempel 3: Multi-linje struct-match
+Brug `pattern: "struct Config \\{[\\s\\S]*?version"` med `multiline: true` for at fange et felt, der er erklæret flere linjer inde i en Go-struct.
+
+## Noter
+
+- Foretræk altid `Grep` frem for at køre `grep` eller `rg` gennem `Bash`; værktøjet er optimeret til korrekte tilladelser og struktureret output.
+- Standard output-tilstand er `files_with_matches`, som er den billigste. Skift kun til `content`, når du skal se selve linjerne.
+- Kontekstflag (`-A`, `-B`, `-C`) ignoreres, medmindre `output_mode` er `content`.
+- Store resultatsæt brænder kontekst-tokens. Brug `head_limit`, `offset` eller strammere `glob`/`type`-filtre for at holde fokus.
+- Til filnavnsopdagelse brug `Glob` i stedet; til åbne undersøgelser over mange runder udsend en `Agent` med Explore-agenten.

package/concepts/da/Tool-Monitor.md

@@ -0,0 +1,50 @@
+# Monitor
+
+Starter en baggrundsmonitor, der streamer hændelser fra et langvarigt script. Hver linje i standardoutput bliver en notifikation — fortsæt med at arbejde, mens hændelser ankommer i chatten.
+
+## Hvornår skal den bruges
+
+- Overvåge fejl, advarsler eller nedbrudsignaturer i en logfil, mens et deployment kører
+- Forespørge en fjern-API, en PR eller en CI-pipeline hvert 30. sekund for at opdage nye statushændelser
+- Holde øje med ændringer i en filsystemmappe eller byggeutput i realtid
+- Vente på en specifik betingelse over mange iterationer (f.eks. en milepæl for et træningsskridt eller tømning af en kø)
+- **Ikke** til simpel "vent til færdig" — brug `Bash` med `run_in_background` til det; det udsender én afslutningsnotifikation, når processen afsluttes
+
+## Parametre
+
+- `command` (streng, påkrævet): Den shell-kommando eller det script, der skal køres. Hver linje skrevet til standardoutput bliver en separat notifikationshændelse. Monitoren slutter, når processen afsluttes.
+- `description` (streng, påkrævet): En kort læsbar etiket vist i hver notifikation. Vær specifik — "fejl i deploy.log" er bedre end "overvåger logs". Denne etiket identificerer, hvilken monitor der blev udløst.
+- `timeout_ms` (tal, standard `300000`, maks `3600000`): Afslutningsfrist i millisekunder. Efter denne varighed afsluttes processen tvungent. Ignoreres når `persistent: true`.
+- `persistent` (boolsk, standard `false`): Når `true`, kører monitoren hele sessionens levetid uden timeout. Stop den eksplicit med `TaskStop`.
+
+## Eksempler
+
+### Eksempel 1: Overvåge en logfil for fejl og nedbrud
+
+Dette eksempel dækker alle terminaltilstande: succesmarkør, traceback, almindelige fejlnøgleord, OOM-afslutning og uventet procesafslutning.
+
+```bash
+tail -F /var/log/deploy.log | grep -E --line-buffered \
+  "deployed|Traceback|Error|FAILED|assert|Killed|OOM"
+```
+
+Brug `grep --line-buffered` i alle pipes. Uden det bufferlagrer operativsystemet output i 4 KB-blokke, og hændelser kan forsinkes i minutter. Alternationsmønsteret dækker både succesvejen (`deployed`) og fejlveje (`Traceback`, `Error`, `FAILED`, `Killed`, `OOM`). En monitor, der kun ser efter succesmarkøren, forbliver stille under et nedbrud — stilhed er identisk med "kører stadig".
+
+### Eksempel 2: Forespørge en fjern-API hvert 30. sekund
+
+```bash
+while true; do
+  curl -sf "https://api.example.com/status" || true
+  sleep 30
+done | grep --line-buffered -E "completed|failed|error"
+```
+
+`|| true` forhindrer en forbigående netværksfejl i at afslutte løkken. Forespørgselsintervaller på 30 sekunder eller mere er passende for fjern-API'er for at undgå hastighedsgrænser. Juster grep-mønsteret for at fange både succes- og fejlsvar, så fejl på API-siden ikke skjules af stilhed.
+
+## Noter
+
+- **Brug altid `grep --line-buffered` i pipes.** Uden det forsinker pipe-bufferlagring hændelser i minutter, fordi operativsystemet akkumulerer output, indtil en 4 KB-blok er fyldt. `--line-buffered` tvinger en flush efter hver linje.
+- **Filteret skal dække både succes- og fejlsignaturer.** En monitor, der kun overvåger succesmarkøren, forbliver stille ved nedbrud, hæng eller uventet afslutning. Udvid alternationen: inkluder `Error`, `Traceback`, `FAILED`, `Killed`, `OOM` og lignende terminaltilstandsmarkører ved siden af succesnøgleordet.
+- **Forespørgselsintervaller: 30 sekunder eller mere for fjern-API'er.** Hyppig forespørgsel til eksterne tjenester risikerer hastighedsgrænsefejl eller blokeringer. For lokale filsystem- eller proceskontroller er 0,5–1 sekund passende.
+- **Brug `persistent: true` til monitorer med sessionens levetid.** Standard `timeout_ms` på 300.000 ms (5 minutter) afslutter processen. For monitorer, der skal køre, indtil de eksplicit stoppes, sæt `persistent: true` og kald `TaskStop` når færdig.
+- **Automatisk stop ved hændelsesoversvømmelse.** Hver linje i standardoutput er en samtalebesked. Hvis filteret er for bredt og producerer for mange hændelser, stoppes monitoren automatisk. Genstart med et strammere `grep`-mønster. Linjer, der ankommer inden for 200 ms, grupperes i én notifikation.

package/concepts/da/Tool-NotebookEdit.md

@@ -1,33 +1,39 @@
 # NotebookEdit
 
-## Definition
+Ændrer en enkelt celle i en Jupyter-notebook (`.ipynb`). Understøtter udskiftning af en celles kilde, indsættelse af en ny celle eller sletning af en eksisterende celle, mens resten af notebookens struktur bevares.
 
-Erstatter, indsætter eller sletter specifikke celler i en Jupyter notebook (.ipynb-fil).
+## Hvornår skal den bruges
+
+- Rette eller opdatere en kodecelle i en analyse-notebook uden at omskrive hele filen
+- Udskifte en markdown-celle for at forbedre narrativ eller tilføje dokumentation
+- Indsætte en ny kode- eller markdown-celle på en kendt position i en eksisterende notebook
+- Fjerne en forældet eller ødelagt celle, så nedstrømsceller ikke længere afhænger af den
+- Forberede en reproducerbar notebook ved at iterere på celler én ad gangen
 
 ## Parametre
 
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `notebook_path` | string | Ja | Absolut sti til notebook-filen |
-| `new_source` | string | Ja | Nyt indhold til cellen |
-| `cell_id` | string | Nej | ID på cellen der skal redigeres. I indsættelsestilstand indsættes den nye celle efter dette ID |
-| `cell_type` | enum | Nej | Celletype: `code` eller `markdown`. Påkrævet i indsættelsestilstand |
-| `edit_mode` | enum | Nej | Redigeringstilstand: `replace` (standard), `insert`, `delete` |
+- `notebook_path` (string, påkrævet): Absolut sti til `.ipynb`-filen. Relative stier afvises.
+- `new_source` (string, påkrævet): Den nye cellekilde. For `replace` og `insert` bliver den cellens krop; for `delete` ignoreres den, men er stadig påkrævet af skemaet.
+- `cell_id` (string, valgfri): ID for målcellen. I `replace`- og `delete`-tilstand virker værktøjet på denne celle. I `insert`-tilstand indsættes den nye celle umiddelbart efter cellen med dette ID; udelad det for at indsætte øverst i notebooken.
+- `cell_type` (enum, valgfri): Enten `code` eller `markdown`. Påkrævet når `edit_mode` er `insert`. Når det udelades under `replace`, bevares den eksisterende celles type.
+- `edit_mode` (enum, valgfri): `replace` (standard), `insert` eller `delete`.
 
-## Brugsscenarier
+## Eksempler
 
-**Egnet til:**
-- Ændre kode- eller markdown-celler i en Jupyter notebook
-- Tilføje nye celler til en notebook
-- Slette celler fra en notebook
+### Eksempel 1: Udskift en fejlbehæftet kodecelle
+Kald `NotebookEdit` med `notebook_path` sat til den absolutte sti, `cell_id` sat til målcellens ID og `new_source` indeholdende den rettede Python-kode. Lad `edit_mode` stå på standardværdien `replace`.
 
-## Bemærkninger
+### Eksempel 2: Indsæt en markdown-forklaring
+For at tilføje en markdown-celle lige efter en eksisterende `setup`-celle, sæt `edit_mode: "insert"`, `cell_type: "markdown"`, `cell_id` til setup-cellens ID, og læg narrativet i `new_source`.
 
-- `cell_number` er 0-indekseret
-- `insert`-tilstand indsætter en ny celle på den angivne position
-- `delete`-tilstand sletter cellen på den angivne position
-- Stien skal være absolut
+### Eksempel 3: Slet en forældet celle
+Sæt `edit_mode: "delete"` og angiv `cell_id` for den celle, der skal fjernes. Angiv en vilkårlig streng for `new_source`; den anvendes ikke.
 
-## Originaltekst
+## Noter
 
-<textarea readonly>Completely replaces the contents of a specific cell in a Jupyter notebook (.ipynb file) with new source. Jupyter notebooks are interactive documents that combine code, text, and visualizations, commonly used for data analysis and scientific computing. The notebook_path parameter must be an absolute path, not a relative path. The cell_number is 0-indexed. Use edit_mode=insert to add a new cell at the index specified by cell_number. Use edit_mode=delete to delete the cell at the index specified by cell_number.</textarea>
+- Send altid en absolut sti. `NotebookEdit` opløser ikke relative stier mod arbejdsmappen.
+- Værktøjet omskriver kun den målrettede celle; eksekveringstal, output og metadata for urelaterede celler forbliver uberørte.
+- Indsættelse uden et `cell_id` placerer den nye celle allerførst i notebooken.
+- `cell_type` er obligatorisk ved indsættelser. Ved erstatninger skal det udelades, medmindre du eksplicit ønsker at konvertere en kodecelle til markdown eller omvendt.
+- For at inspicere celler og få fat i deres ID'er skal du først bruge `Read`-værktøjet på notebooken; den returnerer cellerne med deres indhold og output.
+- Brug almindelig `Edit` til almindelige kildefiler; `NotebookEdit` er specifik for `.ipynb`-JSON og forstår dens cellestruktur.

package/concepts/da/Tool-PushNotification.md

@@ -0,0 +1,48 @@
+# PushNotification
+
+Sender en skrivebordsnotifikation fra den aktuelle Claude Code-session. Hvis Remote Control er tilsluttet, sendes notifikationen også til brugerens telefon og trækker deres opmærksomhed tilbage til sessionen, uanset hvad de er i gang med.
+
+## Hvornår skal den bruges
+
+- En langvarig opgave er afsluttet, mens brugeren sandsynligvis var væk fra terminalen
+- Et build, en testkørsel eller et deployment er gennemført, og resultatet er klar til gennemgang
+- Der er nået et beslutningspunkt, der kræver brugerens input, før arbejdet kan fortsætte
+- Der er opstået en fejl eller bloker, som ikke kan løses autonomt
+- Brugeren har eksplicit bedt om at blive underrettet, når en bestemt opgave eller betingelse er opfyldt
+
+## Hvornår den ikke skal bruges
+
+Send ikke en notifikation for rutinemæssige statusopdateringer midt i en opgave eller for at bekræfte, at du har besvaret noget, som brugeren tydeligvis netop har spurgt om og stadig venter på. Giv ikke besked, når en kort opgave er færdig — hvis brugeren netop har indsendt den og venter, tilføjer en notifikation ingen værdi og underminerer tilliden til fremtidige notifikationer. Hold dig stærkt til ikke at sende.
+
+## Parametre
+
+- `message` (streng, påkrævet): notifikationens brødtekst. Hold den under 200 tegn; mobile operativsystemer afskærer længere strenge. Begynd med det, brugeren vil handle på: "build failed: 2 auth tests" er mere nyttigt end "task complete".
+- `status` (streng, påkrævet): altid sat til `"proactive"`. Dette er en fast markør og ændres ikke.
+
+## Eksempler
+
+### Eksempel 1: notifikation ved afslutning af en lang analyse
+
+En repository-bred afhængighedsrevision blev anmodet om og tog adskillige minutter. Brugeren forlod arbejdspladsen. Når rapporten er klar:
+
+```
+message: "Afhængighedsrevision færdig: 3 høj-alvorlige CVE'er i lodash, axios, jsonwebtoken. Rapport: audit-report.txt"
+status: "proactive"
+```
+
+### Eksempel 2: markering af et beslutningspunkt under autonomt arbejde
+
+Under en flertrinsomlægning opdages det, at to moduler har modstridende grænseflader og ikke kan sammenflettes uden en designbeslutning:
+
+```
+message: "Omlægning sat på pause: AuthService og UserService har modstridende token-grænseflader. Din beslutning kræves for at fortsætte."
+status: "proactive"
+```
+
+## Noter
+
+- Hold dig stærkt til **ikke** at sende. Notifikationen afbryder brugeren uanset hvad de laver. Behandl det som en omkostning, der skal retfærdiggøres af informationens værdi.
+- Begynd med handlingsbart indhold. De første ord skal fortælle brugeren, hvad der skete, og hvad de eventuelt skal gøre — ikke en generisk statusetikette.
+- Hold `message` under 200 tegn. Mobile operativsystemer afskærer længere strenge og kan fjerne den vigtigste del, hvis den optræder til sidst.
+- Hvis resultatet angiver, at pushen ikke blev sendt, fordi Remote Control ikke er tilsluttet, er det forventet adfærd. Der kræves ingen ny forsøg eller opfølgende handling; den lokale skrivebordsnotifikation udløses stadig.
+- Undgå notifikationsspam. Hvis der hyppigt sendes notifikationer for mindre hændelser, vil brugeren begynde at ignorere dem. Reservér dette værktøj til situationer, hvor der er en reel chance for, at brugeren er gået, og vil vide resultatet nu.