cc-viewer 1.6.182 → 1.6.183

package/concepts/da/Tool-TaskList.md

@@ -1,56 +1,62 @@
 # TaskList
 
-## Definition
+Returnerer hver opgave i det aktuelle team (eller session) i opsummeret form. Brug den til at gennemgå udestående arbejde, beslutte hvad du skal samle op næste, og undgå at oprette dubletter.
 
-Lister alle opgaver i opgavelisten for at se den samlede fremdrift og tilgængeligt arbejde.
+## Hvornår skal den bruges
+
+- Ved starten af en session for at se, hvad der allerede spores.
+- Før kald af `TaskCreate` for at bekræfte, at arbejdet ikke allerede er fanget.
+- Når du beslutter, hvilken opgave du skal overtage næste som holdkammerat eller underagent.
+- For at verificere afhængighedsforhold på tværs af teamet med et hurtigt blik.
+- Periodisk under lange sessioner for at genresynkronisere med holdkammerater, der kan have overtaget, fuldført eller tilføjet opgaver.
+
+`TaskList` er skrivebeskyttet og billig; kald den frit, når du har brug for et overblik.
 
 ## Parametre
 
-Ingen parametre.
+`TaskList` tager ingen parametre. Den returnerer altid det fulde opgavesæt for den aktive kontekst.
+
+## Svarform
 
-## Returneret indhold
+Hver opgave i listen er et resumé, ikke den fulde registrering. Forvent cirka:
 
-Resuméinformation for hver opgave:
-- `id` — Opgaveidentifikator
-- `subject` — Kort beskrivelse
-- `status` — Status: `pending`, `in_progress` eller `completed`
-- `owner` — Ansvarlig (agent-ID), tom betyder ikke tildelt
-- `blockedBy` — Liste over ID'er for ufuldførte opgaver der blokerer denne opgave
+- `id` — stabil identifikator til brug med `TaskGet` / `TaskUpdate`.
+- `subject` — kort imperativ titel.
+- `status` — en af `pending`, `in_progress`, `completed`, `deleted`.
+- `owner` — agent- eller holdkammerat-handle, eller tom, når uoverdraget.
+- `blockedBy` — array af opgave-ID'er, der skal fuldføres først.
 
-## Brugsscenarier
+For den fulde beskrivelse, accepteringskriterier eller metadata for en specifik opgave, følg op med `TaskGet`.
 
-**Egnet til:**
-- Se hvilke opgaver der er tilgængelige (status pending, ingen owner, ikke blokeret)
-- Kontrollere projektets samlede fremdrift
-- Finde blokerede opgaver
-- Finde den næste opgave efter at have fuldført en
+## Eksempler
 
-## Bemærkninger
+### Eksempel 1
 
-- Behandl opgaver fortrinsvis i ID-rækkefølge (laveste ID først), da tidlige opgaver typisk giver kontekst til efterfølgende opgaver
-- Opgaver med `blockedBy` kan ikke påtages, før afhængighederne er løst
-- Brug TaskGet til at hente komplette detaljer for en specifik opgave
+Hurtig statuskontrol.
 
-## Originaltekst
+```
+TaskList()
+```
 
-<textarea readonly>Use this tool to list all tasks in the task list.
+Scan outputtet for alt, der er `in_progress` uden en `owner` (forældet arbejde), og alt `pending` med en tom `blockedBy` (klar til at samle op).
 
-## 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
+Holdkammerat, der vælger den næste opgave.
 
-## 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)
+## Noter
 
-Use TaskGet with a specific task ID to view full details including description and comments.
-</textarea>
+- Holdkammerat-heuristik: når flere `pending`-opgaver er ublokerede og uoverdragne, vælg det laveste ID. Dette holder arbejdet FIFO og undgår, at to agenter griber den samme højprofilerede opgave.
+- Respektér `blockedBy`: start ikke en opgave, hvis blokere stadig er `pending` eller `in_progress`. Arbejd på blokeren først, eller koordinér med dens ejer.
+- `TaskList` er den eneste opdagelsesmekanisme for opgaver. Der er ingen søgning; hvis listen er lang, scan strukturelt (efter status, derefter efter ejer).
+- Slettede opgaver kan stadig fremgå af listen med status `deleted` for sporbarhed. Ignorer dem til planlægningsformål.
+- Listen afspejler teamets live-tilstand, så holdkammerater kan tilføje eller overtage opgaver mellem kald. Gen-list før overtagelse, hvis tid er gået.

