cc-viewer 1.6.182 → 1.6.183

package/concepts/no/Tool-EnterWorktree.md

@@ -1,56 +1,44 @@
 # EnterWorktree
 
-## Definisjon
+Oppretter et isolert Git-worktree på en ny branch, eller bytter sesjonen inn i et eksisterende worktree av gjeldende repository, slik at parallelt eller eksperimentelt arbeid kan pågå uten å berøre hovedutsjekken.
 
-Creates an isolated git worktree and switches the current session into it. Only used when the user explicitly asks to work in a worktree.
+## Når skal den brukes
 
-## Parametere
-
-| Name | Type | Required | Description |
-|---|---|---|---|
-| name | string | No | A name for the worktree. If not provided, a random name is generated. |
-
-## Brukstilfeller
-
-**Egnet for:**
-- The user explicitly says "worktree" (e.g., "start a worktree", "work in a worktree", "create a worktree")
-
-**Ikke egnet for:**
-- 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
+- Brukeren sier eksplisitt "worktree" — for eksempel "start et worktree", "opprett et worktree" eller "jobb i et worktree".
+- Prosjektinstruksjoner i `CLAUDE.md` eller vedvarende minne peker på at du skal bruke et worktree for gjeldende oppgave.
+- Du vil fortsette en oppgave som tidligere ble satt opp som et worktree (send `path` for å gå inn igjen).
+- Flere eksperimentelle branches må sameksistere på disk uten stadig utsjekkskifte.
+- En langvarig oppgave bør isoleres fra urelaterte endringer i hovedarbeidstreet.
 
-## Merknader
-
-- 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.
+## Parametere
 
-## When to Use
+- `name` (string, valgfri): Navn på en ny worktree-katalog. Hvert `/`-separerte segment kan kun inneholde bokstaver, tall, punktum, understreker og bindestreker; hele strengen er begrenset til 64 tegn. Hvis utelatt og `path` også er utelatt, genereres et tilfeldig navn. Gjensidig utelukkende med `path`.
+- `path` (string, valgfri): Filsystemsti til et eksisterende worktree av gjeldende repository som sesjonen skal bytte til. Må vises i `git worktree list` for dette repoet; stier som ikke er registrerte worktrees av gjeldende repo avvises. Gjensidig utelukkende 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: Opprett et nytt worktree med 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
+Oppretter `.claude/worktrees/feat/okta-sso` på en ny branch basert på `HEAD`, og bytter deretter sesjonens arbeidskatalog inn i det. Alle påfølgende filredigeringer og shell-kommandoer opererer inne i worktreet til du avslutter.
 
-- 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å tilbake inn i et eksisterende worktree
 
-## 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
+Gjenopptar arbeidet i et tidligere opprettet worktree. Fordi du gikk inn via `path`, vil `ExitWorktree` ikke slette det automatisk — å forlate med `action: "keep"` returnerer ganske enkelt til den opprinnelige katalogen.
 
-## Parameters
+## Notater
 
-- `name` (optional): A name for the worktree. If not provided, a random name is generated.
-</textarea>
+- Ikke kall `EnterWorktree` med mindre brukeren eksplisitt har bedt om det eller prosjektinstruksjoner krever det. Vanlig branch-bytte eller feilrettingsforespørsler bør bruke normale Git-kommandoer, ikke worktrees.
+- Når den kalles inne i et Git-repository, oppretter verktøyet et worktree under `.claude/worktrees/` og registrerer en ny branch basert på `HEAD`. Utenfor et Git-repository delegerer det til konfigurerte `WorktreeCreate` / `WorktreeRemove` hooks i `settings.json` for VCS-agnostisk isolasjon.
+- Kun én worktree-sesjon er aktiv om gangen. Verktøyet nekter å kjøre hvis du allerede er inne i en worktree-sesjon; avslutt først med `ExitWorktree`.
+- Bruk `ExitWorktree` for å forlate midt i sesjonen. Hvis sesjonen avsluttes mens du fortsatt er inne i et nyopprettet worktree, blir brukeren spurt om å beholde eller fjerne det.
+- Worktrees man går inn i via `path` regnes som eksterne — `ExitWorktree` med `action: "remove"` vil ikke slette dem. Dette er et sikkerhetsrekkverk for å beskytte worktrees brukeren administrerer manuelt.
+- Et nytt worktree arver innholdet til gjeldende branch, men har en uavhengig arbeidskatalog og indeks. Stagede og ustagede endringer i hovedutsjekken er ikke synlige inne i worktreet.
+- Navnetips: prefiks med type arbeid (`feat/`, `fix/`, `spike/`) slik at flere samtidige worktrees er enkle å skille i `git worktree list`.

