cc-viewer 1.6.182 → 1.6.183

package/concepts/no/Tool-TaskList.md

@@ -1,56 +1,62 @@
 # TaskList
 
-## Definisjon
+Returnerer hver oppgave i gjeldende team (eller sesjon) i oppsummert form. Bruk det for å kartlegge utestående arbeid, bestemme hva du skal plukke opp neste, og unngå å opprette duplikater.
 
-Lister alle oppgaver i oppgavelisten for å se samlet fremdrift og tilgjengelig arbeid.
+## Når skal den brukes
+
+- Ved starten av en sesjon for å se hva som allerede er sporet.
+- Før du kaller `TaskCreate`, for å bekrefte at arbeidet ikke allerede er fanget.
+- Når du bestemmer hvilken oppgave du skal ta som lagkamerat eller underagent.
+- For å verifisere avhengighetsrelasjoner på tvers av teamet med et blikk.
+- Periodisk under lange sesjoner for å resynkronisere med lagkamerater som kan ha tatt, fullført eller lagt til oppgaver.
+
+`TaskList` er skrivebeskyttet og billig; kall den fritt når du trenger en oversikt.
 
 ## Parametere
 
-Ingen parametere.
+`TaskList` tar ingen parametere. Den returnerer alltid hele oppgavesettet for den aktive konteksten.
+
+## Responsform
 
-## Returnert innhold
+Hver oppgave i listen er et sammendrag, ikke hele posten. Forvent omtrent:
 
-Sammendragsinformasjon for hver oppgave:
-- `id` — Oppgaveidentifikator
-- `subject` — Kort beskrivelse
-- `status` — Status: `pending`, `in_progress` eller `completed`
-- `owner` — Ansvarlig (agent-ID), tom betyr ikke tildelt
-- `blockedBy` — Liste over uferdige oppgave-ID-er som blokkerer denne oppgaven
+- `id` — stabil identifikator for bruk med `TaskGet` / `TaskUpdate`.
+- `subject` — kort imperativ tittel.
+- `status` — en av `pending`, `in_progress`, `completed`, `deleted`.
+- `owner` — agent- eller lagkamerathandle, eller tom når uclaimet.
+- `blockedBy` — array av oppgave-ID-er som må fullføres først.
 
-## Bruksscenarioer
+For den fulle beskrivelsen, akseptkriteriene eller metadataen for en bestemt oppgave, følg opp med `TaskGet`.
 
-**Egnet for bruk:**
-- Se hvilke oppgaver som er tilgjengelige (status pending, ingen owner, ikke blokkert)
-- Sjekke samlet prosjektfremdrift
-- Finne blokkerte oppgaver
-- Finne neste oppgave etter å ha fullført en
+## Eksempler
 
-## Merknader
+### Eksempel 1
 
-- Foretrekk å behandle oppgaver i ID-rekkefølge (lavest ID først), da tidlige oppgaver vanligvis gir kontekst for senere oppgaver
-- Oppgaver med `blockedBy` kan ikke tas før avhengigheten er løst
-- Bruk TaskGet for å hente fullstendige detaljer for en spesifikk oppgave
+Rask statussjekk.
 
-## Originaltekst
+```
+TaskList()
+```
 
-<textarea readonly>Use this tool to list all tasks in the task list.
+Skann utdata for alt `in_progress` uten en `owner` (foreldet arbeid) og alt `pending` med tom `blockedBy` (klar til å plukke opp).
 
-## When to Use This Tool
+### Eksempel 2
 
-- To see what tasks are available to work on (status: 'pending', no owner, not blocked)
-- To check overall progress on the project
-- To find tasks that are blocked and need dependencies resolved
-- After completing a task, to check for newly unblocked work or claim the next available task
-- **Prefer working on tasks in ID order** (lowest ID first) when multiple tasks are available, as earlier tasks often set up context for later ones
+Lagkamerat som plukker neste oppgave.
 
-## Output
+```
+TaskList()
+# Filter to: status == pending AND blockedBy is empty AND owner is empty.
+# Among those, prefer the lower ID (tasks are typically numbered in
+# creation order, so lower IDs are older and usually higher priority).
+TaskGet(taskId: "<chosen id>")
+TaskUpdate(taskId: "<chosen id>", status: "in_progress", owner: "<your handle>")
+```
 