package/concepts/da/Tool-TaskOutput.md

@@ -1,40 +1,50 @@
 # TaskOutput
 
-## Definition
+Henter det akkumulerede output fra en kørende eller fuldført baggrundsopgave — en baggrunds-shell-kommando, en lokal agent eller en fjernsession. Brug den, når du har brug for at inspicere, hvad en langvarig opgave har produceret indtil videre.
 
-Henter output fra en kørende eller fuldført baggrundsopgave. Gælder for baggrunds-shells, asynkrone agenter og fjernsessioner.
+## Hvornår skal den bruges
+
+- En fjernsession (for eksempel en cloud-sandbox) kører, og du har brug for dens stdout.
+- En lokal agent blev sendt i baggrunden, og du vil have delvise fremskridt, før den returnerer.
+- En baggrunds-shell-kommando har kørt længe nok til, at du vil tjekke op på den uden at stoppe den.
+- Du har brug for at bekræfte, at en baggrundsopgave faktisk gør fremskridt, før du venter længere eller kalder `TaskStop`.
+
+Ræk ikke refleksivt efter `TaskOutput`. For det meste baggrundsarbejde er der en mere direkte sti — se noterne nedenfor.
 
 ## Parametre
 
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `task_id` | string | Ja | Opgave-ID |
-| `block` | boolean | Ja | Om der skal ventes blokerende på opgavens fuldførelse, standard `true` |
-| `timeout` | number | Ja | Maksimal ventetid (millisekunder), standard 30000, maks. 600000 |
+- `task_id` (string, påkrævet): Opgave-identifikatoren returneret, da baggrundsarbejdet blev startet. Ikke det samme som et task-list `taskId`; dette er runtime-håndtaget for den specifikke eksekvering.
+- `block` (boolean, valgfri): Når `true` (standard), vent indtil opgaven producerer nyt output eller afsluttes, før der returneres. Når `false`, returnér straks med det, der er bufret.
+- `timeout` (number, valgfri): Maksimum millisekunder at blokere, før der returneres. Kun meningsfuld, når `block` er `true`. Standard `30000`, maksimum `600000`.
+
+## Eksempler
+
+### Eksempel 1
+
+Kig på en fjernsession uden at blokere.
 
-## Brugsscenarier
+```
+TaskOutput(task_id: "sess_01HXYZ...", block: false)
+```
 
-**Egnet til:**
-- Kontrollere fremdriften for en baggrundsagent startet via Task (`run_in_background: true`)
-- Hente udførelsesresultater fra Bash-kommandoer i baggrunden
-- Vente på fuldførelse af en asynkron opgave og hente output
+Returnerer det stdout/stderr, der er produceret, siden opgaven startede (eller siden dit sidste `TaskOutput`-kald, afhængigt af runtime).
 
-**Ikke egnet til:**
-- Forgrundsopgaver — forgrundsopgaver returnerer resultater direkte, dette værktøj er ikke nødvendigt
+### Eksempel 2
 
-## Bemærkninger
+Vent kort på, at en lokal agent udsender mere output.
 
-- `block: true` blokerer indtil opgaven er fuldført eller timeout
-- `block: false` til ikke-blokerende kontrol af aktuel status
-- Opgave-ID kan findes via `/tasks`-kommandoen
-- Gælder for alle opgavetyper: baggrunds-shells, asynkrone agenter, fjernsessioner
+```
+TaskOutput(
+  task_id: "agent_01ABCD...",
+  block: true,
+  timeout: 10000
+)
+```
 
-## Originaltekst
+## Noter
 
