cc-viewer 1.6.182 → 1.6.183

package/concepts/da/Tool-Bash.md

@@ -1,167 +1,39 @@
 # Bash
 
-## Definition
+Kører en shell-kommando inde i en vedvarende arbejdsmappe og returnerer dens stdout/stderr. Reserveres bedst til operationer, som intet dedikeret Claude Code-værktøj kan udtrykke, såsom at køre git, npm, docker eller build-scripts.
 
-Udfører shell-kommandoer med valgfri timeout-indstilling. Arbejdsmappen bevares mellem kommandoer, men shell-tilstanden (miljøvariabler osv.) bevares ikke.
+## Hvornår skal den bruges
 
-## Parametre
-
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `command` | string | Ja | Bash-kommandoen der skal udføres |
-| `description` | string | Nej | Kort beskrivelse af kommandoen |
-| `timeout` | number | Nej | Timeout i millisekunder, maks. 600000, standard 120000 |
-| `run_in_background` | boolean | Nej | Om den skal køre i baggrunden |
-
-## Brugsscenarier
-
-**Egnet til:**
-- Git-operationer (commit, push, branch osv.)
-- npm/yarn og andre pakkehåndteringskommandoer
-- Docker-operationer
-- Kompilerings- og build-kommandoer
-- Liste mappeindhold (`ls`)
-- Andre systemkommandoer der kræver shell-udførelse
-
-**Ikke egnet til:**
-- Læse filer — brug Read
-- Søge filnavne — brug Glob
-- Søge filindhold — brug Grep
-- Redigere filer — brug Edit
-- Skrive filer — brug Write
-- Vise information til brugeren — skriv direkte i svarteksten
-- Langvarige processer (dev server, watch-tilstand) — anbefal brugeren at køre dem manuelt
-
-## Bemærkninger
-
-- Stier med mellemrum skal omsluttes af dobbelte anførselstegn
-- Output over 30000 tegn afkortes
-- Baggrundskommandoer henter resultater via TaskOutput
-- Brug helst absolutte stier, undgå `cd`
-- Uafhængige kommandoer kan kaldes parallelt med flere Bash
-- Kommandoer med afhængigheder kædes sammen med `&&`
-- Shell-miljøet initialiseres fra brugerens profil (bash eller zsh)
-
-## Originaltekst
-
-<textarea readonly>Executes a given bash command and returns its output.
-
-The working directory persists between commands, but shell state does not. The shell environment is initialized from the user's profile (bash or zsh).
+- Udfør git-operationer (`git status`, `git diff`, `git commit`, `gh pr create`)
+- Kør pakkehåndterere og build-værktøjer (`npm install`, `npm run build`, `pytest`, `cargo build`)
+- Start langvarige processer (dev-servere, watchers) i baggrunden med `run_in_background`
+- Kald domænespecifikke CLI'er (`docker`, `terraform`, `kubectl`, `gh`), som ikke har en indbygget ækvivalent
+- Kæd afhængige trin sammen med `&&`, når rækkefølgen er vigtig
 