-Returns a summary of each task:
-- **id**: Task identifier (use with TaskGet, TaskUpdate)
-- **subject**: Brief description of the task
-- **status**: 'pending', 'in_progress', or 'completed'
-- **owner**: Agent ID if assigned, empty if available
-- **blockedBy**: List of open task IDs that must be resolved first (tasks with blockedBy cannot be claimed until dependencies resolve)
+## Notater
 
-Use TaskGet with a specific task ID to view full details including description and comments.
-</textarea>
+- Lagkamerat-heuristikk: når flere `pending`-oppgaver er ublokkerte og uten eier, velg den laveste ID-en. Dette holder arbeidet FIFO og unngår at to agenter tar samme høy-profil-oppgave.
+- Respekter `blockedBy`: ikke start en oppgave der blokkerne fortsatt er `pending` eller `in_progress`. Arbeid på blokkeren først eller koordiner med eieren.
+- `TaskList` er den eneste oppdagelsesmekanismen for oppgaver. Det er ingen søk; hvis listen er lang, skann strukturelt (etter status, deretter etter eier).
+- Slettede oppgaver kan fortsatt vises i listen med status `deleted` for sporbarhet. Ignorer dem for planleggingsformål.
+- Listen reflekterer den levende tilstanden til teamet, så lagkamerater kan legge til eller ta oppgaver mellom kall. Kall listen på nytt før du tar hvis tid har gått.

package/concepts/no/Tool-TaskOutput.md

@@ -1,40 +1,50 @@
 # TaskOutput
 
-## Definisjon
+Henter den akkumulerte utdataen fra en kjørende eller fullført bakgrunnsoppgave — en bakgrunns-shell-kommando, en lokal agent eller en ekstern sesjon. Bruk det når du trenger å inspisere hva en langvarig oppgave har produsert så langt.
 
-Henter utdata fra bakgrunnsoppgaver som kjører eller er fullført. Gjelder for bakgrunns-shell, asynkrone agenter og fjernsesjoner.
+## Når skal den brukes
+
+- En ekstern sesjon (for eksempel en cloud sandbox) kjører og du trenger dens stdout.
+- En lokal agent ble dispatchet i bakgrunnen og du vil ha delvis fremgang før den returnerer.
+- En bakgrunns-shell-kommando har kjørt lenge nok til at du vil sjekke den uten å stoppe den.
+- Du må bekrefte at en bakgrunnsoppgave faktisk gjør fremgang før du venter lenger eller kaller `TaskStop`.
+
+Ikke strekk deg etter `TaskOutput` refleksivt. For det meste av bakgrunnsarbeid finnes en mer direkte vei — se notatene nedenfor.
 
 ## Parametere
 
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `task_id` | string | Ja | Oppgave-ID |
-| `block` | boolean | Ja | Om den skal blokkere og vente til oppgaven er ferdig, standard `true` |
-| `timeout` | number | Ja | Maksimal ventetid (millisekunder), standard 30000, maks 600000 |
+- `task_id` (string, påkrevd): Oppgaveidentifikatoren som returneres når bakgrunnsarbeidet ble startet. Ikke det samme som en oppgavelistes `taskId`; dette er kjøretidshåndtaket for den spesifikke utførelsen.
+- `block` (boolean, valgfri): Når `true` (standard), vent til oppgaven produserer ny utdata eller avslutter før den returnerer. Når `false`, returner umiddelbart med det som er bufret.
+- `timeout` (number, valgfri): Maksimalt antall millisekunder å blokkere før returnering. Kun meningsfull når `block` er `true`. Standard `30000`, maksimum `600000`.
+
+## Eksempler
+
+### Eksempel 1
+
+Kikk på en ekstern sesjon uten å blokkere.
 
-## Bruksscenarioer
+```
+TaskOutput(task_id: "sess_01HXYZ...", block: false)
+```
 
-**Egnet for bruk:**
-- Sjekke fremdriften til bakgrunnsagenter startet via Task (`run_in_background: true`)
-- Hente resultater fra bakgrunns-Bash-kommandoer
-- Vente på at asynkrone oppgaver fullføres og hente utdata
+Returnerer hvilken som helst stdout/stderr som har blitt produsert siden oppgaven startet (eller siden ditt siste `TaskOutput`-kall, avhengig av kjøretiden).
 