-<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>
+- Baggrunds-bash-kommandoer: `TaskOutput` er reelt forældet til dette brug. Når du starter en baggrunds-shell-opgave, inkluderer resultatet allerede stien til dens outputfil — læs den sti direkte med `Read`-værktøjet. `Read` giver dig random access, linjeoffsets og en stabil visning; det gør `TaskOutput` ikke.
+- Lokale agenter (`Agent`-værktøjet udsendt i baggrunden): når agenten er færdig, indeholder `Agent`-værktøjsresultatet allerede dens endelige svar. Brug det direkte. Læs ikke den symlinkede transkriptfil — den indeholder den fulde værktøjskaldsstrøm og vil overfylde kontekstvinduet.
+- Fjernsessioner: `TaskOutput` er den korrekte og ofte eneste måde at streame output tilbage på. Foretræk `block: true` med en moderat `timeout` frem for stramme polling-løkker.
+- Et ukendt `task_id` eller en opgave, hvis output er blevet garbage-collected, returnerer en fejl. Udsend arbejdet igen, hvis du stadig har brug for det.
+- `TaskOutput` stopper ikke opgaven. Brug `TaskStop` til at afslutte.

package/concepts/da/Tool-TaskStop.md

@@ -1,32 +1,45 @@
 # TaskStop
 
-## Definition
+Stopper en kørende baggrundsopgave — en shell-kommando, en udsendt agent eller en fjernsession — efter dens runtime-håndtag. Brug den til at frigive ressourcer, annullere arbejde, der ikke længere er nyttigt, eller komme på fode igen, når en opgave sidder fast.
 
-Stopper en kørende baggrundsopgave.
+## Hvornår skal den bruges
+
+- En baggrunds-shell-kommando har kørt længere end forventet, og du har ikke længere brug for dens resultat.
+- En lokal agent looper eller er gået i stå og skal afkortes.
+- Brugeren har skiftet retning, og baggrundsarbejde for den tidligere retning bør opgives.
+- En fjernsession er ved at time ud eller holder en ressource, du har brug for.
+- Du har brug for en ren tavle, før du starter en ny kørsel af den samme opgave.
+
+Foretræk at lade kortvarigt baggrundsarbejde blive færdigt af sig selv. `TaskStop` er til tilfælde, hvor fortsat eksekvering ingen værdi har eller er aktivt skadelig.
 
 ## Parametre
 
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `task_id` | string | Nej | ID på baggrundsopgaven der skal stoppes |
-| `shell_id` | string | Nej | Forældet, brug `task_id` i stedet |
+- `task_id` (string, påkrævet): Runtime-håndtaget returneret, da baggrundsopgaven blev startet. Dette er den samme identifikator, som `TaskOutput` accepterer, ikke et task-list `taskId`.
+
+## Eksempler
+
+### Eksempel 1
+
+Stop en løbsk baggrunds-shell-kommando.
+
+```
+TaskStop(task_id: "bash_01HXYZ...")
+```
 
-## Brugsscenarier
+Kommandoen modtager et terminate-signal; bufret output skrevet indtil nu forbliver læsbart ved dens outputsti.
 
-**Egnet til:**
-- Afslutte langvarige opgaver der ikke længere er nødvendige
-- Annullere fejlagtigt startede baggrundsopgaver
+### Eksempel 2
 
-## Bemærkninger
+Annuller en udsendt agent efter en brugerkurskorrektion.
 
-- Returnerer en succes- eller fejlstatus
-- Parameteren `shell_id` er forældet, brug `task_id`
+```
+TaskStop(task_id: "agent_01ABCD...")
+```
 
-## Originaltekst
+## Noter
 