-IMPORTANT: Avoid using this tool to run `find`, `grep`, `cat`, `head`, `tail`, `sed`, `awk`, or `echo` commands, unless explicitly instructed or after you have verified that a dedicated tool cannot accomplish your task. Instead, use the appropriate dedicated tool as this will provide a much better experience for the user:
-
- - File search: Use Glob (NOT find or ls)
- - Content search: Use Grep (NOT grep or rg)
- - Read files: Use Read (NOT cat/head/tail)
- - Edit files: Use Edit (NOT sed/awk)
- - Write files: Use Write (NOT echo >/cat <<EOF)
- - Communication: Output text directly (NOT echo/printf)
-While the Bash tool can do similar things, it’s better to use the built-in tools as they provide a better user experience and make it easier to review tool calls and give permission.
-
-# Instructions
- - If your command will create new directories or files, first use this tool to run `ls` to verify the parent directory exists and is the correct location.
- - Always quote file paths that contain spaces with double quotes in your command (e.g., cd "path with spaces/file.txt")
- - Try to maintain your current working directory throughout the session by using absolute paths and avoiding usage of `cd`. You may use `cd` if the User explicitly requests it.
- - You may specify an optional timeout in milliseconds (up to 600000ms / 10 minutes). By default, your command will timeout after 120000ms (2 minutes).
- - You can use the `run_in_background` parameter to run the command in the background. Only use this if you don't need the result immediately and are OK being notified when the command completes later. You do not need to check the output right away - you'll be notified when it finishes. You do not need to use '&' at the end of the command when using this parameter.
- - Write a clear, concise description of what your command does. For simple commands, keep it brief (5-10 words). For complex commands (piped commands, obscure flags, or anything hard to understand at a glance), include enough context so that the user can understand what your command will do.
- - When issuing multiple commands:
-  - If the commands are independent and can run in parallel, make multiple Bash tool calls in a single message. Example: if you need to run "git status" and "git diff", send a single message with two Bash tool calls in parallel.
-  - If the commands depend on each other and must run sequentially, use a single Bash call with '&&' to chain them together.
-  - Use ';' only when you need to run commands sequentially but don't care if earlier commands fail.
-  - DO NOT use newlines to separate commands (newlines are ok in quoted strings).
- - For git commands:
-  - Prefer to create a new commit rather than amending an existing commit.
-  - Before running destructive operations (e.g., git reset --hard, git push --force, git checkout --), consider whether there is a safer alternative that achieves the same goal. Only use destructive operations when they are truly the best approach.
-  - Never skip hooks (--no-verify) or bypass signing (--no-gpg-sign, -c commit.gpgsign=false) unless the user has explicitly asked for it. If a hook fails, investigate and fix the underlying issue.
- - Avoid unnecessary `sleep` commands:
-  - Do not sleep between commands that can run immediately — just run them.
-  - If your command is long running and you would like to be notified when it finishes – simply run your command using `run_in_background`. There is no need to sleep in this case.
-  - Do not retry failing commands in a sleep loop — diagnose the root cause or consider an alternative approach.
-  - If waiting for a background task you started with `run_in_background`, you will be notified when it completes — do not poll.
-  - If you must poll an external process, use a check command (e.g. `gh run view`) rather than sleeping first.
-  - If you must sleep, keep the duration short (1-5 seconds) to avoid blocking the user.
-
-# Committing changes with git
-
-Only create commits when requested by the user. If unclear, ask first. When the user asks you to create a new git commit, follow these steps carefully:
-
-Git Safety Protocol:
-- NEVER update the git config
-- NEVER run destructive git commands (push --force, reset --hard, checkout ., restore ., clean -f, branch -D) unless the user explicitly requests these actions. Taking unauthorized destructive actions is unhelpful and can result in lost work, so it's best to ONLY run these commands when given direct instructions 
-- NEVER skip hooks (--no-verify, --no-gpg-sign, etc) unless the user explicitly requests it
-- NEVER run force push to main/master, warn the user if they request it
-- CRITICAL: Always create NEW commits rather than amending, unless the user explicitly requests a git amend. When a pre-commit hook fails, the commit did NOT happen — so --amend would modify the PREVIOUS commit, which may result in destroying work or losing previous changes. Instead, after hook failure, fix the issue, re-stage, and create a NEW commit
-- When staging files, prefer adding specific files by name rather than using "git add -A" or "git add .", which can accidentally include sensitive files (.env, credentials) or large binaries
-- NEVER commit changes unless the user explicitly asks you to. It is VERY IMPORTANT to only commit when explicitly asked, otherwise the user will feel that you are being too proactive
-
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel, each using the Bash tool:
-  - Run a git status command to see all untracked files. IMPORTANT: Never use the -uall flag as it can cause memory issues on large repos.
-  - Run a git diff command to see both staged and unstaged changes that will be committed.
-  - Run a git log command to see recent commit messages, so that you can follow this repository's commit message style.
-2. Analyze all staged changes (both previously staged and newly added) and draft a commit message:
-  - Summarize the nature of the changes (eg. new feature, enhancement to an existing feature, bug fix, refactoring, test, docs, etc.). Ensure the message accurately reflects the changes and their purpose (i.e. "add" means a wholly new feature, "update" means an enhancement to an existing feature, "fix" means a bug fix, etc.).
-  - Do not commit files that likely contain secrets (.env, credentials.json, etc). Warn the user if they specifically request to commit those files
-  - Draft a concise (1-2 sentences) commit message that focuses on the "why" rather than the "what"
-  - Ensure it accurately reflects the changes and their purpose
-3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands:
-   - Add relevant untracked files to the staging area.
-   - Create the commit with a message ending with:
-   Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-   - Run git status after the commit completes to verify success.
-   Note: git status depends on the commit completing, so run it sequentially after the commit.
-4. If the commit fails due to pre-commit hook: fix the issue and create a NEW commit
-
-Important notes:
-- NEVER run additional commands to read or explore code, besides git bash commands
-- NEVER use the TodoWrite or Agent tools
-- DO NOT push to the remote repository unless the user explicitly asks you to do so
-- IMPORTANT: Never use git commands with the -i flag (like git rebase -i or git add -i) since they require interactive input which is not supported.
-- IMPORTANT: Do not use --no-edit with git rebase commands, as the --no-edit flag is not a valid option for git rebase.
-- If there are no changes to commit (i.e., no untracked files and no modifications), do not create an empty commit
-- In order to ensure good formatting, ALWAYS pass the commit message via a HEREDOC, a la this example:
-<example>
-git commit -m "$(cat <<'EOF'
-   Commit message here.
-
-   Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
-   EOF
-   )"
-</example>
+## Parametre
 