-**Ikke egnet for bruk:**
-- Forgrunnsoppgaver — disse returnerer resultater direkte, dette verktøyet er ikke nødvendig
+### Eksempel 2
 
-## Merknader
+Vent kort på at en lokal agent sender ut mer utdata.
 
-- `block: true` blokkerer til oppgaven er ferdig eller tidsavbruddet nås
-- `block: false` for ikke-blokkerende sjekk av gjeldende status
-- Oppgave-ID kan finnes via `/tasks`-kommandoen
-- Gjelder for alle oppgavetyper: bakgrunns-shell, asynkrone agenter, fjernsesjoner
+```
+TaskOutput(
+  task_id: "agent_01ABCD...",
+  block: true,
+  timeout: 10000
+)
+```
 
-## Originaltekst
+## Notater
 
-<textarea readonly>- Retrieves output from a running or completed task (background shell, agent, or remote session)
-- Takes a task_id parameter identifying the task
-- Returns the task output along with status information
-- Use block=true (default) to wait for task completion
-- Use block=false for non-blocking check of current status
-- Task IDs can be found using the /tasks command
-- Works with all task types: background shells, async agents, and remote sessions</textarea>
+- Bakgrunns-bash-kommandoer: `TaskOutput` er effektivt avviklet for dette bruksområdet. Når du starter en bakgrunns-shell-oppgave inkluderer resultatet allerede stien til utdatafilen dens — les den stien direkte med `Read`-verktøyet. `Read` gir deg vilkårlig tilgang, linjeoffsets og en stabil visning; `TaskOutput` gjør ikke det.
+- Lokale agenter (`Agent`-verktøyet dispatchet i bakgrunnen): når agenten fullføres, inneholder `Agent`-verktøyresultatet allerede det endelige svaret. Bruk det direkte. Ikke `Read` den symlinkede transkripsjonsfilen — den inneholder hele verktøykall-strømmen og vil overfylle kontekstvinduet.
+- Eksterne sesjoner: `TaskOutput` er den korrekte og ofte eneste måten å strømme tilbake utdata. Foretrekk `block: true` med en moderat `timeout` fremfor tette polling-loops.
+- En ukjent `task_id`, eller en oppgave hvis utdata har blitt søppelsamlet, returnerer en feil. Dispatch arbeidet på nytt hvis du fortsatt trenger det.
+- `TaskOutput` stopper ikke oppgaven. Bruk `TaskStop` for å avslutte.

package/concepts/no/Tool-TaskStop.md

@@ -1,32 +1,45 @@
 # TaskStop
 
-## Definisjon
+Stopper en kjørende bakgrunnsoppgave — en shell-kommando, en dispatchet agent eller en ekstern sesjon — ved hjelp av kjøretidshåndtaket. Bruk det for å frigjøre ressurser, avbryte arbeid som ikke lenger er nyttig, eller gjenopprette når en oppgave er fastlåst.
 
-Stopper en bakgrunnsoppgave som kjører.
+## Når skal den brukes
+
+- En bakgrunns-shell-kommando har kjørt lenger enn forventet og du trenger ikke lenger resultatet.
+- En lokal agent loop-er eller har stoppet opp og må avskjæres.
+- Brukeren endret retning og bakgrunnsarbeid for forrige retning bør forlates.
+- En ekstern sesjon er i ferd med å tidsavbryte eller holder en ressurs du trenger.
+- Du trenger en ren tavle før du starter en ny kjøring av samme oppgave.
+
+Foretrekk å la kortlivet bakgrunnsarbeid fullføre på egen hånd. `TaskStop` er for tilfeller der fortsatt utførelse ikke har noen verdi eller er aktivt skadelig.
 
 ## Parametere
 
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `task_id` | string | Nei | ID-en til bakgrunnsoppgaven som skal stoppes |
-| `shell_id` | string | Nei | Utfaset, bruk `task_id` i stedet |
+- `task_id` (string, påkrevd): Kjøretidshåndtaket som returneres når bakgrunnsoppgaven ble startet. Dette er samme identifikator akseptert av `TaskOutput`, ikke en oppgaveliste-`taskId`.
+
+## Eksempler
+
+### Eksempel 1
+
+Stopp en løpsk bakgrunns-shell-kommando.
+
+```
+TaskStop(task_id: "bash_01HXYZ...")
+```
 