-<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` anmoder om afslutning; den garanterer ikke øjeblikkelig nedlukning. Velopdragne opgaver afslutter omgående, men en proces, der laver blokerende I/O, kan tage et øjeblik om at afvikle sig.
+- Stop af en opgave sletter ikke dens output. For baggrunds-shell-opgaver er outputfilen på disken bevaret og stadig læsbar med `Read`. For agenter og sessioner er det, der blev fanget før stoppet, stadig tilgængeligt via `TaskOutput`.
+- Et ukendt `task_id` eller en opgave, der allerede er afsluttet, returnerer en fejl eller en no-op. Dette er sikkert — du kan kalde `TaskStop` defensivt uden at tjekke status først.
+- Hvis du har til hensigt at genstarte det samme arbejde, stop den gamle opgave, før du sender den nye, for at undgå, at to parallelle kørsler løber om kap om delte ressourcer (filer, porte, databaserækker).
+- `TaskStop` påvirker ikke poster i teamets opgaveliste. For at annullere en sporet opgave opdater dens status til `deleted` med `TaskUpdate`.

package/concepts/da/Tool-TaskUpdate.md

@@ -1,123 +1,70 @@
 # TaskUpdate
 
-## Definition
+Ændrer en eksisterende opgave — dens status, indhold, ejerskab, metadata eller afhængighedskanter. Sådan skrider opgaver gennem deres livscyklus, og sådan overdrages arbejde mellem Claude Code, holdkammerater og underagenter.
 
-Opdaterer status, indhold eller afhængigheder for en opgave i opgavelisten.
+## Hvornår skal den bruges
 
-## Parametre
-
-| Parameter | Type | Påkrævet | Beskrivelse |
-|------|------|------|------|
-| `taskId` | string | Ja | ID på opgaven der skal opdateres |
-| `status` | enum | Nej | Ny status: `pending` / `in_progress` / `completed` / `deleted` |
-| `subject` | string | Nej | Ny titel |
-| `description` | string | Nej | Ny beskrivelse |
-| `activeForm` | string | Nej | Tekst i nutids-tillægsform vist under udførelse |
-| `owner` | string | Nej | Ny opgaveansvarlig (agent-navn) |
-| `metadata` | object | Nej | Metadata der skal flettes (sæt til null for at slette en nøgle) |
-| `addBlocks` | string[] | Nej | Liste over ID'er for opgaver blokeret af denne opgave |
-| `addBlockedBy` | string[] | Nej | Liste over ID'er for forudgående opgaver der blokerer denne opgave |
-
-## Statusflow
-
-```
-pending → in_progress → completed
-```
-
-`deleted` kan nås fra enhver status og fjerner opgaven permanent.
-
-## Brugsscenarier
-
-**Egnet til:**
-- Markere en opgave som `in_progress` når arbejdet påbegyndes
-- Markere en opgave som `completed` når arbejdet er afsluttet
-- Sætte afhængigheder mellem opgaver
-- Opdatere opgaveindhold når kravene ændres
-
-**Vigtige regler:**
-- Markér kun som `completed` når opgaven er fuldstændigt afsluttet
-- Ved fejl eller blokeringer, behold `in_progress`
-- Markér ikke som `completed` ved fejlende tests, ufuldstændig implementering eller uløste fejl
-
-## Bemærkninger
-
-- Før opdatering bør man hente opgavens seneste status via TaskGet for at undgå forældede data
-- Efter fuldførelse af en opgave, kald TaskList for at finde den næste tilgængelige opgave
+- Skift en opgave gennem statusworkflowet, mens du arbejder på den.
+- Overtag en opgave ved at tildele dig selv (eller en anden agent) som `owner`.
+- Finjustering af `subject` eller `description`, når du lærer mere om problemet.
+- Registrering af nyopdagede afhængigheder med `addBlocks` / `addBlockedBy`.
+- Vedhæft struktureret `metadata` som eksterne ticket-ID'er eller prioritetshints.
 
-## 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
+## Parametre
 
-**Update task details:**
-- When requirements change or become clearer
-- When establishing dependencies between tasks
+- `taskId` (string, påkrævet): Den opgave, der skal ændres. Hent fra `TaskList` eller `TaskCreate`.
+- `status` (string, valgfri): En af `pending`, `in_progress`, `completed`, `deleted`.
+- `subject` (string, valgfri): Erstatningsimperativtitel.
+- `description` (string, valgfri): Erstatningsdetaljeret beskrivelse.
+- `activeForm` (string, valgfri): Erstatnings-nutid-continuous-spinner-tekst.
+- `owner` (string, valgfri): Agent- eller holdkammerat-handle, der tager ansvar for opgaven.
+- `metadata` (object, valgfri): Metadata-nøgler, der skal flettes ind i opgaven. Sæt en nøgle til `null` for at slette den.
+- `addBlocks` (array af strings, valgfri): Opgave-ID'er, som denne opgave blokerer.
+- `addBlockedBy` (array af strings, valgfri): Opgave-ID'er, der skal fuldføres, før denne.
 
-## Fields You Can Update
+## Statusworkflow
 
-- **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
+Livscyklussen er bevidst lineær: `pending` → `in_progress` → `completed`. `deleted` er terminal og bruges til at trække opgaver tilbage, der aldrig vil blive arbejdet på.
 
-## Status Workflow
+- Sæt `in_progress` i det øjeblik, du faktisk begynder arbejdet, ikke før. Kun én opgave ad gangen bør være `in_progress` for en given ejer.
+- Sæt `completed`, kun når arbejdet er fuldt udført — accepteringskriterier opfyldt, tests bestået, output skrevet. Hvis en blokering viser sig, hold opgaven `in_progress` og tilføj en ny opgave, der beskriver, hvad der skal løses.
+- Markér aldrig en opgave `completed`, når tests fejler, implementeringen er delvis, eller du støder på uløste fejl.
+- Brug `deleted` for opgaver, der er annullerede eller dublerede; genbrug ikke en opgave til ikke-relateret arbejde.
 
-Status progresses: `pending` → `in_progress` → `completed`
+## Eksempler
 
-Use `deleted` to permanently remove a task.
+### Eksempel 1
 
-## Staleness
+Overtag en opgave 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"}
-```
+Afslut arbejdet og registrér en opfølgende afhængighed.
 