-# Creating pull requests
-Use the gh command via the Bash tool for ALL GitHub-related tasks including working with issues, pull requests, checks, and releases. If given a Github URL use the gh command to get the information needed.
+- `command` (string, påkrævet): Den nøjagtige shell-kommando, der skal udføres.
+- `description` (string, påkrævet): En kort, aktiv opsummering (5-10 ord for simple kommandoer; mere kontekst for piped eller obskure).
+- `timeout` (number, valgfri): Timeout i millisekunder, op til `600000` (10 minutter). Standard er `120000` (2 minutter).
+- `run_in_background` (boolean, valgfri): Når `true`, kører kommandoen frakoblet, og du modtager en notifikation ved afslutning. Tilføj ikke selv `&`.
 
-IMPORTANT: When the user asks you to create a pull request, follow these steps carefully:
+## Eksempler
 
-1. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following bash commands in parallel using the Bash tool, in order to understand the current state of the branch since it diverged from the main branch:
-   - Run a git status command to see all untracked files (never use -uall flag)
-   - Run a git diff command to see both staged and unstaged changes that will be committed
-   - Check if the current branch tracks a remote branch and is up to date with the remote, so you know if you need to push to the remote
-   - Run a git log command and `git diff [base-branch]...HEAD` to understand the full commit history for the current branch (from the time it diverged from the base branch)
-2. Analyze all changes that will be included in the pull request, making sure to look at all relevant commits (NOT just the latest commit, but ALL commits that will be included in the pull request!!!), and draft a pull request title and summary:
-   - Keep the PR title short (under 70 characters)
-   - Use the description/body for details, not the title
-3. You can call multiple tools in a single response. When multiple independent pieces of information are requested and all commands are likely to succeed, run multiple tool calls in parallel for optimal performance. run the following commands in parallel:
-   - Create new branch if needed
-   - Push to remote with -u flag if needed
-   - Create PR using gh pr create with the format below. Use a HEREDOC to pass the body to ensure correct formatting.
-<example>
-gh pr create --title "the pr title" --body "$(cat <<'EOF'
-## Summary
-<1-3 bullet points>
+### Eksempel 1: Inspicér repo-status før commit
+Udsted `git status` og `git diff --stat` som to parallelle `Bash`-kald i samme besked for hurtigt at indsamle kontekst, og saml derefter commit'en i et opfølgende kald.
 
-## Test plan
-[Bulleted markdown checklist of TODOs for testing the pull request...]
+### Eksempel 2: Kæd afhængige build-trin
+Brug et enkelt kald som `npm ci && npm run build && npm test`, så hvert trin kun kører, efter det forrige lykkedes. Brug kun `;`, hvis du bevidst vil have senere trin til at køre selv efter fejl.
 
-🤖 Generated with [Claude Code](https://claude.com/claude-code)
-EOF
-)"
-</example>
+### Eksempel 3: Langvarig dev-server
+Kald `npm run dev` med `run_in_background: true`. Du får besked, når den afslutter. Poll ikke med `sleep`-løkker; diagnosticér fejl i stedet for at prøve igen blindt.
 
-Important:
-- DO NOT use the TodoWrite or Agent tools
-- Return the PR URL when you're done, so the user can see it
+## Noter
 