-## Bruksscenarioer
+Kommandoen mottar et termineringssignal; bufret utdata skrevet så langt forblir lesbart på utdatastien.
 
-**Egnet for bruk:**
-- Avslutte langvarige oppgaver som ikke lenger er nødvendige
-- Avbryte bakgrunnsoppgaver som ble startet ved en feil
+### Eksempel 2
 
-## Merknader
+Avbryt en dispatchet agent etter en brukerkursjustering.
 
-- Returnerer suksess- eller feilstatus
-- `shell_id`-parameteren er utfaset, bruk `task_id`
+```
+TaskStop(task_id: "agent_01ABCD...")
+```
 
-## Originaltekst
+## Notater
 
-<textarea readonly>
-- Stops a running background task by its ID
-- Takes a task_id parameter identifying the task to stop
-- Returns a success or failure status
-- Use this tool when you need to terminate a long-running task
-</textarea>
+- `TaskStop` ber om terminering; det garanterer ikke øyeblikkelig nedstengning. Veloppførte oppgaver avsluttes raskt, men en prosess som gjør blokkerende I/O kan ta et øyeblikk å avvikle.
+- Å stoppe en oppgave sletter ikke utdata dens. For bakgrunns-shell-oppgaver er utdatafilen på disken bevart og fortsatt lesbar med `Read`. For agenter og sesjoner er hvilken som helst utdata fanget opp før stoppet fortsatt tilgjengelig via `TaskOutput`.
+- En ukjent `task_id`, eller en oppgave som allerede har avsluttet, returnerer en feil eller er en no-op. Dette er trygt — du kan kalle `TaskStop` defensivt uten å sjekke status først.
+- Hvis du har tenkt å starte det samme arbeidet på nytt, stopp den gamle oppgaven før du dispatcher den nye for å unngå to parallelle kjøringer som konkurrerer om delte ressurser (filer, porter, databaserader).
+- `TaskStop` påvirker ikke oppføringer i team-oppgavelisten. For å avbryte en sporet oppgave, oppdater status til `deleted` med `TaskUpdate`.

package/concepts/no/Tool-TaskUpdate.md

@@ -1,123 +1,70 @@
 # TaskUpdate
 
-## Definisjon
+Modifiserer en eksisterende oppgave — dens status, innhold, eierskap, metadata eller avhengighetskanter. Dette er måten oppgaver går gjennom livssyklusen sin og måten arbeid overleveres mellom Claude Code, lagkamerater og underagenter.
 
-Oppdaterer status, innhold eller avhengighetsforhold for en oppgave i oppgavelisten.
+## Når skal den brukes
 
-## Parametere
-
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `taskId` | string | Ja | ID-en til oppgaven som skal oppdateres |
-| `status` | enum | Nei | Ny status: `pending` / `in_progress` / `completed` / `deleted` |
-| `subject` | string | Nei | Ny tittel |
-| `description` | string | Nei | Ny beskrivelse |
-| `activeForm` | string | Nei | Tekst i presens partisipp som vises under utførelse |
-| `owner` | string | Nei | Ny oppgaveansvarlig (agent-navn) |
-| `metadata` | object | Nei | Metadata som skal flettes inn (sett til null for å slette nøkkel) |
-| `addBlocks` | string[] | Nei | Liste over oppgave-ID-er blokkert av denne oppgaven |
-| `addBlockedBy` | string[] | Nei | Liste over forutgående oppgave-ID-er som blokkerer denne oppgaven |
-
-## Statusflyt
-
-```
-pending → in_progress → completed
-```
-
-`deleted` kan nås fra enhver status og fjerner oppgaven permanent.
-
-## Bruksscenarioer
-
-**Egnet for bruk:**
-- Markere oppgave som `in_progress` når arbeidet starter
-- Markere oppgave som `completed` etter fullført arbeid
-- Sette avhengighetsforhold mellom oppgaver
-- Oppdatere oppgaveinnhold ved endrede krav
-
-**Viktige regler:**
-- Marker kun som `completed` når oppgaven er fullstendig ferdig
-- Ved feil eller blokkering, behold `in_progress`
-- Ikke marker som `completed` ved mislykkede tester, ufullstendig implementering eller uløste feil
-
-## Merknader
-
-- Før oppdatering bør du hente siste oppgavestatus via TaskGet for å unngå utdaterte data
-- Etter fullføring av oppgave, kall TaskList for å finne neste tilgjengelige oppgave
+- Overføre en oppgave gjennom statusarbeidsflyten mens du jobber på den.
+- Ta en oppgave ved å tildele deg selv (eller en annen agent) som `owner`.
+- Raffinere `subject` eller `description` når du lærer mer om problemet.
+- Registrere nyoppdagede avhengigheter med `addBlocks` / `addBlockedBy`.
+- Legge ved strukturert `metadata` som eksterne ticket-ID-er eller prioritetshint.
 