package/concepts/no/Tool-ExitPlanMode.md

@@ -1,62 +1,42 @@
 # ExitPlanMode
 
-## Definisjon
+Sender inn implementasjonsplanen som ble utarbeidet i planmodus til brukergodkjenning, og — hvis godkjent — overfører sesjonen ut av planmodus slik at redigeringer kan begynne.
 
-Går ut av planleggingsmodus og sender planen til brukeren for godkjenning. Planinnholdet leses fra planfilen som ble skrevet tidligere.
+## Når skal den brukes
 
-## Parametere
-
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `allowedPrompts` | array | Nei | Liste over tillatelsesbeskrivelser som kreves for implementeringsplanen |
-
-Hvert element i `allowedPrompts`-arrayen:
-
-| Felt | Type | Påkrevd | Beskrivelse |
-|------|------|---------|-------------|
-| `tool` | enum | Ja | Gjeldende verktøy, for øyeblikket støttes kun `Bash` |
-| `prompt` | string | Ja | Semantisk beskrivelse av operasjonen (f.eks. "run tests", "install dependencies") |
+- En plan skrevet under `EnterPlanMode` er fullført og klar til gjennomgang.
+- Oppgaven er implementasjonsfokusert (kode- eller konfigurasjonsendringer), ikke ren research, så en eksplisitt plan er hensiktsmessig.
+- All forberedende lesing og analyse er gjort; ingen ytterligere undersøkelse er nødvendig før brukeren bestemmer.
+- Assistenten har listet opp konkrete filbaner, funksjoner og steg — ikke bare mål.
+- Brukeren har bedt om å se planen, eller plan-modus-arbeidsflyten er i ferd med å levere stafettpinnen videre til redigeringsverktøy.
 
-## Bruksscenarioer
-
-**Egnet for bruk:**
-- Planen er ferdig i planleggingsmodus og klar til å sendes for brukergodkjenning
-- Brukes kun for implementeringsoppgaver som krever kodeskriving
-
-**Ikke egnet for bruk:**
-- Rene forsknings-/utforskningsoppgaver — trenger ikke å gå ut av planleggingsmodus
-- Spørre "er planen OK?" — dette er nettopp funksjonen til dette verktøyet, ikke bruk AskUserQuestion for det
-
-## Merknader
+## Parametere
 
-- Dette verktøyet aksepterer ikke planinnhold som parameter — det leser fra planfilen som ble skrevet tidligere
-- Brukeren vil se innholdet i planfilen for godkjenning
-- Ikke bruk AskUserQuestion før du kaller dette verktøyet for å spørre "er planen OK", det er overflødig
-- Ikke nevn "planen" i spørsmål, fordi brukeren ikke ser planinnholdet før ExitPlanMode
+- `allowedPrompts` (array, valgfri): Prompter brukeren kan skrive på godkjenningsskjermen for å auto-godkjenne eller endre planen. Hvert element spesifiserer en avgrenset tillatelse (for eksempel et operasjonsnavn og verktøyet det gjelder for). La stå usatt for å bruke standard godkjenningsflyt.
 
-## 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: Standard innsendelse
 
-## 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
+Etter å ha undersøkt en autentiseringsrefaktorering inne i planmodus og skrevet planfilen til disk, kaller assistenten `ExitPlanMode` uten argumenter. Rammeverket leser planen fra dens kanoniske plassering, viser den til brukeren og venter på godkjenning eller avslag.
 
-## 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åndsgodkjente 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.
+Lar brukeren gi tillatelse på forhånd for rutinemessige oppfølgingskommandoer, slik at assistenten ikke trenger å pause for hver tillatelsesforespørsel under implementering.
 
-## Examples
+## Notater
 