-# Other common operations
-- View comments on a Github PR: gh api repos/foo/bar/pulls/123/comments</textarea>
+- Arbejdsmappen vedvarer mellem kald, men shell-tilstand (eksporterede variabler, shell-funktioner, aliasser) gør ikke. Foretræk absolutte stier, og undgå `cd`, medmindre brugeren beder om det.
+- Foretræk dedikerede værktøjer frem for piped shell-ækvivalenter: `Glob` i stedet for `find`/`ls`, `Grep` i stedet for `grep`/`rg`, `Read` i stedet for `cat`/`head`/`tail`, `Edit` i stedet for `sed`/`awk`, `Write` i stedet for `echo >` eller heredocs, og almindelig assistenttekst i stedet for `echo`/`printf` til brugervendt output.
+- Sæt enhver sti, der indeholder mellemrum, i dobbelte anførselstegn (for eksempel `"/Users/me/My Project/file.txt"`).
+- For uafhængige kommandoer skal du lave flere `Bash`-værktøjskald parallelt i en enkelt besked. Kæd kun med `&&`, når én kommando afhænger af en anden.
+- Output over 30000 tegn bliver afkortet. Når du fanger store logs, omdirigér til en fil og læs den derefter med `Read`-værktøjet.
+- Brug aldrig interaktive flag som `git rebase -i` eller `git add -i`; de kan ikke modtage input gennem dette værktøj.
+- Spring ikke git-hooks over (`--no-verify`, `--no-gpg-sign`), og udfør ikke destruktive operationer (`reset --hard`, `push --force`, `clean -f`), medmindre brugeren udtrykkeligt beder om det.

package/concepts/da/Tool-CronCreate.md

@@ -0,0 +1,57 @@
+# CronCreate
+
+Planlæg et prompt til at blive sat i kø på et fremtidigt tidspunkt, enten som en enkelt udførelse eller som en tilbagevendende opgave. Anvender standard 5-felt cron-syntaks i brugerens lokale tidszone — ingen tidszonekonvertering er nødvendig.
+
+## Hvornår skal den bruges
+
+- **Engangs-påmindelser**: Når en bruger vil mindes om noget på et bestemt tidspunkt ("mind mig om det i morgen kl. 15"). Med `recurring: false` slettes opgaven automatisk efter udførelse.
+- **Tilbagevendende tidsplaner**: Når noget skal udføres gentagne gange ("hver hverdag kl. 9", "hvert 30. minut"). Standardværdien `recurring: true` dækker dette tilfælde.
+- **Autonome agent-løkker**: Til arbejdsgange der skal genaktivere sig selv efter en tidsplan — f.eks. daglige resuméer eller periodiske statustjek.
+- **Varige opgaver**: Når tidsplanen skal overleve en sessionsgenstart. Med `durable: true` gemmes opgaven i `.claude/scheduled_tasks.json`.
+- **Omtrentlige tidspunkter**: Når brugeren siger "omkring kl. 9" eller "hver time", bør man vælge en forskudt minutværdi (f.eks. `57 8 * * *` eller `7 * * * *`) for at undgå at mange brugere aktiverer på :00 eller :30 samtidigt.
+
+## Parametre
+
+- `cron` (string, påkrævet): 5-felt cron-udtryk i brugerens lokale tidszone. Format: `minut time dag-i-måneden måned ugedag`. Eksempel: `"0 9 * * 1-5"` betyder mandag–fredag kl. 9:00.
+- `prompt` (string, påkrævet): Den prompttekst, der sættes i kø, når cron udløses — den præcise besked, der sendes til REPL på det planlagte tidspunkt.
+- `recurring` (boolean, valgfri, standard `true`): Med `true` køres jobbet ved hvert matchende cron-interval og udløber automatisk efter 7 dage. Med `false` køres jobbet præcis én gang og slettes derefter — til engangs-påmindelser.
+- `durable` (boolean, valgfri, standard `false`): Med `false` lever tidsplanen kun i hukommelsen og forsvinder, når sessionen afsluttes. Med `true` gemmes opgaven i `.claude/scheduled_tasks.json` og overlever genstarter.
+
+## Eksempler
+
+### Eksempel 1: engangs-påmindelse
+
+Brugeren siger: "Mind mig om at sende den ugentlige rapport i morgen kl. 14:30." Hvis i morgen er den 21. april:
+
+```json
+{
+  "cron": "30 14 21 4 *",
+  "prompt": "Påmindelse: send den ugentlige rapport nu.",
+  "recurring": false,
+  "durable": true
+}
+```
+
+`recurring: false` sikrer, at opgaven sletter sig selv efter udførelse. `durable: true` bevarer den på tværs af eventuelle genstarter inden da.
+
+### Eksempel 2: tilbagevendende hverdagsmorgen-opgave
+
+Brugeren siger: "Opsummer mine åbne GitHub-issues hver hverdag om morgenen."
+
+```json
+{
+  "cron": "3 9 * * 1-5",
+  "prompt": "Opsummer alle åbne GitHub-issues tildelt mig.",
+  "recurring": true,
+  "durable": true
+}
+```
+
+Minut `3` i stedet for `0` undgår belastningsspidsen på heltimer. Jobbet udløber automatisk efter 7 dage.
+
+## Noter
+
+- **Automatisk udløb efter 7 dage**: Tilbagevendende job slettes automatisk efter højst 7 dage. Genskab opgaven inden udløbet, hvis du har brug for en længere tidsplan.
+- **Udløses kun i tomgang**: `CronCreate` sætter prompten i kø kun når REPL ikke behandler en anden forespørgsel. Hvis REPL er optaget på udløsningstidspunktet, venter prompten til den aktuelle forespørgsel er afsluttet.
+- **Undgå :00 og :30**: For omtrentlige tidspunkter bør man bevidst vælge forskudte minutværdier for at fordele systembelastningen. Reserver :00/:30 kun til tilfælde, hvor brugeren angiver det præcise minut.
+- **Ingen tidszonekonvertering**: Cron-udtrykket fortolkes direkte i brugerens lokale tidszone. Der er ikke behov for at konvertere til UTC eller en anden tidszone.

