Oppsummer alle utbedringer i én setning og spør: > Jeg fikser sak {direkte-saker} direkte, spawner subagent for sak {subagent-saker}, og noterer sak {ny-sesjon-saker} som ny sesjon. **OK?** Utelat kategorier der det ikke er noen saker. Vent på brukerens "ja" før du gjør noe. **Ved "ja":** Bruk utbedringstabellen som arbeidsliste — den inneholder all nødvendig informasjon. Ikke gå tilbake og let i rapporten etter detaljer som burde stått i tabellen. ```

Én samlet tabell. Kolonne "Løsning" angir om agenten fikser direkte, spawner subagent, eller om det krever ny sesjon. **VIKTIG:** Tabellen er den autoritative listen over alt som skal gjøres. "Endring"-kolonnen MÅ inneholde nok detalj til at endringen kan implementeres uten å lese resten av rapporten på nytt. Vær konkret: filsti, regelformulering, gotcha-tekst, bug-beskrivelse. Ikke skriv "oppdater med funn fra audit" — skriv den faktiske teksten/regelen. | # | Type | Fil/lokasjon | Endring |...

- Sløsing: {lav/middels/høy} — {verste eksempel hvis relevant} ---

- **{komponent}** (MCP/hook/agent-fil/expert-fil/CLAUDE.md): {problem} → {konsekvens} - Hvis ingen: "Ingen systemfeil observert."

- **[{KRITISK/ADVARSEL/MINOR}]** {kategori}: {hva skjedde} → {hva som burde skjedd}

- {kort, konkret}

{3-5 setninger. Hva gikk bra, hva gikk galt, hva var systemfeil vs agentfeil. Rett på sak.} ---

Rapporten har TO deler: en kort menneske-oppsummering, og en strukturert LLM-seksjon for direkte implementering. ```markdown # Chat-Audit: [{agent/command}] — {kort beskrivelse} **Agent:** {agent} | **Workspace:** {workspace} | **Dom:** {A/B/C/D/F}

Sjekk spesifikt for disse — de har skjedd før: - **SSH find-storm**: `find / -name "*.ts"` i stedet for MCP eller målrettet oppslag - **cat-bombing**: `cat` av store filer (CSS, minified JS, compiled bundles) uten `wc -l` først - **Explore-flood**: Starter med bred Explore-subagent (>50k tokens) der KB-query + Serena `find_symbol` ville gitt tilstrekkelig kontekst. Symptom: subagenten returnerer arkitektur-oversikt der kun 10-20% er relevant for selve diagnosen. Korrekt: `kb:query` →...

| Sjekk | Detalj | |-------|--------| | Passord | Hardkodet passord noe sted? (skal bruke `$SUDO_PASS`) | | Core-filer | Forsøkte å endre filer i `core/`, `vendor/`, `public/legacy/modules/`? | | Destruktive kommandoer | Kjørte `migrate:fresh`, `reset --hard`, `rm -rf` etc.? | | Backup/rollback | Tok den hensyn til reverserbarhet ved risikable operasjoner? | ---

| Sjekk | Detalj | |-------|--------| | MCP-feil | Returnerte MCP-servere feil data, timeouts, eller uventede svar? | | MCP-mangler | Manglet MCP-tool for noe agenten trengte? (gap i MCP-dekning) | | Hook-problemer | Blokkerte hooks agentens arbeid feilaktig? | | Verktøybegrensninger | Traff agenten begrensninger i Claude Code (context, tool-feil, etc.)? | | Agent-fil-mangler | Manglet agent-filen instrukser som ville forhindret problemet? | | CLAUDE.md-hull | Manglet workspace-regler som ville...

| Sjekk | Detalj | |-------|--------| | Kontekstforståelse | Forsto agenten hva den faktisk ble bedt om? | | Prioritering | Tok den tak i det viktigste først? | | Glemsel | Glemte den tidligere info fra samtalen (context drift)? | | Feil antakelser | Antok den noe som ikke stemte? (feilaktige filstier, versjoner, etc.) | | Scope creep | La den til arbeid som ikke var etterspurt? | | Feil delegering | Burde den ha delegert til en annen agent i stedet for å gjøre det selv? |