-## Originaltekst
-
-<textarea readonly>Use this tool to update a task in the task list.
-
-## When to Use This Tool
-
-**Mark tasks as resolved:**
-- When you have completed the work described in a task
-- When a task is no longer needed or has been superseded
-- IMPORTANT: Always mark your assigned tasks as resolved when you finish them
-- After resolving, call TaskList to find your next task
-
-- ONLY mark a task as completed when you have FULLY accomplished it
-- If you encounter errors, blockers, or cannot finish, keep the task as in_progress
-- When blocked, create a new task describing what needs to be resolved
-- Never mark a task as completed if:
-  - Tests are failing
-  - Implementation is partial
-  - You encountered unresolved errors
-  - You couldn't find necessary files or dependencies
-
-**Delete tasks:**
-- When a task is no longer relevant or was created in error
-- Setting status to `deleted` permanently removes the task
+## Parametere
 
-**Update task details:**
-- When requirements change or become clearer
-- When establishing dependencies between tasks
+- `taskId` (string, påkrevd): Oppgaven som skal modifiseres. Hent fra `TaskList` eller `TaskCreate`.
+- `status` (string, valgfri): En av `pending`, `in_progress`, `completed`, `deleted`.
+- `subject` (string, valgfri): Erstatning imperativ tittel.
+- `description` (string, valgfri): Erstatning detaljert beskrivelse.
+- `activeForm` (string, valgfri): Erstatning presens partisipp spinner-tekst.
+- `owner` (string, valgfri): Agent- eller lagkamerathandle som tar ansvar for oppgaven.
+- `metadata` (objekt, valgfri): Metadatanøkler som skal slås sammen inn i oppgaven. Sett en nøkkel til `null` for å slette den.
+- `addBlocks` (array av strenger, valgfri): Oppgave-ID-er som denne oppgaven blokkerer.
+- `addBlockedBy` (array av strenger, valgfri): Oppgave-ID-er som må fullføres før denne.
 
-## Fields You Can Update
+## Statusarbeidsflyt
 
-- **status**: The task status (see Status Workflow below)
-- **subject**: Change the task title (imperative form, e.g., "Run tests")
-- **description**: Change the task description
-- **activeForm**: Present continuous form shown in spinner when in_progress (e.g., "Running tests")
-- **owner**: Change the task owner (agent name)
-- **metadata**: Merge metadata keys into the task (set a key to null to delete it)
-- **addBlocks**: Mark tasks that cannot start until this one completes
-- **addBlockedBy**: Mark tasks that must complete before this one can start
+Livssyklusen er bevisst lineær: `pending` → `in_progress` → `completed`. `deleted` er terminal og brukes for å trekke tilbake oppgaver som aldri vil bli arbeidet med.
 
-## Status Workflow
+- Sett `in_progress` i det øyeblikket du faktisk begynner arbeidet, ikke før. Kun én oppgave om gangen bør være `in_progress` for en gitt eier.
+- Sett `completed` kun når arbeidet er helt ferdig — akseptkriterier oppfylt, tester bestått, utdata skrevet. Hvis en blokker dukker opp, hold oppgaven `in_progress` og legg til en ny oppgave som beskriver hva som må løses.
+- Marker aldri en oppgave `completed` når tester feiler, implementeringen er delvis eller du støtte på uløste feil.
+- Bruk `deleted` for oppgaver som er kansellert eller duplikat; ikke gjenbruk en oppgave for urelatert arbeid.
 