package/concepts/da/Tool-CronDelete.md

@@ -0,0 +1,43 @@
+# CronDelete
+
+Annullerer et cron-job, der tidligere er planlagt med `CronCreate`. Fjerner det øjeblikkeligt fra den in-memory sessionslager. Har ingen effekt, hvis jobbet allerede er blevet automatisk slettet (enkeltudløsende job fjernes efter udløsning, tilbagevendende job udløber efter 7 dage).
+
+## Hvornår skal den bruges
+
+- En bruger beder om at stoppe en tilbagevendende planlagt opgave inden den automatiske udløb efter 7 dage.
+- Et enkeltudløsende job er ikke længere nødvendigt og skal annulleres, inden det udløses.
+- Tidsplanudtrykket for et eksisterende job skal ændres — slet det med `CronDelete`, og opret det derefter igen med `CronCreate` ved hjælp af det nye udtryk.
+- Rydde op i flere forældede job for at holde sessionsslageret ryddeligt.
+
+## Parametre
+
+- `id` (string, påkrævet): Job-ID'et returneret af `CronCreate`, da jobbet første gang blev oprettet. Denne værdi skal matche præcist; uklar søgning eller navnebaseret opslag understøttes ikke.
+
+## Eksempler
+
+### Eksempel 1: annuller et kørende tilbagevendende job
+
+Et tilbagevendende job blev tidligere oprettet med ID `"cron_abc123"`. Brugeren beder om at stoppe det.
+
+```
+CronDelete({ id: "cron_abc123" })
+```
+
+Jobbet fjernes fra sessionsslageret og vil ikke udløses igen.
+
+### Eksempel 2: fjern et forældet enkeltudløsende job, inden det udløses
+
+Et enkeltudløsende job med ID `"cron_xyz789"` var planlagt til at køre om 30 minutter, men brugeren har besluttet, at det ikke længere er nødvendigt.
+
+```
+CronDelete({ id: "cron_xyz789" })
+```
+
+Jobbet annulleres. Der vil ikke blive udført nogen handling, når det oprindelige udløsningstidspunkt nås.
+
+## Noter
+
+- `id` skal hentes fra returværdien af `CronCreate`. Der er ingen måde at slå et job op efter beskrivelse eller callback — gem ID'et, hvis du måske har brug for at annullere det senere.
+- Hvis jobbet allerede er blevet automatisk slettet (udløst som et enkeltudløsende job eller nået den tilbagevendende udløb efter 7 dage), er kald af `CronDelete` med det ID en no-op og producerer ikke en fejl.
+- `CronDelete` påvirker kun den aktuelle in-memory session. Hvis kørselsomgivelsen ikke bevarer cron-tilstanden på tværs af genstarter, vil planlagte job gå tabt ved genstart, uanset om `CronDelete` blev kaldt.
+- Der er ingen masseoperationer for sletning; annuller hvert job individuelt ved hjælp af dets eget `id`.