-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"}
-```
+## Noter
 
-Set up task dependencies:
-```json
-{"taskId": "2", "addBlockedBy": ["1"]}
-```
-</textarea>
+- `metadata` fletter nøgle for nøgle; at sende `null` for en nøgle fjerner den. Kald `TaskGet` først, hvis du er usikker på det aktuelle indhold.
+- `addBlocks` og `addBlockedBy` tilføjer kanter; de fjerner ikke eksisterende. Destruktiv redigering af grafen kræver et dedikeret workflow — rådfør dig med teamejeren, før du omskriver afhængigheder.
+- Hold `activeForm` i synk, når du ændrer `subject`, så spinnertekst fortsat læses naturligt.
+- Markér ikke en opgave `completed` for at tie den stille. Hvis brugeren annullerede arbejdet, brug `deleted` med en kort begrundelse i `description`.
+- Læs en opgaves seneste tilstand med `TaskGet`, før du opdaterer — holdkammerater kan have ændret den mellem din sidste læsning og din skrivning.

package/concepts/da/Tool-TeamCreate.md

@@ -1,38 +1,53 @@
 # TeamCreate
 
-## Definition
+Etablerer et nyt samarbejdsteam med en delt opgaveliste og en kanal for inter-agent-beskeder. Et team er koordinationsprimitivet for multi-agent-arbejde — hovedsessionen fungerer som leder og starter navngivne holdkammerater via `Agent`-værktøjet.
 
-Opretter et nyt team til at koordinere flere agenter, der arbejder på et projekt. Teams muliggør parallel opgaveudførelse via en delt opgaveliste og kommunikation mellem agenter.
+## Hvornår skal den bruges
+
+- Brugeren anmoder udtrykkeligt om et team, en swarm, et crew eller multi-agent-samarbejde.
+- Et projekt har flere klart uafhængige arbejdsstrømme, der drager fordel af dedikerede specialister (f.eks. frontend, backend, tests, docs).
+- Du har brug for en vedvarende delt opgaveliste, som flere agenter opdaterer, mens de gør fremskridt.
+- Du ønsker navngivne, adresserbare holdkammerater, der kan udveksle beskeder via `SendMessage` frem for one-shot underagentkald.
+
+Brug det IKKE til en enkelt delegeret søgning eller en engangs parallel fan-out — almindelige `Agent`-kald er lettere og tilstrækkelige.
 
 ## Parametre
 
-| Parameter | Type | Påkrævet | Beskrivelse |
-|-----------|------|----------|-------------|
-| `team_name` | string | Ja | Navn til det nye team |
-| `description` | string | Nej | Teambeskrivelse / formål |
-| `agent_type` | string | Nej | Type / rolle for teamlederen |
+- `team_name` (string, påkrævet): Unik identifikator for teamet. Bruges som mappenavn under `~/.claude/teams/` og som `team_name`-argument ved start af holdkammerater.
+- `description` (string, påkrævet): Kort erklæring om teamets mål. Vises for hver holdkammerat ved start og skrives i teamkonfigurationen.
+- `agent_type` (string, valgfri): Standard-underagent-persona anvendt på holdkammerater, der ikke tilsidesætter den. Typiske værdier er `general-purpose`, `Explore` eller `Plan`.
+
+## Eksempler
+
+### Eksempel 1: Opret et refaktoreringsteam
 
-## Hvad der oprettes
+```
+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-konfigurationsfil**: `~/.claude/teams/{team-name}/config.json` — gemmer medlemsliste og metadata
-- **Opgavelistemappe**: `~/.claude/tasks/{team-name}/` — delt opgaveliste for alle teammedlemmer
+Efter oprettelse start holdkammerater med `Agent` ved hjælp af `team_name: "refactor-crew"` og distinkte `name`-værdier som `db-lead`, `migrations` og `tests`.
 