-Status progresses: `pending` → `in_progress` → `completed`
+## Eksempler
 
-Use `deleted` to permanently remove a task.
+### Eksempel 1
 
-## Staleness
+Ta en oppgave og start den.
 
-Make sure to read a task's latest state using `TaskGet` before updating it.
+```
+TaskUpdate(
+  taskId: "t_01HXYZ...",
+  status: "in_progress",
+  owner: "main-agent"
+)
+```
 
-## Examples
+### Eksempel 2
 
-Mark task as in progress when starting work:
-```json
-{"taskId": "1", "status": "in_progress"}
-```
+Avslutt arbeidet og registrer en oppfølgingsavhengighet.
 
-Mark task as completed after finishing work:
-```json
-{"taskId": "1", "status": "completed"}
 ```
-
-Delete a task:
-```json
-{"taskId": "1", "status": "deleted"}
+TaskUpdate(
+  taskId: "t_01HXYZ...",
+  status: "completed"
+)
+
+TaskUpdate(
+  taskId: "t_01FOLLOWUP...",
+  addBlockedBy: ["t_01HXYZ..."]
+)
 ```
 
-Claim a task by setting owner:
-```json
-{"taskId": "1", "owner": "my-name"}
-```
+## Notater
 
-Set up task dependencies:
-```json
-{"taskId": "2", "addBlockedBy": ["1"]}
-```
-</textarea>
+- `metadata` slås sammen nøkkel for nøkkel; å sende `null` for en nøkkel fjerner den. Kall `TaskGet` først hvis du er usikker på gjeldende innhold.
+- `addBlocks` og `addBlockedBy` legger til kanter; de fjerner ikke eksisterende. Å redigere grafen destruktivt krever en dedikert arbeidsflyt — konsulter team-eieren før du skriver om avhengigheter.
+- Hold `activeForm` synkronisert når du endrer `subject` slik at spinner-teksten fortsetter å lese naturlig.
+- Ikke marker en oppgave `completed` for å dempe den. Hvis brukeren kansellerte arbeidet, bruk `deleted` med en kort begrunnelse i `description`.
+- Les en oppgaves siste tilstand med `TaskGet` før oppdatering — lagkamerater kan ha endret den mellom din siste lesing og din skriving.

package/concepts/no/Tool-TeamCreate.md

@@ -1,38 +1,53 @@
 # TeamCreate
 
-## Definisjon
+Etablerer et nytt samarbeidsteam med en delt oppgaveliste og inter-agent meldingskanal. Et team er koordinasjonsprimitiv for flere-agent-arbeid — hovedsesjonen fungerer som leder og spawner navngitte lagkamerater via `Agent`-verktøyet.
 
-Oppretter et nytt team for å koordinere flere agenter som arbeider på et prosjekt. Team muliggjør parallell oppgavekjøring via en delt oppgaveliste og kommunikasjon mellom agenter.
+## Når skal den brukes
+
+- Brukeren ber eksplisitt om et team, swarm, crew eller flere-agent-samarbeid.
+- Et prosjekt har flere klart uavhengige arbeidsstrømmer som tjener på dedikerte spesialister (f.eks. frontend, backend, tester, dokumenter).
+- Du trenger en persistent delt oppgaveliste som flere agenter oppdaterer etter hvert som de gjør fremgang.
+- Du vil ha navngitte, adresserbare lagkamerater som kan utveksle meldinger via `SendMessage` i stedet for engangs-underagentkall.
+
+IKKE bruk for et enkelt delegert søk eller en engangs-parallell utvidelse — vanlige `Agent`-kall er lettere og tilstrekkelige.
 
 ## Parametere
 