| Sjekk | Detalj | |-------|--------| | KB-query | Brukte KB (`kb:query`/`kb:context`) før manuell fil-lesing? | | Expert-filer | Leste relevante CURRENT-*.md ekspertfiler? | | Knowledge-filer | Brukte agent-spesifikke knowledge-filer der relevant? | | Explore-rapporter | Sjekket eksisterende explore-rapporter før ny research? | | context7 | Brukte context7 for dokumentasjons-spørsmål i stedet for gjetting? | | Versjonskorrekthet | Blandet den SuiteCRM 7/8, Laravel-versjoner, eller andre...

| Sjekk | Detalj | |-------|--------| | Unødvendig lesing | Leste filer den ikke trengte? Leste hele filer når `head`/`grep` holdt? | | Gjentatt resonnering | Resonerte den om det samme flere ganger? | | Overforklaring | Brukte den tokens på å forklare ting brukeren ikke spurte om? | | Dobbeltarbeid | Verifiserte den ting som allerede var bekreftet (explore-rapporter, etc.)? | | Parallellisering | Kjørte den uavhengige operasjoner parallelt, eller sekvensielt uten grunn? | | SSH-output |...

> **MCP-spesifikk analyse gjøres i `/prompt-agent-chat-mcp-usage-audit`.** Denne seksjonen dekker KUN generell verktøybruk. | Sjekk | Detalj | |-------|--------| | Subagent-bruk | Brukte subagenter der det ga verdi? Overbrukte subagenter unødvendig? | | Verktøy-rekkefølge | Riktig sekvens? (KB-query → expert-fil → MCP → SSH som siste utvei) | | Read/Edit/Write | Brukte dedikerte verktøy i stedet for bash (cat, sed, echo)? |

| Sjekk | Detalj | |-------|--------| | Eksplisitte instrukser | Fulgte agenten brukerens direkte instruksjoner? | | Agent-fil-regler | Fulgte den sin egen agent-definisjon? (Les filen og verifiser) | | CLAUDE.md-regler | Respektert workspace-regler? (MCP-first, no-core-modify, SSH-patterns) | | Scope-disiplin | Holdt seg innenfor sin rolle, eller tok den på seg arbeid den burde delegert? | | Vent-på-instruksjon | Ventet den på faktisk oppgave, eller begynte den å jobbe på window-tittel? |

Før du vurderer noe, identifiser: 1. **Hvilken agent/command** ble brukt? (Les agent-filen om nødvendig: `~/.claude/agents/{name}.md`) 2. **Hvilket workspace** (`$PWD` → suitecrm-dev, reportmaker, magitek-ops, etc.) 3. **Hva var oppdraget?** (Brukerens faktiske instruksjon, ikke window-tittel) 4. **Hvilke MCP-servere** var tilgjengelige? (fra agent-filens `mcpServers:` frontmatter) 5. **Hvilke ekspertfiler/knowledge-filer** burde agenten ha brukt? Uten denne konteksten kan du ikke vurdere om...

**Før du starter, vis dette og vent på bekreftelse:** > `[Anbefalt: sonnet · high · no thinking]` > > Skal jeg starte analysen med disse innstillingene, eller vil du justere først? **Vent på brukerens svar.** Ikke start analysen før brukeren bekrefter. --- Gjennomfør en grundig revisjon av chatten/sesjonen du har fått. Du er en **streng revisor** — ikke diplomat.

**Steg 1 — Vis hele rapporten i chat.** IKKE forkort, avkort, eller oppsummer. Brukeren skal kunne lese alt uten a apne filen. Vis hele markdown-rapporten direkte i chat-svaret. **Steg 2 — Lagre til fil.** Etter at rapporten er vist i chat, lagre den OGSA til fil: **Sti:** `coordination/maintenance/audits/mcp-usage/AUDIT-{YYYY-MM-DD}-{kort-slug}.md` - `{kort-slug}` = 2-4 ord som beskriver sesjonen (f.eks. "infra-vm-oppsett") - Opprett mappene hvis de ikke finnes (`mkdir -p`) - Bruk Write...

- **Agenten er pasienten.** Vurder agentens MCP-bruk, ikke MCP-serverens kvalitet. - **Workspace-bevisst.** Kun MCP-servere som var tilgjengelig i DETTE workspace er relevante. - **Oppgave-relevant.** Ikke kritiser manglende Playwright-bruk for en ren backend-oppgave. - **Konkret.** For hvert funn: si HVILKEN MCP-server, HVILKET tool, og hva agenten gjorde i stedet. - **Positiv anerkjennelse.** Trekk frem god MCP-bruk like tydelig som darlig. - **Ikke gjenta meta-audit.** Denne prompten...