package/concepts/da/Tool-CronList.md

@@ -0,0 +1,30 @@
+# CronList
+
+Viser alle cron-jobs planlagt via `CronCreate` i den aktuelle session. Returnerer et overblik over hvert aktivt cron-job, herunder `id`, cron-udtryk, forkortet `prompt`, `recurring`-flag, `durable`-flag og naeste udlosningstidspunkt.
+
+## Hvornår skal den bruges
+
+- For at gennemse alle aktuelt planlagte jobs, inden der foretages aendringer eller sessionen afsluttes.
+- For at finde det korrekte `id` pa et job, inden `CronDelete` kaldes for at slette det.
+- For at fejlfinde, hvorfor et forventet job aldrig blev udlost, ved at bekrafte dets eksistens og kontrollere naeste udlosningstidspunkt.
+- For at bekrafte, at et engangsjob (ikke-tilbagevendende) endnu ikke er blevet udlost og stadig afventer udforsel.
+
+## Parametre
+
+Ingen.
+
+## Eksempler
+
+### Eksempel 1: gennemse alle planlagte jobs
+
+Kald `CronList` uden argumenter for at hente den komplette liste over alle aktive cron-jobs. Svaret indeholder for hvert job dets `id`, det cron-udtryk der definerer planen, en forkortet udgave af det `prompt` det vil udfore, om det er `recurring` (tilbagevendende), om det er `durable` (vedvarende pa tvars af genstarter) og naeste planlagte udlosningstidspunkt.
+
+### Eksempel 2: find id'et pa en bestemt tilbagevendende opgave
+
+Hvis der er oprettet flere cron-jobs og et bestemt tilbagevendende job skal slettes, skal `CronList` kaldes forst. Gennemsa den returnerede liste for at finde det job, hvis `prompt`-oversigt og cron-udtryk matcher den opgave, der skal fjernes. Kopieer dets `id` og send det til `CronDelete`.
+
+## Noter
+
+- Kun jobs oprettet i den aktuelle session vises, medmindre de er oprettet med `durable: true`, som gor det muligt for dem at overleve sessionsgenstart.
+- Feltet `prompt` i oversigtsen er forkortet; det viser kun begyndelsen af den fulde prompttekst, ikke hele indholdet.
+- Engangsjobs (`recurring` er `false`), der allerede er blevet udlost, slettes automatisk og vises ikke laengere pa listen.

package/concepts/da/Tool-Edit.md

@@ -1,46 +1,38 @@
 # Edit
 
-## Definition
+Udfører en nøjagtig strengudskiftning inden for en eksisterende fil. Det er den foretrukne måde at ændre filer på, fordi kun diff'en sendes, hvilket holder redigeringer præcise og reviderbare.
 
-Redigerer filer via præcis strengerstatning. Erstatter `old_string` med `new_string` i filen.
+## Hvornår skal den bruges
 
-## Parametre
-
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `file_path` | string | Ja | Absolut sti til filen der skal ændres |
-| `old_string` | string | Ja | Originaltekst der skal erstattes |
-| `new_string` | string | Ja | Ny erstatningstekst (skal være forskellig fra old_string) |
-| `replace_all` | boolean | Nej | Om alle forekomster skal erstattes, standard `false` |
+- Rette en fejl i en enkelt funktion uden at omskrive den omgivende fil
+- Opdatere en konfigurationsværdi, versionsstreng eller importsti
+- Omdøbe et symbol på tværs af en fil med `replace_all`
+- Indsætte en blok i nærheden af et anker (udvid `old_string` til at inkludere nærliggende kontekst, og angiv derefter erstatningen)
+- Anvende små, velafgrænsede redigeringer som led i en refaktorering i flere trin
 
-## Brugsscenarier
+## Parametre
 
-**Egnet til:**
-- Ændre specifikke kodeafsnit i eksisterende filer
-- Rette fejl, opdatere logik
-- Omdøbe variabler (med `replace_all: true`)
-- Ethvert scenarie der kræver præcis ændring af filindhold
+- `file_path` (string, påkrævet): Absolut sti til den fil, der skal ændres.
+- `old_string` (string, påkrævet): Den eksakte tekst, der skal søges efter. Skal matche tegn for tegn, inklusive mellemrum og indrykning.
+- `new_string` (string, påkrævet): Erstatningsteksten. Skal afvige fra `old_string`.
+- `replace_all` (boolean, valgfri): Når `true`, erstattes hver forekomst af `old_string`. Standard er `false`, hvilket kræver, at matchet er unikt.
 