-| Parameter | Type | Påkrevd | Beskrivelse |
-|-----------|------|---------|-------------|
-| `team_name` | string | Ja | Navn på det nye teamet |
-| `description` | string | Nei | Teambeskrivelse / formål |
-| `agent_type` | string | Nei | Type / rolle for teamlederen |
+- `team_name` (string, påkrevd): Unik identifikator for teamet. Brukes som katalognavn under `~/.claude/teams/` og som `team_name`-argument når lagkamerater spawnes.
+- `description` (string, påkrevd): Kort uttalelse om teamets mål. Vises til hver lagkamerat ved spawn og skrives inn i team-konfigurasjonen.
+- `agent_type` (string, valgfri): Standard underagent-persona anvendt på lagkamerater som ikke overstyrer den. Typiske verdier er `general-purpose`, `Explore` eller `Plan`.
+
+## Eksempler
+
+### Eksempel 1: Opprett et refaktorerings-team
 
-## Hva som opprettes
+```
+TeamCreate(
+  team_name="refactor-crew",
+  description="Refactor the data access layer from raw SQL to Prisma, including migrations and tests.",
+  agent_type="general-purpose"
+)
+```
 
-- **Team-konfigurasjonsfil**: `~/.claude/teams/{team-name}/config.json` — lagrer medlemsliste og metadata
-- **Oppgavelistemappe**: `~/.claude/tasks/{team-name}/` — delt oppgaveliste for alle teammedlemmer
+Etter opprettelse, spawn lagkamerater med `Agent` ved å bruke `team_name: "refactor-crew"` og distinkte `name`-verdier som `db-lead`, `migrations` og `tests`.
 
-Team har et 1:1-forhold til oppgavelister.
+### Eksempel 2: Opprett et undersøkelsesteam
 
-## Team-arbeidsflyt
+```
+TeamCreate(
+  team_name="perf-investigation",
+  description="Identify and rank the top three performance regressions introduced in the last release.",
+  agent_type="Explore"
+)
+```
 
-1. **TeamCreate** — opprett teamet og dets oppgaveliste
-2. **TaskCreate** — definer oppgaver for teamet
-3. **Agent** (med `team_name` + `name`) — start teammedlemmer som slutter seg til teamet
-4. **TaskUpdate** — tildel oppgaver til teammedlemmer via `owner`
-5. Teammedlemmer arbeider med oppgaver og kommuniserer via **SendMessage**
-6. Avslutt teammedlemmer når ferdig, deretter **TeamDelete** for opprydding
+Hver spawnet lagkamerat arver `Explore` som standard persona, som matcher den skrivebeskyttede undersøkelsesnaturen til arbeidet.
 
-## Relaterte verktøy
+## Notater
 
-| Verktøy | Formål |
-|---------|--------|
-| `TeamDelete` | Fjern team og oppgavemapper |
-| `SendMessage` | Kommunikasjon mellom agenter i teamet |
-| `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` | Administrer den delte oppgavelisten |
-| `Agent` | Start teammedlemmer som slutter seg til teamet |
+- Kun ett team kan ledes om gangen fra en gitt sesjon. Fullfør eller slett gjeldende team før du oppretter et annet.
+- Et team er 1:1 med en delt oppgaveliste. Lederen eier oppgaveopprettelse, tildeling og avslutning; lagkamerater oppdaterer statusen på oppgaver de jobber med.
+- Teamkonfigurasjon persisteres på `~/.claude/teams/{team_name}/config.json`, og oppgavekatalogen lever ved siden av den. Disse filene overlever på tvers av sesjoner til de eksplisitt fjernes med `TeamDelete`.
+- Lagkamerater spawnes med `Agent`-verktøyet med matchende `team_name` pluss et distinkt `name`. `name` blir adressen brukt av `SendMessage`.
+- Velg et `team_name` som er filsystem-trygt (bokstaver, tall, bindestreker, understreker). Unngå mellomrom eller skråstreker.
+- Skriv `description` slik at en helt ny lagkamerat, som leser den uten forkunnskap, vil forstå teamets mål uten ytterligere kontekst. Den blir del av hver lagkamerats startprompt.

package/concepts/no/Tool-TeamDelete.md

@@ -1,30 +1,44 @@
 # TeamDelete
 
-## Definisjon
+River ned det gjeldende aktive teamet, og fjerner dets konfigurasjonskatalog og delte oppgavekatalog. Dette er opprydningsmotparten til `TeamCreate` og kalles typisk etter at teamets mål er oppnådd og alle lagkamerater er stengt ned.
 