Oppsummer alle utbedringer i en setning og spor: > Jeg fikser sak {direkte-saker} direkte. **OK?** Vent pa brukerens "ja" for du gjor noe. ---

| Score | Betydning | |-------|-----------| | **A** | Brukte alle relevante MCP-servere korrekt, minimalt SSH-fallback, god parallellisering, ingen feilbruk | | **B** | Brukte de fleste MCP-servere, noen fa unodvendige SSH-kall eller minor feilbruk | | **C** | Blanding av MCP og SSH, noe feilbruk av verktoy, eller merkbar slosing | | **D** | Overveiende SSH-bruk til tross for tilgjengelig MCP, alvorlig feilbruk, eller mye slosing | | **F** | Ignorerte MCP-servere fullstendig, eller gjentatt...

| # | Type | Fil/lokasjon | Endring | Prioritet | |---|------|-------------|---------|-----------| | 1 | {agent-fil/knowledge/CLAUDE.md/anti-pattern/gotcha} | {filsti} | {konkret endring} | {HOY/MIDDELS/LAV} | ```

| # | Situasjon | MCP-server | Tool | Hva agenten tapte ved a ikke bruke MCP | |---|-----------|-----------|------|----------------------------------------| | 1 | {kontekst} | `{server}` | `{tool}` | {konsekvens: tokens, tid, kvalitet} | ---

- {konkrete eksempler pa god MCP-utnyttelse}

| # | MCP-server | Tool | Problem | Agentens handtering | Bor dokumenteres? | |---|-----------|------|---------|--------------------|--------------------| | 1 | `{server}` | `{tool}` | {feil/timeout/format} | {retry/fallback/ignorert} | {Ja/Nei} |

| # | Type | MCP-server | Tool | Beskrivelse | Estimert token-kostnad | |---|------|-----------|------|-------------|----------------------| | 1 | {redundant/overbred/sekvensiell/ubrukt} | `{server}` | `{tool}` | {hva som skjedde} | {estimat} |

| # | MCP-server | Tool | Hva agenten gjorde feil | Riktig bruk | Alvorlighet | |---|-----------|------|------------------------|-------------|-------------| | 1 | `{server}` | `{tool}` | {feil parametere, feil tool-valg, feilfortolkning} | {hva som burde vert gjort} | {KRITISK/HOY/MIDDELS/LAV} |

| # | SSH/bash-kommando agenten kjørte | MCP-server som dekker dette | MCP-tool som burde vært brukt | Token-kostnad | |---|----------------------------------|----------------------------|-------------------------------|---------------| | 1 | `{kommando}` | `{server}` | `mcp__{server}__{tool}` | {estimat} |

| Server | Tilgjengelig | Relevant | Brukt | Kall | SSH-fallbacks | Vurdering | |--------|-------------|----------|-------|------|---------------|-----------| | `{server}` | Ja | {Ja/Nei} | {Ja/Nei} | {N} | {N} | {OK/MISS/DELVIS} |

{3-5 setninger. Utnyttet agenten MCP-serverne sine? Brukte den dem riktig? Feilbruk, slosing, bugs? Tapte muligheter?} ---