-Teams har et 1:1-forhold til opgavelister.
+### Eksempel 2: Opret et undersøgelsesteam
 
-## Team-arbejdsgang
+```
+TeamCreate(
+  team_name="perf-investigation",
+  description="Identify and rank the top three performance regressions introduced in the last release.",
+  agent_type="Explore"
+)
+```
 
-1. **TeamCreate** — opret teamet og dets opgaveliste
-2. **TaskCreate** — definer opgaver for teamet
-3. **Agent** (med `team_name` + `name`) — start teammedlemmer der tilslutter sig teamet
-4. **TaskUpdate** — tildel opgaver til teammedlemmer via `owner`
-5. Teammedlemmer arbejder på opgaver og kommunikerer via **SendMessage**
-6. Luk teammedlemmer ned når det er færdigt, derefter **TeamDelete** for at rydde op
+Hver startet holdkammerat arver `Explore` som sin standardpersona, hvilket matcher arbejdets skrivebeskyttede undersøgende natur.
 
-## Relaterede værktøjer
+## Noter
 
-| Værktøj | Formål |
-|---------|--------|
-| `TeamDelete` | Fjern team og opgavemapper |
-| `SendMessage` | Kommunikation mellem agenter inden for teamet |
-| `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` | Administrer den delte opgaveliste |
-| `Agent` | Start teammedlemmer der tilslutter sig teamet |
+- Kun ét team kan ledes ad gangen fra en given session. Afslut eller slet det aktuelle team, før du opretter et andet.
+- Et team er 1:1 med en delt opgaveliste. Lederen ejer opgaveoprettelse, tildeling og lukning; holdkammerater opdaterer status på opgaver, de arbejder på.
+- Teamkonfiguration persisteres på `~/.claude/teams/{team_name}/config.json`, og opgavebiblioteket ligger ved siden af den. Disse filer overlever på tværs af sessioner, indtil de eksplicit fjernes med `TeamDelete`.
+- Holdkammerater startes ved hjælp af `Agent`-værktøjet med matchende `team_name` plus et distinkt `name`. `name` bliver den adresse, der bruges af `SendMessage`.
+- Vælg et `team_name`, der er filsystemsikkert (bogstaver, cifre, bindestreger, understregninger). Undgå mellemrum eller skråstreger.
+- Skriv `description`, så en helt ny holdkammerat, der læser den koldt, ville forstå teamets mål uden yderligere kontekst. Den bliver en del af hver holdkammerats startprompt.

package/concepts/da/Tool-TeamDelete.md

@@ -1,30 +1,44 @@
 # TeamDelete
 
-## Definition
+Nedbryder det aktuelt aktive team, fjerner dets konfigurationsmappe og delte opgavebibliotek. Dette er oprydningsmodstykket til `TeamCreate` og kaldes typisk, efter teamets mål er nået, og alle holdkammerater er lukket ned.
 