-**Ikke egnet til:**
-- Oprette nye filer — brug Write
-- Omfattende omskrivninger — kan kræve Write til at overskrive hele filen
+## Eksempler
 
-## Bemærkninger
+### Eksempel 1: Ret et enkelt kaldssted
+Sæt `old_string` til den eksakte linje `const port = 3000;` og `new_string` til `const port = process.env.PORT ?? 3000;`. Matchet er unikt, så `replace_all` kan forblive på standardværdien.
 
-- Filen skal først være læst via Read, ellers opstår en fejl
-- `old_string` skal være unik i filen, ellers fejler redigeringen. Hvis den ikke er unik, angiv mere kontekst for at gøre den unik, eller brug `replace_all`
-- Ved redigering af tekst skal den originale indrykning (tab/mellemrum) bevares; medtag ikke linjenummerpræfikset fra Read-output
-- Foretræk redigering af eksisterende filer frem for at oprette nye
-- `new_string` skal være forskellig fra `old_string`
+### Eksempel 2: Omdøb et symbol på tværs af en fil
+For at omdøbe `getUser` til `fetchUser` overalt i `api.ts` sættes `old_string: "getUser"`, `new_string: "fetchUser"` og `replace_all: true`.
 
-## Originaltekst
+### Eksempel 3: Disambiguér et gentaget uddrag
+Hvis `return null;` forekommer i flere grene, udvides `old_string` til at inkludere omgivende kontekst (for eksempel den foregående `if`-linje), så matchet er unikt. Ellers fejler værktøjet i stedet for at gætte.
 
-<textarea readonly>Performs exact string replacements in files.
+## Noter
 
-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>
+- Du skal kalde `Read` på filen mindst én gang i den aktuelle session, før `Edit` accepterer ændringer. Linjenummer-præfikser fra `Read`-output er ikke en del af filindholdet; inkludér dem ikke i `old_string` eller `new_string`.
+- Mellemrum skal matche nøjagtigt. Vær opmærksom på tabulatorer versus mellemrum og efterstillede mellemrum, især i YAML, Makefiles og Python.
+- Hvis `old_string` ikke er unik og `replace_all` er `false`, fejler redigeringen. Udvid enten konteksten eller aktivér `replace_all`.
+- Foretræk `Edit` frem for `Write`, når filen allerede findes; `Write` overskriver hele filen og mister urelateret indhold, hvis du ikke er forsigtig.
+- Til flere urelaterede redigeringer i samme fil skal du udstede flere `Edit`-kald i rækkefølge i stedet for én stor, skrøbelig erstatning.
+- Undgå at indføre emoji, marketingtekst eller uanmodede dokumentationsblokke ved redigering af kildefiler.

package/concepts/da/Tool-EnterPlanMode.md

@@ -1,128 +1,35 @@
 # EnterPlanMode
 
-## Definition
+Skifter sessionen til plantilstand, en skrivebeskyttet udforskningsfase, hvor assistenten undersøger kodebasen og udarbejder en konkret implementeringsplan, som brugeren kan godkende, før filer ændres.
 
-Skifter Claude Code til planlægningstilstand, der bruges til at udforske kodebasen og designe en plan før implementering.
+## Hvornår skal den bruges
 