```markdown # MCP-Usage-Audit: [{agent/command}] — {kort beskrivelse} **Sesjon:** {agent} | **Workspace:** {workspace} | **Dom:** {A/B/C/D/F} **Tilgjengelige MCP-servere:** {antall} | **Brukte:** {antall} | **Relevante men ubrukte:** {antall} **MCP-kall totalt:** {antall} | **Feilbruk:** {antall} | **SSH-fallbacks der MCP fantes:** {antall}

| Sjekk | Detalj | |-------|--------| | Playwright-miss | Var det et deploy/UI-arbeid der Playwright-verifisering ville fanget feil? | | context7-miss | Gjettet agenten framework-detaljer der context7 hadde riktig dokumentasjon? | | Serena-miss | Navigerte agenten kode manuelt der Serena `find_symbol`/`get_references` var raskere? | | Batch-miss | Kunne agenten brukt en MCP-server til a gjore noe i bulk i stedet for lokke? | ---

| Sjekk | Detalj | |-------|--------| | Riktig rekkefolge | Fulgte agenten KB -> ekspert -> MCP -> SSH-rekkefolgen? | | Parallellisering | Kjorte agenten uavhengige MCP-kall parallelt? | | Feilhandtering | Handterte agenten MCP-feil gracefully (retry, fallback)? | | Riktig server | Brukte agenten riktig MCP-server? (f.eks. proxmox-px1 for px1-VMs, ikke proxmox-px3) |

| Sjekk | Detalj | |-------|--------| | Uventet feil | Returnerte et MCP-tool en feil som agenten ikke forventet? Hvordan handterte den det? | | Stille feil | Returnerte MCP "suksess" med feil/tomt/ufullstendig resultat? Merket agenten det? | | Timeout | Tok noen MCP-kall urimelig lang tid? | | Formaterings-overraskelse | Var MCP-output i et format agenten ikke forventet? (f.eks. paginert, trunkert, annet felt-navn) | | Gotcha agenten traff | Traff agenten en kjent MCP-gotcha som burde vert...

| Sjekk | Detalj | |-------|--------| | Redundante kall | Kalte agenten samme MCP-tool flere ganger med identiske parametere? | | Overbredt kall | Hentet agenten ALT (f.eks. alle records) nar et filtrert kall hadde holdt? | | Sekvensielt der parallelt | Kjorte agenten MCP-kall sekvensielt som kunne gatt parallelt? | | Manglende caching | Spurte agenten MCP om noe den allerede hadde fatt svar pa tidligere i samtalen? | | Ubrukt output | Hentet agenten data via MCP som den aldri brukte til noe?...

| Sjekk | Detalj | |-------|--------| | Feil parametere | Sendte agenten feil/ugyldige parametere til et MCP-tool? (feil node, feil VMID, feil modul-navn, etc.) | | Feil tool for oppgaven | Brukte agenten et tool som teknisk fungerte men var feil valg? (f.eks. `list_records` med filter i stedet for `search_records`) | | Feil server | Kalte agenten feil proxmox-server for en VM? (f.eks. proxmox-px1 for en VM som er pa px3) | | Ignorerte output | Fikk agenten svar fra MCP men ignorerte viktig...

| Sjekk | Detalj | |-------|--------| | Unødvendig SSH | Kjørte agenten SSH-kommandoer som en MCP-server kunne svart på? | | Unødvendig grep | Brukte agenten `grep`/`find` i kodebasen der Serena ville vært bedre? | | Unødvendig gjetting | Gjettet agenten API-oppførsel/docs der context7 kunne svart? | | Manglende verifisering | Droppet agenten visuell verifisering med Playwright der det var naturlig? | | Docker via SSH | Brukte agenten `ssh ... "docker ps/logs/exec"` der docker MCP var...

For HVER server som var tilgjengelig OG relevant for oppgaven: | Sjekk | Detalj | |-------|--------| | Brukt? | Ble serveren brukt i det hele tatt? | | Riktig verktøy? | Valgte agenten riktig tool fra serveren? | | Tilstrekkelig? | Brukte agenten serveren nok, eller bare for én ting og falt deretter til SSH? | | Først? | Prøvde agenten MCP FØR SSH for denne typen operasjon? |

| Server | Workspace(s) | Dekker | Typisk fallback | |--------|-------------|--------|-----------------| | `suitecrm` | suitecrm-dev, magitek-ops | CRM-data, metadata, moduler, layouts, deploy | SSH + grep i SuiteCRM-filer | | `mysql` | suitecrm-dev, reportmaker | Database-queries | `ssh ... "mysql -e '...'"` | | `reportmaker` | reportmaker | App-spesifikke operasjoner | SSH + artisan-kommandoer | | `dam-sqlite` | magitek-ops | DAM-database | Manuell SQLite-queries | | `lighthouse` |...

| Server | Dekker | Typisk fallback | |--------|--------|-----------------| | `serena` | Kodebase-navigering, symboler, referanser | `grep -r`, `find . -name`, manuell fil-lesing for definisjoner | | `context7` | Bibliotek/framework-dokumentasjon | Gjetting, utdatert kunnskap, feil API-bruk | | `playwright` | Browser-testing, visuell verifisering | Ingen verifisering, anta at deploy fungerer |

| Server | Dekker | Typisk SSH-fallback som indikerer MCP-bypass | |--------|--------|----------------------------------------------| | `proxmox-px1` | VM/CT på px1 (hjemme) | `ssh TU-px1 "qm list"`, `ssh TU-px1 "pct list"` | | `proxmox-px3` | VM/CT på px3 (hjemme) | `ssh TU-px3 "qm list"` | | `proxmox-hjemme` | Hjemme-cluster samlet | `ssh TU-px5 "qm status"` | | `proxmox-pmox2` | VM/CT på pmox2 (kontoret) | `ssh pmox2 "qm list"` | | `proxmox-pmox10` | VM/CT på pmox10 (kontoret) | `ssh pmox10...