-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` gir kun mening for implementasjonsorientert arbeid. Hvis brukerens forespørsel er en research- eller forklaringsoppgave uten filendringer, svar direkte i stedet — ikke rut gjennom planmodus bare for å avslutte den.
+- Planen må allerede være skrevet til disk før dette verktøyet kalles. `ExitPlanMode` aksepterer ikke plankroppen som parameter; den leser fra stien rammeverket forventer.
+- Hvis brukeren avviser planen, returnerer du til planmodus. Revider basert på tilbakemeldingene og send inn på nytt; ikke begynn å redigere filer mens planen er ugodkjent.
+- Godkjenning gir tillatelse til å forlate planmodus og bruke muterende verktøy (`Edit`, `Write`, `Bash` og så videre) for omfanget beskrevet i planen. Utvidelse av omfang i etterkant krever en ny plan eller eksplisitt brukersamtykke.
+- Ikke bruk `AskUserQuestion` for å spørre "ser denne planen bra ut?" før du kaller dette verktøyet — å be om plangodkjenning er nøyaktig det `ExitPlanMode` gjør, og brukeren kan ikke se planen før den sendes inn.
+- Hold planen minimal og handlingsrettet. En gjennomgangsperson bør kunne skumlese den på under ett minutt og forstå nøyaktig hva som vil endres.
+- Hvis du midt i implementeringen innser at planen var feil, stopp og rapporter tilbake til brukeren i stedet for å avvike i stillhet. Å gå inn i planmodus igjen er et gyldig neste steg.

package/concepts/no/Tool-ExitWorktree.md

@@ -0,0 +1,41 @@
+# ExitWorktree
+
+Avslutter en worktree-økt som tidligere ble opprettet av `EnterWorktree`, og returnerer økten til den opprinnelige arbeidsmappen. Dette verktøyet virker utelukkende på worktrees som er opprettet av `EnterWorktree` i gjeldende økt; er ingen slik økt aktiv, har kallet ingen effekt.
+
+## Når skal den brukes
+
+- Arbeidet i en isolert worktree er fullført og du ønsker å returnere til den primære arbeidsmappen.
+- En oppgave i en feature-branch-worktree er ferdig og etter sammenslåing ønsker du å rydde opp i grenen og mappen.
+- Du ønsker å beholde worktree til senere bruk og ganske enkelt returnere til den opprinnelige mappen uten å slette noe.
+- Du ønsker å forkaste en eksperimentell eller midlertidig gren uten å etterlate artefakter på disken.
+- Du må starte en ny `EnterWorktree`-økt, noe som krever at du først avslutter den gjeldende.
+
+## Parametere
+
+- `action` (streng, obligatorisk): `"keep"` beholder worktree-mappen og grenen på disken slik at du kan returnere til dem senere; `"remove"` sletter både mappen og grenen for en ren avslutning.
+- `discard_changes` (boolsk, valgfri, standard `false`): Kun relevant når `action` er `"remove"`. Inneholder worktree ucommittede filer eller commits som ikke finnes i den opprinnelige grenen, nekter verktøyet fjerning med mindre `discard_changes` er satt til `true`. Feilsvaret lister opp de aktuelle endringene slik at du kan bekrefte med brukeren før du kaller på nytt.
+
+## Eksempler
+
+### Eksempel 1: ren avslutning etter sammenslåing av endringer
+
+Etter å ha fullført arbeidet i en worktree og slått sammen grenen i main, kall `ExitWorktree` med `action: "remove"` for å slette worktree-mappen og grenen og returnere til den opprinnelige arbeidsmappen.
+
+```
+ExitWorktree(action: "remove")
+```
+
+### Eksempel 2: forkast en midlertidig worktree med ucommittet eksperimentell kode
+
+Inneholder en worktree eksperimentelle, ucommittede endringer som skal forkastes fullstendig, forsøk først `action: "remove"`. Verktøyet nekter og lister opp de ucommittede endringene. Etter bekreftelse fra brukeren om at endringene kan forkastes, kall på nytt med `discard_changes: true`.
+
+```
+ExitWorktree(action: "remove", discard_changes: true)
+```
+
+## Notater
+
+- Dette verktøyet virker utelukkende på worktrees opprettet av `EnterWorktree` i gjeldende økt. Det vil ikke påvirke worktrees opprettet med `git worktree add`, worktrees fra tidligere økter eller den vanlige arbeidsmappen dersom `EnterWorktree` aldri ble kalt — i disse tilfellene har kallet ingen effekt.
+- `action: "remove"` avvises hvis worktree har ucommittede endringer eller commits som ikke finnes i den opprinnelige grenen, med mindre `discard_changes: true` oppgis eksplisitt. Bekreft alltid med brukeren før du setter `discard_changes: true`, ettersom data ikke kan gjenopprettes.
+- Er en tmux-økt tilknyttet worktree: ved `remove` avsluttes den; ved `keep` fortsetter den å kjøre, og navnet returneres slik at brukeren kan koble seg til igjen senere.
+- Etter at `ExitWorktree` er fullført, kan `EnterWorktree` kalles igjen for å starte en ny worktree-økt.

package/concepts/no/Tool-Glob.md

@@ -1,39 +1,35 @@
 # Glob
 
-## Definisjon
+Matcher filnavn mot et glob-mønster og returnerer stiene sortert etter nyeste modifikasjonstidspunkt først. Optimalisert for raskt å lokalisere filer i kodebaser av enhver størrelse uten å shelle ut til `find`.
 
-Raskt filnavnmønstermatchingsverktøy som støtter kodebaser av enhver størrelse. Returnerer matchende filstier sortert etter endringstid.
+## Når skal den brukes
 
-## Parametere
+- Ramse opp hver fil med en bestemt filendelse (for eksempel alle `*.ts`-filer under `src`)
+- Oppdage konfigurasjons- eller fixturfiler etter navnekonvensjon (`**/jest.config.*`, `**/*.test.tsx`)
+- Snevre inn en søkeflate før du kjører en målrettet `Grep`
+- Sjekke om en fil allerede finnes på et kjent mønster før du kaller `Write`
+- Finne nylig berørte filer ved å stole på sortering etter modifikasjonstid
 
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `pattern` | string | Ja | Glob-mønster (f.eks. `**/*.js`, `src/**/*.ts`) |
-| `path` | string | Nei | Søkekatalog, standard er gjeldende arbeidskatalog. Ikke send "undefined" eller "null" |
+## Parametere
 
-## Bruksscenarioer
+- `pattern` (string, påkrevd): Glob-uttrykket som skal matches. Støtter `*` for enkeltsegment-jokertegn, `**` for rekursive treff og `{a,b}` for alternativer, for eksempel `src/**/*.{ts,tsx}`.
+- `path` (string, valgfri): Katalogen søket skal kjøres i. Må være en gyldig katalogsti når den oppgis. Utelat feltet helt for å søke i gjeldende arbeidskatalog. Ikke send inn strengene `"undefined"` eller `"null"`.
 
-**Egnet for bruk:**
-- Søke etter filer med filnavnmønster
-- Finne alle filer av en bestemt type (f.eks. alle `.tsx`-filer)
-- Lokalisere filer når du søker etter en bestemt klassedefinisjon (f.eks. `class Foo`)
-- Kan starte flere Glob-kall parallelt i en enkelt melding
+## Eksempler
 
-**Ikke egnet for bruk:**
-- Søke i filinnhold — bruk Grep
-- Åpen utforskning som krever flere søkerunder — bruk Task (Explore-type)
+### Eksempel 1: Hver TypeScript-kildefil
+Kall `Glob` med `pattern: "src/**/*.ts"`. Resultatet er en mtime-sortert liste, så de sist redigerte filene vises først, noe som er nyttig for å fokusere på hot spots.
 
-## Merknader
+### Eksempel 2: Lokaliser en kandidat for klassedefinisjon
+Når du mistenker at en klasse ligger i en fil med ukjent navn, søk med `pattern: "**/*UserService*"` for å snevre inn kandidatene, og følg opp med `Read` eller `Grep`.
 
-- Støtter standard glob-syntaks: `*` matcher ett nivå, `**` matcher flere nivåer, `{}` matcher flere valg
-- Resultater sortert etter endringstid
-- Anbefales fremfor `find`-kommandoen i Bash
+### Eksempel 3: Parallell oppdagelse før en større oppgave
+Send flere `Glob`-kall i én melding (for eksempel én for `**/*.test.ts` og én for `**/fixtures/**`) slik at begge kjører parallelt og resultatene kan korreleres.
 
-## Originaltekst
+## Notater
 
-<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 sortert etter filens modifikasjonstid (nyeste først), ikke alfabetisk. Sorter nedstrøms hvis du trenger stabil rekkefølge.
+- Mønstre evalueres av verktøyet, ikke av skallet; du trenger ikke sitere eller escape dem slik du ville gjort på kommandolinjen.
+- For åpen utforskning som krever flere runder med søk og resonnement, deleger til en `Agent` med Explore-agenttypen i stedet for å lenke mange `Glob`-kall.
+- Foretrekk `Glob` fremfor `Bash`-invokasjoner av `find` eller `ls` for filnavnsoppdagelse; det håndterer tillatelser konsekvent og returnerer strukturert utdata.
+- Når du leter etter innhold inne i filer i stedet for filnavn, bruk `Grep` i stedet.

package/concepts/no/Tool-Grep.md

@@ -1,57 +1,46 @@
 # Grep
 
-## Definisjon
+Søker i filinnhold med ripgrep-motoren. Tilbyr full støtte for regulære uttrykk, filtrering etter filtype og tre utdatamoduser slik at du kan bytte presisjon mot kompakthet.
 
-Kraftig innholdssøkverktøy bygget på ripgrep. Støtter regulære uttrykk, filtypfiltrering og flere utdatamoduser.
+## Når skal den brukes
+
+- Lokalisere hvert kallsted for en funksjon eller hver referanse til en identifikator
+- Sjekke om en streng eller feilmelding vises noe sted i kodebasen
+- Telle forekomster av et mønster for å vurdere påvirkning før refaktorering
+- Snevre inn et søk til en filtype (`type: "ts"`) eller glob (`glob: "**/*.tsx"`)
+- Hente treff på tvers av linjer, som flerlinjede struct-definisjoner eller JSX-blokker med `multiline: true`
 
 ## Parametere
 
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `pattern` | string | Ja | Søkemønster med regulært uttrykk |
-| `path` | string | Nei | Søkesti (fil eller katalog), standard er gjeldende arbeidskatalog |
-| `glob` | string | Nei | Filnavnfilter (f.eks. `*.js`, `*.{ts,tsx}`) |
-| `type` | string | Nei | Filtypfilter (f.eks. `js`, `py`, `rust`), mer effektivt enn glob |
-| `output_mode` | enum | Nei | Utdatamodus: `files_with_matches` (standard), `content`, `count` |
-| `-i` | boolean | Nei | Søk uten hensyn til store/små bokstaver |
-| `-n` | boolean | Nei | Vis linjenumre (kun content-modus), standard true |
-| `-A` | number | Nei | Antall linjer vist etter treff |
-| `-B` | number | Nei | Antall linjer vist før treff |
-| `-C` / `context` | number | Nei | Antall linjer vist før og etter treff |
-| `head_limit` | number | Nei | Begrens antall utdataoppføringer, standard 0 (ubegrenset) |
-| `offset` | number | Nei | Hopp over de første N resultatene |
-| `multiline` | boolean | Nei | Aktiver flerlinjematchingsmodus, standard false |
-
-## Bruksscenarioer
-
-**Egnet for bruk:**
-- Søke etter spesifikke strenger eller mønstre i kodebasen
-- Finne brukssteder for funksjoner/variabler
-- Filtrere søkeresultater etter filtype
-- Telle antall treff
-
-**Ikke egnet for bruk:**
-- Finne filer etter navn — bruk Glob
-- Åpen utforskning som krever flere søkerunder — bruk Task (Explore-type)
-
-## Merknader
-
-- Bruker ripgrep-syntaks (ikke grep), spesialtegn som krøllparenteser må escapes
-- `files_with_matches`-modus returnerer kun filstier, mest effektivt
-- `content`-modus returnerer innholdet i matchende linjer, med støtte for kontekstlinjer
-- Flerlinjematching krever at `multiline: true` settes
-- Foretrekk alltid Grep-verktøyet fremfor `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åkrevd): Det regulære uttrykket å søke etter. Bruker ripgrep-syntaks, så bokstavelige krøllparenteser må escapes (for eksempel `interface\{\}` for å finne `interface{}`).
+- `path` (string, valgfri): Fil eller katalog å søke i. Standard er gjeldende arbeidskatalog.
+- `glob` (string, valgfri): Filnavnsfilter som `*.js` eller `*.{ts,tsx}`.
+- `type` (string, valgfri): Snarvei for filtype som `js`, `py`, `rust`, `go`. Mer effektiv enn `glob` for standardspråk.
+- `output_mode` (enum, valgfri): `files_with_matches` (standard, returnerer kun stier), `content` (returnerer treffende linjer), eller `count` (returnerer treffantall).
+- `-i` (boolean, valgfri): Ikke skille mellom store og små bokstaver.
+- `-n` (boolean, valgfri): Inkluder linjenummer i `content`-modus. Standard er `true`.
+- `-A` (number, valgfri): Linjer med kontekst etter hvert treff (krever `content`-modus).
+- `-B` (number, valgfri): Linjer med kontekst før hvert treff (krever `content`-modus).
+- `-C` / `context` (number, valgfri): Linjer med kontekst på begge sider av hvert treff.
+- `multiline` (boolean, valgfri): Tillat mønstre å gå over linjeskift (`.` matcher `\n`). Standard er `false`.
+- `head_limit` (number, valgfri): Begrens returnerte linjer, filstier eller telleoppføringer. Standard er 250; send `0` for ubegrenset (bruk sparsomt).
+- `offset` (number, valgfri): Hopp over de første N resultatene før `head_limit` anvendes. Standard er `0`.
+
+## Eksempler
+
+### Eksempel 1: Finn alle kallsteder for en funksjon
+Sett `pattern: "registerHandler\\("`, `output_mode: "content"` og `-C: 2` for å se linjene rundt hvert kall.
+
+### Eksempel 2: Tell treff på tvers av en type
+Sett `pattern: "TODO"`, `type: "py"` og `output_mode: "count"` for å se totale TODO-tall per fil på tvers av Python-kilder.
+
+### Eksempel 3: Flerlinjers struct-treff
+Bruk `pattern: "struct Config \\{[\\s\\S]*?version"` med `multiline: true` for å fange et felt som er deklarert flere linjer inn i en Go-struct.
+
+## Notater
+
+- Foretrekk alltid `Grep` fremfor å kjøre `grep` eller `rg` via `Bash`; verktøyet er optimalisert for riktige tillatelser og strukturert utdata.
+- Standard utdatamodus er `files_with_matches`, som er billigst. Bytt til `content` kun når du trenger å se linjene selv.
+- Kontekstflagg (`-A`, `-B`, `-C`) ignoreres med mindre `output_mode` er `content`.
+- Store resultatsett brenner kontekstokens. Bruk `head_limit`, `offset` eller strammere `glob`/`type`-filtre for å holde fokus.
+- For filnavnsoppdagelse, bruk `Glob` i stedet; for åpne undersøkelser over mange runder, dispatch en `Agent` med Explore-agenten.

package/concepts/no/Tool-Monitor.md

@@ -0,0 +1,50 @@
+# Monitor
+
+Starter en bakgrunnsmonitor som strømmer hendelser fra et langvarig skript. Hver linje i standardutdata blir en varsling — fortsett å arbeide mens hendelser ankommer i chatten.
+
+## Når skal den brukes
+
+- Følge med på feil, advarsler eller krasj-signaturer i en loggfil mens et utrullingsoppdrag kjører
+- Spørre et eksternt API, en PR eller en CI-pipeline hvert 30. sekund for å oppdage nye statushendelser
+- Overvåke endringer i en filsystemmapp eller byggutdata i sanntid
+- Vente på en bestemt betingelse over mange iterasjoner (f.eks. en milepæl i et treningssteg eller tømming av en kø)
+- **Ikke** for enkelt "vent til ferdig" — bruk `Bash` med `run_in_background` for det; det sender én fullføringsvarsling når prosessen avsluttes
+
+## Parametere
+
+- `command` (streng, påkrevd): Shell-kommandoen eller skriptet som skal kjøres. Hver linje skrevet til standardutdata blir en separat varslershendelse. Monitoren avsluttes når prosessen avsluttes.
+- `description` (streng, påkrevd): En kort, lesbar etikett som vises i hver varsling. Vær spesifikk — "feil i deploy.log" er bedre enn "ser på logger". Denne etiketten identifiserer hvilken monitor som ble utløst.
+- `timeout_ms` (tall, standard `300000`, maks `3600000`): Tvangsavslutningsfrist i millisekunder. Etter denne varigheten avsluttes prosessen. Ignoreres når `persistent: true`.
+- `persistent` (boolsk, standard `false`): Når `true`, kjører monitoren i hele sesjonens levetid uten tidsavbrudd. Stopp den eksplisitt med `TaskStop`.
+
+## Eksempler
+
+### Eksempel 1: Følge en loggfil for feil og krasj
+
+Dette eksemplet dekker alle terminaltilstander: suksessmarkør, traceback, vanlige feilnøkkelord, OOM-avslutning og uventet prosessavslutning.
+
+```bash
+tail -F /var/log/deploy.log | grep -E --line-buffered \
+  "deployed|Traceback|Error|FAILED|assert|Killed|OOM"
+```
+
+Bruk `grep --line-buffered` i alle rør. Uten det bufrer operativsystemet utdata i 4 KB-blokker, og hendelser kan forsinkes i minutter. Vekselmønsteret dekker både suksessveien (`deployed`) og feilveiene (`Traceback`, `Error`, `FAILED`, `Killed`, `OOM`). En monitor som bare ser etter suksessmarkøren, forblir stille ved et krasj — stillhet ser identisk ut som "kjører fortsatt".
+
+### Eksempel 2: Spørre et eksternt 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 nettverksfeil fra å avslutte løkken. Spørringsintervaller på 30 sekunder eller mer er hensiktsmessige for eksterne APIer for å unngå hastighetsbegrensninger. Juster grep-mønsteret for å fange både suksess- og feilsvar slik at feil på API-siden ikke skjules av stillhet.
+
+## Notater
+
+- **Bruk alltid `grep --line-buffered` i rør.** Uten det forsinker rør-bufring hendelser i minutter fordi operativsystemet akkumulerer utdata til en 4 KB-blokk er fylt. `--line-buffered` tvinger en tømming etter hver linje.
+- **Filteret må dekke både suksess- og feilsignaturer.** En monitor som bare overvåker suksessmarkøren, forblir stille ved krasj, henging eller uventet avslutning. Utvid vekslingen: inkluder `Error`, `Traceback`, `FAILED`, `Killed`, `OOM` og lignende terminaltilstandsmarkører ved siden av suksessnøkkelordet.
+- **Spørringsintervaller: 30 sekunder eller mer for eksterne APIer.** Hyppig spørring av eksterne tjenester risikerer hastighetsbegrensningsfeil eller blokkering. For lokale filsystem- eller prosesskontroller er 0,5–1 sekund hensiktsmessig.
+- **Bruk `persistent: true` for monitorer med sesjonens levetid.** Standard `timeout_ms` på 300 000 ms (5 minutter) avslutter prosessen. For monitorer som skal kjøre til de eksplisitt stoppes, sett `persistent: true` og kall `TaskStop` når ferdig.
+- **Automatisk stopp ved hendelsesflomsituasjon.** Hver linje i standardutdata er en samtalemelding. Hvis filteret er for bredt og produserer for mange hendelser, stoppes monitoren automatisk. Start på nytt med et strammere `grep`-mønster. Linjer som ankommer innen 200 ms grupperes til én varsling.

package/concepts/no/Tool-NotebookEdit.md

@@ -1,33 +1,39 @@
 # NotebookEdit
 
-## Definisjon
+Modifiserer en enkelt celle i en Jupyter-notebook (`.ipynb`). Støtter å erstatte en celles kilde, sette inn en ny celle eller slette en eksisterende celle mens resten av notebookens struktur bevares.
 
-Erstatter, setter inn eller sletter spesifikke celler i Jupyter notebook (.ipynb-filer).
+## Når skal den brukes
+
+- Fikse eller oppdatere en kodecelle i en analyse-notebook uten å skrive om hele filen
+- Bytte ut en markdown-celle for å forbedre narrativ eller legge til dokumentasjon
+- Sette inn en ny kode- eller markdown-celle på en kjent posisjon i en eksisterende notebook
+- Fjerne en utdatert eller ødelagt celle slik at nedstrøms celler ikke lenger er avhengige av den
+- Forberede en reproduserbar notebook ved å iterere på celler én om gangen
 
 ## Parametere
 
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `notebook_path` | string | Ja | Absolutt sti til notebook-filen |
-| `new_source` | string | Ja | Nytt innhold for cellen |
-| `cell_id` | string | Nei | ID-en til cellen som skal redigeres. I insert-modus settes den nye cellen inn etter denne ID-en |
-| `cell_type` | enum | Nei | Celletype: `code` eller `markdown`. Påkrevd i insert-modus |
-| `edit_mode` | enum | Nei | Redigeringsmodus: `replace` (standard), `insert`, `delete` |
+- `notebook_path` (string, påkrevd): Absolutt sti til `.ipynb`-filen. Relative stier avvises.
+- `new_source` (string, påkrevd): Den nye cellekildekoden. For `replace` og `insert` blir dette cellekroppen; for `delete` ignoreres den, men kreves fortsatt av skjemaet.
+- `cell_id` (string, valgfri): ID-en til målcellen. I `replace`- og `delete`-modus virker verktøyet på denne cellen. I `insert`-modus settes den nye cellen inn rett etter cellen med denne ID-en; utelat for å sette inn øverst i notebooken.
+- `cell_type` (enum, valgfri): Enten `code` eller `markdown`. Påkrevd når `edit_mode` er `insert`. Når den utelates under `replace` bevares eksisterende celletype.
+- `edit_mode` (enum, valgfri): `replace` (standard), `insert` eller `delete`.
 
-## Bruksscenarioer
+## Eksempler
 
-**Egnet for bruk:**
-- Endre kode- eller markdown-celler i Jupyter notebook
-- Legge til nye celler i notebook
-- Slette celler fra notebook
+### Eksempel 1: Erstatt en buggy kodecelle
+Kall `NotebookEdit` med `notebook_path` satt til absolutt sti, `cell_id` satt til målcellens ID og `new_source` som inneholder korrigert Python-kode. La `edit_mode` stå på standard `replace`.
 
-## Merknader
+### Eksempel 2: Sett inn en markdown-forklaring
+For å legge til en markdown-celle rett etter en eksisterende `setup`-celle, sett `edit_mode: "insert"`, `cell_type: "markdown"`, `cell_id` til setup-cellens ID, og plasser narrativet i `new_source`.
 
-- `cell_number` er 0-indeksert
-- `insert`-modus setter inn en ny celle på angitt posisjon
-- `delete`-modus sletter cellen på angitt posisjon
-- Stien må være absolutt
+### Eksempel 3: Slett en foreldet celle
+Sett `edit_mode: "delete"` og oppgi `cell_id` for cellen som skal fjernes. Oppgi en hvilken som helst streng for `new_source`; den anvendes ikke.
 
-## Originaltekst
+## Notater
 
-<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 alltid inn en absolutt sti. `NotebookEdit` løser ikke opp relative stier mot arbeidskatalogen.
+- Verktøyet omskriver kun den målrettede cellen; kjøringsteller, utdata og metadata for urelaterte celler forblir uberørt.
+- Å sette inn uten en `cell_id` plasserer den nye cellen helt i begynnelsen av notebooken.
+- `cell_type` er obligatorisk for inserts. For replaces, utelat den med mindre du eksplisitt vil konvertere en kodecelle til markdown eller omvendt.
+- For å inspisere celler og hente ID-ene deres, bruk `Read`-verktøyet på notebooken først; det returnerer cellene med innhold og utdata.
+- Bruk vanlig `Edit` for vanlige kildefiler; `NotebookEdit` er spesifikk for `.ipynb` JSON og forstår cellestrukturen.

package/concepts/no/Tool-PushNotification.md

@@ -0,0 +1,48 @@
+# PushNotification
+
+Sender et skrivebordsvarsel fra den gjeldende Claude Code-økten. Hvis Remote Control er tilkoblet, sendes varselet også til brukerens telefon og trekker oppmerksomheten tilbake til økten uansett hva de holder på med.
+
+## Når skal den brukes
+
+- En langvarig oppgave er fullført mens brukeren sannsynligvis var borte fra terminalen
+- Et bygg, en testkjøring eller et utrulling er ferdig og resultatet er klart for gjennomgang
+- Det er nådd et beslutningspunkt som krever brukerens innspill før arbeidet kan fortsette
+- Det har oppstått en feil eller blokkering som ikke kan løses autonomt
+- Brukeren har eksplisitt bedt om å bli varslet når en bestemt oppgave eller betingelse er oppfylt
+
+## Når den ikke skal brukes
+
+Send ikke et varsel for rutinemessige fremdriftsoppdateringer under en oppgave, eller for å bekrefte at du har svart på noe brukeren tydelig nettopp spurte om og fremdeles venter på. Ikke varsle når en kort oppgave er fullført — hvis brukeren nettopp sendte den inn og venter, gir varselet ingen verdi og svekker tilliten til fremtidige varsler. Hel sterkt mot ikke å sende.
+
+## Parametere
+
+- `message` (streng, obligatorisk): varselets brødtekst. Hold det under 200 tegn; mobile operativsystemer kutter av lengre strenger. Begynn med det brukeren vil handle på: "build failed: 2 auth tests" er mer nyttig enn "task complete".
+- `status` (streng, obligatorisk): alltid satt til `"proactive"`. Dette er en fast markør og endres ikke.
+
+## Eksempler
+
+### Eksempel 1: varsle ved fullføring av en lang analyse
+
+En avhengighetsrevisjon for hele repositoriet ble forespurt og tok flere minutter. Brukeren forlot arbeidsplassen. Når rapporten er klar:
+
+```
+message: "Avhengighetsrevisjon ferdig: 3 alvorlige CVEer i lodash, axios, jsonwebtoken. Rapport: audit-report.txt"
+status: "proactive"
+```
+
+### Eksempel 2: flagge et beslutningspunkt under autonomt arbeid
+
+Under en flerstegs refaktorering oppdages det at to moduler har motstridende grensesnitt og ikke kan slås sammen uten en designbeslutning:
+
+```
+message: "Refaktorering satt på pause: AuthService og UserService har motstridende token-grensesnitt. Trenger din beslutning for å fortsette."
+status: "proactive"
+```
+
+## Notater
+
+- Hel sterkt mot **ikke** å sende. Varselet avbryter brukeren uansett hva de gjør. Behandle det som en kostnad som må rettferdiggjøres av informasjonsverdien.
+- Begynn med handlingsbart innhold. De første ordene bør fortelle brukeren hva som skjedde og hva, om noe, de må gjøre — ikke en generisk statusetikett.
+- Hold `message` under 200 tegn. Mobile operativsystemer vil kutte av lengre strenger og kan fjerne den viktigste delen hvis den vises til slutt.
+- Hvis resultatet indikerer at pushen ikke ble sendt fordi Remote Control ikke er tilkoblet, er det forventet atferd. Ingen nytt forsøk eller oppfølging er nødvendig; det lokale skrivebordsvarsel utløses likevel.
+- Unngå varselspam. Hvis det sendes varsler hyppig for mindre hendelser, vil brukeren begynne å ignorere dem. Reserver dette verktøyet for øyeblikk der det er reell sjanse for at brukeren har gått og vil vite resultatet nå.