-## Parametre
-
-Ingen parametre.
-
-## Brugsscenarier
-
-**Egnet til:**
-- Implementering af nye funktioner — kræver arkitekturbeslutninger
-- Der findes flere mulige tilgange — kræver brugerens valg
-- Kodeændringer påvirker eksisterende adfærd eller struktur
-- Ændringer i flere filer — involverer potentielt 2-3 eller flere filer
-- Uklare krav — nødvendigt at udforske først for at forstå omfanget
-- Brugerpræferencer er vigtige — implementeringen kan have flere rimelige retninger
-
-**Ikke egnet til:**
-- Rettelser af én eller få linjer (stavefejl, åbenlyse fejl)
-- Brugeren har givet meget specifikke instruktioner
-- Rene forsknings-/udforskningsopgaver — brug Task (Explore-type)
-
-## Adfærd i planlægningstilstand
-
-Efter at være gået ind i planlægningstilstand vil Claude Code:
-1. Bruge Glob-, Grep-, Read-værktøjer til at udforske kodebasen i dybden
-2. Forstå eksisterende mønstre og arkitektur
-3. Designe implementeringsplanen
-4. Indsende planen til brugerens godkendelse
-5. Bruge AskUserQuestion til afklaring om nødvendigt
-6. Forlade tilstanden via ExitPlanMode, når planen er klar
-
-## Bemærkninger
-
-- Dette værktøj kræver brugerens samtykke for at gå ind i planlægningstilstand
-- Hvis du er i tvivl om, hvorvidt planlægning er nødvendig, foretrækkes planlægning — at afstemme på forhånd er bedre end at lave om
-
-## Originaltekst
-
-<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?
+- Brugeren beder om en ikke-triviel ændring, der spænder over flere filer eller undersystemer.
+- Kravene er tvetydige, og assistenten skal læse kode, før den forpligter sig til en tilgang.
+- En refaktorering, migration eller afhængighedsopgradering foreslås, og konsekvensradius er uklar.
+- Brugeren siger udtrykkeligt "planlæg dette", "lad os planlægge først" eller anmoder om en designgennemgang.
+- Risikoen er høj nok til, at det ville være spild af arbejde eller beskadige tilstanden at gå direkte til redigeringer.
 
-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
+## Parametre
 
-User: "Implement dark mode"
-- Architectural decision on theme system, affects many components
+Ingen. `EnterPlanMode` tager ingen argumenter — kald den med et tomt parameterobjekt.
 
-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
+## Eksempler
 
-User: "Update the error handling in the API"
-- Affects multiple files, user should approve the approach
+### Eksempel 1: Stor featureanmodning
 
-### BAD - Don't use EnterPlanMode:
-User: "Fix the typo in the README"
-- Straightforward, no planning needed
+Brugeren beder om: "Tilføj SSO via Okta til adminpanelet." Assistenten kalder `EnterPlanMode` og bruger derefter flere runder på at læse auth-middleware, session-storage, rute-guards og eksisterende login-UI. Den skriver en plan, der beskriver nødvendige ændringer, migrationstrin og testdækning, og indsender derefter via `ExitPlanMode` til godkendelse.
 
-User: "Add a console.log to debug this function"
-- Simple, obvious implementation
+### Eksempel 2: Risikabel refaktorering
 
-User: "What files handle routing?"
-- Research task, not implementation planning
+Brugeren siger: "Konvertér REST-controllerne til tRPC." Assistenten går i plantilstand, undersøger hver controller, katalogiserer den offentlige kontrakt, oplister udrulningsfaser (shim, dual-read, cutover) og foreslår en sekventeringsplan, før nogen fil berøres.
 
-## Important Notes
+## Noter
 
-- 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>
+- Plantilstand er skrivebeskyttet pr. kontrakt. Mens inde i den må assistenten ikke køre `Edit`, `Write`, `NotebookEdit` eller nogen muterende shell-kommando. Brug kun `Read`, `Grep`, `Glob` og ikke-destruktive `Bash`-kommandoer.
+- Gå ikke i plantilstand for trivielle one-liner-redigeringer, rene researchspørgsmål eller opgaver, hvor brugeren allerede har specificeret ændringen i fuld detalje. Omkostningen skader mere, end den hjælper.
+- Under Auto-tilstand frarådes plantilstand, medmindre brugeren udtrykkeligt beder om det — Auto-tilstand foretrækker handling frem for forudgående planlægning.
+- Brug plantilstand til at reducere kurskorrektioner på dyrt arbejde. En fem-minutters plan sparer ofte en time med fejlretningsorienterede redigeringer.
+- Når først i plantilstand, skal undersøgelsen fokusere på de dele af systemet, der faktisk vil ændre sig. Undgå udtømmende ture i dele af repoet, der ikke er relateret til opgaven.
+- Selve planen bør skrives til disk på den sti, rammen forventer, så `ExitPlanMode` kan indsende den. Planen bør indeholde konkrete filstier, funktionsnavne og verifikationstrin, ikke vag hensigt.
+- Brugeren kan afvise planen og bede om revisioner. Itererér inde i plantilstand, indtil planen accepteres; afslut først derefter.