Bruk dette kartet til å vurdere om agenten brukte riktig server for oppgaven:

1. **Hvilken agent/command** ble brukt? 2. **Hvilket workspace** (`$PWD`) 3. **Hvilke MCP-servere var tilgjengelige?** (fra agent-filens `mcpServers:` frontmatter + workspace `.mcp.json`) 4. **Hva var oppgaven?** (Brukerens faktiske instruksjon) 5. **Hvilke MCP-servere var RELEVANTE** for denne spesifikke oppgaven? For punkt 3, les `.mcp.json` i workspace-roten hvis du er usikker: ```bash cat "$PWD/.mcp.json" 2>/dev/null | python3 -c "import json,sys;...

**Før du starter, vis dette og vent på bekreftelse:** > `[Anbefalt: sonnet · high · no thinking]` > > Skal jeg starte analysen med disse innstillingene, eller vil du justere først? **Vent på brukerens svar.** Ikke start analysen før brukeren bekrefter. --- Gjennomfør en grundig analyse av om agenten **utnyttet tilgjengelige MCP-servere** korrekt. Du vurderer agentens MCP-bruk, IKKE MCP-servernes kodekvalitet (det gjør `/prompt-agent-chat-mcp-audit`). > **Scope:** ALLE MCP-servere som var...

**Steg 1 — Vis hele rapporten i chat.** IKKE forkort, avkort, eller oppsummer. Brukeren skal kunne lese alt uten å åpne filen. Vis hele markdown-rapporten direkte i chat-svaret. **Steg 2 — Lagre til fil.** Etter at rapporten er vist i chat, lagre den OGSÅ til fil: **Sti:** `coordination/maintenance/audits/mcp/AUDIT-{YYYY-MM-DD}-{kort-slug}.md` - `{kort-slug}` = 2-4 ord som beskriver sesjonen (f.eks. "lead-navn-synk-hooks") - Opprett mappene hvis de ikke finnes (`mkdir -p`) - Bruk Write tool...

- **MCP-serveren er pasienten, ikke agenten.** Vurder serverens oppførsel, ikke agentens kompetanse. - **Kun egenbygde servere.** Tredjepart (context7, serena, playwright, etc.) er utenfor scope. - **Konkret og implementerbar.** Hver feil/mangel skal ha nok detalj til at en utvikler kan fikse den uten å lese hele chat-loggen. - **Prioriter etter smerte.** Bugs som tvinger SSH/bash-fallback = høy prioritet. Kosmetiske forbedringer = lav. - **Scope-respekt.** Denne auditen IDENTIFISERER...

Oppsummer alle entries i en setning og spoer: > Jeg logger sak {#, #, ...} til GAP-trackeren. **OK?** Vent paa brukerens "ja" foer du gjoer noe. **Ved "ja":** Logg ALLE entries via gap-cli.sh. Ikke filtrer basert paa prioritet. Ikke hopp over entries du mener er "aapenbare" eller "for enkle". Alle funn logges. I tillegg, hvis noen funn er kritiske nok til aa fikse umiddelbart: - **Spawn `mcp-server-builder`** subagent direkte fra denne sesjonen for enkle bugfixes - **Generer LLM-prompt** du...

**KRITISK REGEL: Auditor filtrerer IKKE. ALLE funn fra seksjonene "MCP-feil", "MCP-mangler", og "Tool-forbedringer" SKAL logges som GAPs. Prioritet-feltet er informasjon for MCP-utvikleren — ikke et filter for hva som logges.** List opp ALLE entries som skal logges: | # | Type | Tittel | Server | Prioritet | |---|------|--------|--------|-----------| | 1 | `gap\|error\|perf\|ux` | {tittel fra funnene over} | {suitecrm\|reportmaker} | {high\|medium\|low} | **Logging via gap-cli.sh** (soek...

- {tools som fungerte bra og sparte agenten tid} ---