-Fjerner et team og tilhørende oppgavemapper når multi-agent-samarbeidsarbeidet er fullført. Dette er oppryddingsmotparten til TeamCreate.
+## Når skal den brukes
 
-## Atferd
+- Teamet har fullført arbeidet sitt og sluttrapporten er levert til brukeren.
+- Teamet ble opprettet ved en feil eller dets omfang har endret seg så drastisk at det er renere å starte på nytt enn å fortsette.
+- Du må opprette et nytt team, men et er allerede aktivt — slett det gamle først, siden kun ett team kan ledes om gangen.
+- Et team har blitt foreldet på tvers av sesjoner og dets persisterte tilstand under `~/.claude/teams/` er ikke lenger nødvendig.
 
-- Fjerner team-mappen: `~/.claude/teams/{team-name}/`
-- Fjerner oppgavemappen: `~/.claude/tasks/{team-name}/`
-- Tømmer team-kontekst fra gjeldende økt
+IKKE kall mens lagkamerater fortsatt kjører — sten dem ned først via `SendMessage` med en `shutdown_request`, vent på hver `shutdown_response`, og slett deretter.
 
-**Viktig**: TeamDelete vil mislykkes hvis teamet fortsatt har aktive medlemmer. Teammedlemmer må først avsluttes på en kontrollert måte via SendMessage-avslutningsforespørsler.
+## Parametere
 
-## Typisk bruk
+`TeamDelete` tar ingen parametere i sin typiske invokasjon. Den opererer på det gjeldende aktive teamet eid av den kallende sesjonen.
 
-TeamDelete kalles på slutten av en team-arbeidsflyt:
+## Eksempler
 
-1. Alle oppgaver er fullført
-2. Teammedlemmer avsluttes via `SendMessage` med `shutdown_request`
-3. **TeamDelete** fjerner team- og oppgavemapper
+### Eksempel 1: Rutinenedstengning etter suksess
 
-## Relaterte verktøy
+1. Kringkast en shutdown-forespørsel til teamet:
+   ```
+   SendMessage(to="*", message={ "type": "shutdown_request" })
+   ```
+2. Vent på at hver lagkamerat svarer med en `shutdown_response`.
+3. Kall `TeamDelete()` for å fjerne teamkatalogen og oppgavekatalogen.
 
-| Verktøy | Formål |
-|---------|--------|
-| `TeamCreate` | Opprett et nytt team og dets oppgaveliste |
-| `SendMessage` | Kommuniser med teammedlemmer / send avslutningsforespørsler |
-| `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` | Administrer den delte oppgavelisten |
-| `Agent` | Start teammedlemmer som slutter seg til teamet |
+### Eksempel 2: Erstatte et feilkonfigurert team
+
+Hvis `TeamCreate` ble kalt med feil `agent_type` eller `description`, sørg først for at ingen lagkamerater har blitt spawnet ennå (eller sten dem ned), og deretter:
+
+```
+TeamDelete()
+TeamCreate(team_name="...", description="...", agent_type="...")
+```
+
+## Notater
+
+- `TeamDelete` feiler hvis noen lagkamerat fortsatt er aktiv. Feilsvaret lister de levende lagkameratene — send hver en `shutdown_request` via `SendMessage`, vent på deres `shutdown_response`, og prøv på nytt.
+- Sletting er irreversibel fra verktøyets perspektiv. Teamets konfigurasjon på `~/.claude/teams/{team_name}/config.json` og oppgavekatalogen fjernes fra disken. Hvis du trenger oppgavelisten bevart, eksporter eller kopier katalogen før sletting.
+- Kun ledersesjonen som opprettet teamet kan slette det. En spawnet lagkamerat kan ikke kalle `TeamDelete` på sitt eget team.
+- Å slette teamet ruller ikke tilbake filsystemsendringer som lagkamerater gjorde i repositoriet. Disse er vanlige git-sporede redigeringer og må reverseres separat hvis uønsket.
+- Etter at `TeamDelete` returnerer vellykket, er sesjonen fri til å kalle `TeamCreate` igjen for et nytt team.