-Fjerner et team og dets tilknyttede opgavemapper når multi-agent-samarbejdsarbejdet er afsluttet. Dette er oprydningsmodstykket til TeamCreate.
+## Hvornår skal den bruges
 
-## Adfærd
+- Teamet har fuldført sit arbejde, og den endelige rapport er leveret til brugeren.
+- Teamet blev oprettet ved en fejl, eller dets omfang har ændret sig så drastisk, at det er renere at starte forfra end at fortsætte.
+- Du skal oprette et nyt team, men et er allerede aktivt — slet det gamle først, da kun ét team kan ledes ad gangen.
+- Et team er blevet forældet på tværs af sessioner, og dets persisterede tilstand under `~/.claude/teams/` er ikke længere nødvendig.
 
-- Fjerner team-mappen: `~/.claude/teams/{team-name}/`
-- Fjerner opgavelistemappen: `~/.claude/tasks/{team-name}/`
-- Rydder team-konteksten fra den aktuelle session
+Kald det IKKE, mens holdkammerater stadig kører — luk dem først ned via `SendMessage` med en `shutdown_request`, vent på hver `shutdown_response`, og slet så.
 
-**Vigtigt**: TeamDelete fejler hvis teamet stadig har aktive medlemmer. Teammedlemmer skal først lukkes ned korrekt via SendMessage shutdown-anmodninger.
+## Parametre
 
-## Typisk anvendelse
+`TeamDelete` tager ingen parametre i sin typiske invokering. Den opererer på det aktuelt aktive team ejet af den kaldende session.
 
-TeamDelete kaldes i slutningen af en team-arbejdsgang:
+## Eksempler
 
-1. Alle opgaver er fuldført
-2. Teammedlemmer lukkes ned via `SendMessage` med `shutdown_request`
-3. **TeamDelete** fjerner team- og opgavemapper
+### Eksempel 1: Rutinemæssig nedlukning efter succes
 
-## Relaterede værktøjer
+1. Broadcast en nedlukningsanmodning til teamet:
+   ```
+   SendMessage(to="*", message={ "type": "shutdown_request" })
+   ```
+2. Vent på, at hver holdkammerat svarer med et `shutdown_response`.
+3. Kald `TeamDelete()` for at fjerne teammappen og opgavebiblioteket.
 
-| Værktøj | Formål |
-|---------|--------|
-| `TeamCreate` | Opret et nyt team og dets opgaveliste |
-| `SendMessage` | Kommuniker med teammedlemmer / send shutdown-anmodninger |
-| `TaskCreate` / `TaskUpdate` / `TaskList` / `TaskGet` | Administrer den delte opgaveliste |
-| `Agent` | Start teammedlemmer der tilslutter sig teamet |
+### Eksempel 2: Udskiftning af et fejlkonfigureret team
+
+Hvis `TeamCreate` blev kaldt med den forkerte `agent_type` eller `description`, sørg først for, at ingen holdkammerater er blevet startet endnu (eller luk dem ned), og derefter:
+
+```
+TeamDelete()
+TeamCreate(team_name="...", description="...", agent_type="...")
+```
+
+## Noter
+
+- `TeamDelete` fejler, hvis nogen holdkammerat stadig er aktiv. Fejlsvaret lister de aktive holdkammerater — send hver af dem en `shutdown_request` via `SendMessage`, vent på deres `shutdown_response`, og prøv igen.
+- Sletning er irreversibel fra værktøjets perspektiv. Teamets konfiguration på `~/.claude/teams/{team_name}/config.json` og dets opgavebibliotek fjernes fra disken. Hvis du har brug for, at opgavelisten bevares, eksportér eller kopiér biblioteket, før du sletter.
+- Kun lederens session, der oprettede teamet, kan slette det. En startet holdkammerat kan ikke kalde `TeamDelete` på sit eget team.
+- Sletning af teamet ruller ikke filsystemændringer tilbage, som holdkammerater foretog i repoet. Disse er almindelige git-sporede redigeringer og skal vendes separat, hvis uønskede.
+- Efter at `TeamDelete` er returneret med succes, er sessionen fri til at kalde `TeamCreate` igen for et nyt team.