Skills, Subagents, MCP og Plugins i Claude Code: Hvilken bør du velge?

Akkurat nå finnes det fem måter å gjøre den samme kodegjennomgangen på i Claude Code: en slash-kommando, en skill, en subagent, en plugin eller ganske enkelt en prompt i chatten. Ingen av disse måtene er som standard bedre enn de andre; valget avhenger av oppgaven, tokenbudsjettet og hvem andre enn deg som skal bruke den.

Dette er veiledningen jeg skulle ønske jeg hadde gitt meg selv for et år siden. Et tre med 4 spørsmål, en ferdig matrise for «oppgave → lag» og 5 vanlige feil som sløser med tokens for omtrent hver eneste vibe coder jeg jobber med.

Om hvordan du bruker tjenesten – i Ailoot-dokumentasjonen.

Hva er skills, subagenter, MCP og plugins med én setning?#

Før vi velger, skal vi skille mellom begrepene. Alle de fire lagene har samme mål – å utvide det Claude kan gjøre rett ut av boksen. Men hvert lag har sin egen natur.

Skill er en mappe med en SKILL.md-fil som beskriver når og hvordan du skal bruke en bestemt arbeidsmetode. Anthropic sammenligner en skill med instruksjoner for en ny medarbeider: Du dikterer ikke hvert eneste trinn for dem hver dag; du gir dem en framgangsmåte.

Subagent er en separat Claude-økt med egen kontekst, startet fra hovedsamtalen. Den har én viktig egenskap: isolasjon. En subagent kan lese 30 filer, lage et sammendrag og bare sende dette tilbake til hovedchatten. Konteksten i hovedsamtalen forblir ryddig.

MCP (Model Context Protocol) er en åpen standard fra Anthropic for å koble Claude til eksterne systemer. I et blogginnlegg 13. november 2025 forklarte Anthropic forskjellen så tydelig som mulig:

Plugin er en ferdig samling fra noen andre med skills, subagenter, hooks og kommandoer, pakket i en markedsplass. Installer den med én linje ved hjelp av /plugin install, så får du alt på én gang. Hvis en skill er din egen framgangsmåte, er en plugin en framgangsmåte du har kjøpt fra et annet selskap.

Kort sagt er skills oppskrifter, subagenter er spesialiserte kolleger, og MCP gir Claude tilgang til eksterne verktøy som lar den nå tjenester og data. Tokenkostnaden varierer: En skill er billigst (den lastes når den utløses), mens MCP er betydelig dyrere (hver tilkoblede server opptar plass i kontekstvinduet hele tiden).

Hvorfor 4 lag når du kan bruke én CLAUDE.md?#

I prosjektet som er beskrevet, er CLAUDE.md et stort kart over regler: hvor ting skal ligge, hvordan man publiserer, og hvilke avtaler som gjelder. Uten denne filen ville Claude begynt på nytt i hver nye økt.

Men CLAUDE.md har en grense. La meg forklare tre situasjoner der den slutter å fungere.

Situasjon 1: En regel fungerer bare noen ganger. CLAUDE.md sier: «Kjør alltid npm run build før git push.» Claude leser det i starten av økten, nikker, begynner å skrive kode etter 25 meldinger og glemmer det. Jeg har allerede tatt meg selv i å pushe uten å bygge tre ganger; de pushene mislyktes i produksjon. En riktig konfigurert og testet hook kan kjøre en deterministisk byggkontroll og avvise den dekkede operasjonen. Dekningen avhenger av hendelsen og verktøyruten. En Claude Code-hook fanger ikke i seg selv opp hver push fra en annen terminal eller applikasjon. Verifiser at et bevisst feilende bygg blokkerer den faktiske ruten du bruker.

Situasjon 2: En prosess på 15 trinn som gjentas. I eksemplet som er beskrevet, går hver veiledning gjennom 14 faser: research → struktur → MDX → 7 parallelle QA-kontroller → publisering til produksjon → IndexNow. Hvis jeg skriver en prompt hver gang der jeg sier «kjør fase 1, deretter 2, så 3», sløser jeg med tokens før jeg i det hele tatt har kommet i gang. Derfor er hele denne arbeidsflyten pakket inn i skillen build-masterskaya-guide – et instruksjonssett på 34 KB som startes med uttrykket «la oss lage en ny veiledning for prosjektet».

Situasjon 3: En oppgave sluker konteksten. For å kontrollere om en allerede publisert veiledning er oppdatert, må Claude lese et livestream-transkript på 30 KB, 20 retrospektiver på 5 KB hver og sammenligne dem med det nåværende nettstedet. Hvis jeg gjør dette i hovedchatten, ender jeg med 200K tokens med rusk i konteksten mot slutten av gjennomgangen. En subagent gjør det samme arbeidet, sender bare et sammendrag på 300 ord tilbake til hovedsamtalen og avslutter.

Situasjon 4: Jeg vil at teamet skal få de samme malene som jeg har. Et ferdig sett med regler for frontend-design, hooks for publisering via Coolify og MCP for Playwright-kontroller. Det er en plugin: Jeg pakker oppsettet mitt, publiserer det i markedsplassen, og en kollega installerer det med én linje.

CLAUDE.md dekker det grunnleggende: «slik gjør vi ting her». De 4 lagene på toppen dekker det CLAUDE.md fysisk ikke kan: gjentakelse gjennom triggere, kontekstisolering, tilgang til omverdenen og deling.

Når trenger du en skill i stedet for CLAUDE.md?#

Testen på om du trenger en skill, er enkel: Du tar deg selv i å kopiere den samme lange prompten fra notatene dine inn i chatten. Tredje gang er allerede et signal.

Jeg har for tiden 7 mapper i ~/.claude/skills/: build-masterskaya-guide, build-vc-spoke, build-reel-script, build-practicum-instruction, update-config, simplify og keybindings-help. Den jeg bruker mest, er build-masterskaya-guide (denne veiledningen ble skrevet med den). Den inneholder 34 KB med arbeidsmetode: hvilke faser man skal gjennom, hvilke QA-kontroller med flere agenter som skal kjøres, hvilke gate-vilkår som skal stanse prosessen, og hvilke artefakter som skal lagres i /tmp/.

Når du ikke bør lage en skill.

• En regel som «svar på brukerens foretrukne språk» hører hjemme i CLAUDE.md, ikke i en skill. En skill lastes når den utløses, men denne regelen bør alltid gjelde.
• En instruksjon du bare bruker én gang, som «kjør refaktoreringen nå», hører hjemme i chatten, ikke i en skill.
• En oppgave som trenger separat kontekst, kan bruke en subagent. Følger den også en gjentakende prosedyre, bevares arbeidsmetoden i en skill.

Det viktigste antidesignmønsteret. Den vanligste feilen vibe codere gjør, er å presse en prosedyre inn i en subagent når den burde vært en skill. En subagent koster flere tokens (den har sin egen kontekst), starter saktere og er ofte overkill. Hvis oppgaven får plass i 1,500–2,000 ord med metode uten å lese eksterne filer, er den en skill.

Slik strukturerer du en skill, hva du skal ha i frontmatter, og hvilke triggerfraser som fungerer – i veiledningen Claude Code Skills in 2026: How to Build a Personal Skills Library.

Når trenger du en subagent i stedet for en skill?#

En skill lagrer arbeidsmetoden; en subagent utfører arbeidet. Det er ulike lag, men de forveksles ofte fordi begge startes «fra chatten».

En subagent gir bare mening for kontekstisolering. Hovedøkten i Claude har et budsjett på 200,000 tokens (eller 1 million i betaversjon). Hvis du ber Claude i hovedchatten lese 30 filer og analysere hver av dem, bruker du opp halve vinduet på mellomliggende lesing. En subagent gjør det samme arbeidet i en separat økt og sender bare resultatet tilbake til hovedchatten.

Et konkret prosjekteksempel. Hver veiledning går gjennom flere parallelle QA-kontroller: stil, sitater og fakta kontrollert mot primærkilder, struktur for søkemotorer og integriteten til interne og eksterne lenker. Hver kontroll trekker på sin egen kontekst: en ordliste med regler, WebFetch mot dusinvis av URL-er og grep-søk i teksten.

Hvis jeg kjørte alle disse kontrollene i én chat, ville konteksten tatt knekken på meg før den første var ferdig. Å kjøre subagenter parallelt med run_in_background: true løser dette: De jobber i bakgrunnen, hovedchatten går videre, og etter 4–6 minutter får jeg korte rapporter og gjennomfører endringene.

Et andre eksempel – omfattende research. Når jeg velger et tema til en ny veiledning, samler 4 subagenter signaler parallelt:

• V1 - forum og fellesskap over 14 dager
• V2 - sosiale nettverk
• V3 - videoplattformer + Anthropic-bloggen
• V4 - SEO-hull

Hver returnerer 30–40 elementer med viralitetspoeng. Jeg samler dem i en gruppe, vekter dem etter 9 dimensjoner og velger en vinner. Uten subagenter tar denne fasen 2–3 timer og bruker opp hovedkonteksten.

Når du ikke bør lage en subagent.

• En oppgave som ikke krever at du leser filer eller bruker WebFetch, hører hjemme i hovedchatten.
• En gjentakende prosedyre hører hjemme i en skill, men kan kjøre i en subagent når isolasjon er nyttig.
• Ekstern tilgang trenger et godkjent verktøy som MCP eller CLI. En subagent kan bruke verktøyet når oppgaven delegeres.

Det viktigste antidesignmønsteret. Å opprette en subagent med navnet backend-engineer eller qa i håp om at Claude skal finne ut når den skal brukes. Spesifikke subagenter (som migration-test-writer eller api-route-reviewer) gir mye bedre kvalitet enn generiske. Jo mer presist navn og instruksjoner er, desto mer nøyaktig velger Claude riktig subagent.

Slik lager du subagenter for bestemte oppgaver, syntaks for frontmatter og 5 ferdige eksempler – i veiledningen Claude Code Subagents in 2026: A Step-by-Step Guide.

Når trenger du MCP i stedet for en skill eller subagent?#

Anthropic ga den korteste formelen for forskjellen i et blogginnlegg: MCP kobler Claude til data; skills lærer Claude hva den skal gjøre med dataene.

En skill for GitHub-issuegjennomgang trenger for eksempel innholdet i saken. Gi dette gjennom et godkjent MCP-verktøy, et CLI eller tilført tekst. Skillen definerer så gjennomgang og funnstruktur; MCP-tilgang alene foreskriver ikke prosedyren.

Min konkrete MCP-stakk.

• Playwright MCP - visuell QA for hver veiledning. Åpne siden på desktop og mobil, sjekk bredden på containeren og om blokkene er gjengitt.
• Stitch MCP - tilgang til designsystemet, generering av komponenter i merkevarens stil.
• vidIQ MCP - trendanalyse og kontroll av ideer for viralitet.
• Railway MCP - administrasjon av utrullingsinfrastruktur.

Hver av disse 4 er en bro til et eksternt system. Uten MCP måtte jeg enten skrevet min egen wrapper-kode eller gått over til en nettleser. Med MCP foregår alt inne i Claude-økten.

Tokenkostnad. MCP er det dyreste laget. Hver tilkoblede server opptar hele tiden plass i kontekstvinduet: verktøydeklarasjoner, argumentasjonskjemaer og beskrivelser. Jeg har 4 MCP-servere – det er omtrent 8–12K tokens i hver nye økt før jeg har spurt om noe som helst.

Det betyr at vi bare kobler til MCP hvis det faktisk trengs i de fleste økter. Hvis du bruker Sentry MCP én gang i uka, er det bedre å aktivere den ved behov med flagget --mcp sentry enn å ha den permanent i lista.

Når du ikke bør bruke MCP.

• Metode for «hvordan jobbe med data» hører hjemme i en skill, ikke i MCP.
• En lang leseoppgave kan ha nytte av en subagent. Er noen filer eller oppføringer eksterne, kan den subagenten også trenge MCP-tilgang.
• Publisering med én kommando krever en hook eller plugin, ikke MCP.

Det viktigste antidesignmønsteret. Å bygge en MCP-server for noe som håndteres bedre av en skill. Jeg så et eksempel i en HN-diskusjon (den samme tråden som fikk 422 poeng 27. mai): Forfatteren skrev en MCP-server som tilbyr «instruksjoner for kodegjennomgang». Men det er ikke tilgang til omverdenen; det er en prosedyre. En skill gjør det samme med 10 ganger færre tokens.

En hendelse med konkurranse om en ressurs. En gang hang Playwright MCP seg med feilen «Browser is already in use» – jeg hadde et Chrome-vindu åpent samtidig, og MCP kunne ikke ta kontroll over nettleseren. Dette er en viktig lærdom: En MCP-server bruker delte systemressurser. Hvis en ressurs er opptatt (en nettleser, port eller fil), bør du tenke på isolering fra starten.

En ferdig veiledning i hvordan du kobler til 7 MCP-er som fungerer, finner du i Claude Code MCP Servers in 2026: 7 Ready-to-Use Setups.

Når trenger du en plugin i stedet for en skill eller subagent?#

Skills, subagenter og MCP handler om din metode. En plugin er andres ferdige metode som du importerer til oppsettet ditt.

I oktober 2025 lanserte Anthropic Claude Code Plugins, en offisiell distribusjonsmekanisme. En plugin er en mappe som kan inneholde:

• egne slash-kommandoer
• egne skills
• egne subagenter
• egne hooks
• egne MCP-konfigurasjoner
• egne utdataformater

Alt dette pakkes i én pakke med plugin.json. Installasjonen gjøres med én linje i ~/.claude/settings.json eller kommandoen /plugin install <name>.

Min konkrete plugin-stakk.

• frontend-design fra den offisielle claude-plugins-official – 67 stiler, 96 paletter, 57 skrifttypepar og 13 rammeverk. Når jeg lager en ny blokk til nettstedet eller en e-postmal, laster jeg denne pluginen og får hele biblioteket på én gang.
• playwright fra den samme offisielle markedsplassen – en samling skills pluss MCP-konfigurasjoner for nettlesertesting.
• telegram – en ferdig samling for å administrere en Telegram-konto fra Claude Code (policy, allowlist, paring).
• trailofbits/skills – en samling sikkerhetsskills fra Trail of Bits, et selskap jeg stoler på når det gjelder sikkerhet.

Alle 4 utgjør tre linjer i settings.json. Uten plugins ville jeg brukt flere timer på å bygge det samme biblioteket for hånd.

Når du ikke bør bruke en plugin.

• Hvis metoden er helt din egen og ikke er relevant for andre, bør du beholde den som en skill.
• Hvis du ikke vet hvem som skal bruke den ennå, kan du prøve den selv som en skill først.
• Hvis du raskt trenger å legge tre filer på en ny maskin, holder det med cp ~/.claude/skills/X /new/machine/.claude/skills/.

Det viktigste antidesignmønsteret. Å bruke en plugin som erstatning for CLAUDE.md – for eksempel en plugin med regler for «slik gjør vi ting i dette prosjektet». En plugin er laget for distribusjon og gjenbruk. Hvis reglene gjelder bare ett repository, hører de hjemme i CLAUDE.md, ikke i en plugin.

Fram mot 2026 beveger Anthropic seg tydelig mot en teammarkedsplass for plugins. Det betyr at selskaper vil kunne publisere de interne arbeidsmetodene sine som plugins, versjonere dem og oppdatere dem for alle ansatte med én kommando. For en selvstendig næringsdrivende betyr det: Installer det som allerede finnes, og ikke finn opp hjulet på nytt.

Beslutningstre: 4 spørsmål du bør stille før hver oppgave#

Spørsmål 1: Finnes en gjentakende prosedyre som er verdt å bevare?

Pakk i så fall arbeidsmetoden som en skill i en SKILL.md-fil med tydelig beskrivelse av når den skal brukes. Dette gir prosedyren, men ikke ekstern tilgang eller separat kontekst i seg selv.

Spørsmål 2: Bør arbeidet ha separat kontekst eller en fokusert delegert rolle?

Bruk i så fall en subagent. Gi den en presis oppgave og verktøy. Samme oppgave kan følge en skills arbeidsmetode i den isolerte konteksten.

Spørsmål 3: Trenger oppgaven et verktøy eller tilgang til eksterne data?

Gi i så fall godkjent tilgang gjennom MCP eller et annet egnet verktøy, for eksempel et allerede konfigurert CLI. En skill beskriver hvordan tilgangen brukes; en subagent kan være aktøren som bruker den.

Spørsmål 4: Bør oppsettet distribueres og vedlikeholdes som en pakke?

Bruk i så fall en plugin til å distribuere relevante skills, agentdefinisjoner, hooks eller MCP-konfigurasjon. Pakken kan være din egen eller laget av en annen forfatter.

Kombinert eksempel: gjentakende gjennomgang av GitHub-issues. En skill definerer prosedyre og resultatformat. Et konfigurert GitHub-MCP eller CLI gir godkjent tilgang til issues. En subagent kan lese en lang tråd i egen kontekst og returnere funn. En plugin kan distribuere kombinasjonen til teamet. Alle fire svar kan være «ja»; ingen opphever et annet.

5 feil vibe codere gjør når de velger lag#

Jeg ser disse 5 mønstrene én gang i uka blant vibe coderne jeg jobber med. Annenhver person gjør minst én av dem i løpet av den første uka.

Feil 1: subagent i stedet for skill.

Symptom: En forfatter opprettet en subagent for «å skrive et nytt blogginnlegg». Hver gang forfatteren kjører subagenten, lastes den inn, leser 2 KB med arbeidsmetode, genererer et innlegg og avslutter. Etter en uke oppdager forfatteren at hver kjøring bruker 5K ekstra tokens på å laste subagenten.

Hva som burde skjedd: «hvordan skrive et innlegg» er en arbeidsmetode – altså en skill. Triggeren er uttrykket «nytt blogginnlegg». Skillen lastes inn i hovedchatten og åpner ikke en egen økt. Det er 3–5 ganger billigere.

Feil 2: MCP-server i stedet for skill.

Symptom: En forfatter skrev en MCP-server som gir instruksjoner om «hvordan utføre en kodegjennomgang». Verktøydeklarasjoner, beskrivelser av argumentskjemaer og dokumentasjon fortsetter å oppta kontekst. Hver forespørsel sløser med 2–3K tokens uten grunn.

Hva som burde skjedd: «hvordan utføre en kodegjennomgang» er en prosedyre, ikke tilgang til et eksternt system. Bruk en skill. MCP er bare berettiget hvis du trenger direkte tilgang – for eksempel til Sentry for å hente de nyeste feilene.

Feil 3: plugin i stedet for CLAUDE.md.

Symptom: En forfatter pakket prosjektregler («bruk alltid streng TypeScript-modus», «ikke bruk noen tankestreker», «bruk bare pnpm, ikke npm») i en plugin og installerte den. Nå laster hver nye økt en plugin som gjentar det som burde stå i CLAUDE.md.

Hva som burde skjedd: Regler for ett prosjekt hører hjemme i CLAUDE.md for det prosjektet. En plugin er for en arbeidsmetode som kan brukes av flere personer eller i flere repositories.

Feil 4: forsøke å lage en skill via en hook.

Symptom: En forfatter så at en hook kjøres automatisk ved en hendelse (for eksempel før en fil lagres). Forfatteren bestemte seg for å lage en «skill via en hook», slik at Claude automatisk skulle bruke arbeidsmetoden ved hver redigering. Resultatet ble en endeløs triggerløkke, konteksten ble brukt opp og atferden ble uforutsigbar.

Hva som burde skjedd: En hook er deterministisk kode som kjører en kommando, formaterer resultatet eller blokkerer en handling. En hook laster ikke en skill og starter ikke Claude. Hvis du trenger å «alltid bruke metode X», kan du bruke enten en skill med en trigger eller en oppføring i CLAUDE.md.

Feil 5: et ekstra lag når ingenting trengs.

Symptom: En forfatter hører om skills, leser veiledninger, bestemmer seg for at «jeg må pakke denne arbeidsmetoden» og bruker en hel kveld på å lage en skill for en oppgave som dukker opp én gang i måneden.

Hva som burde skjedd: En engangsoppgave hører hjemme ad hoc i chatten. En skill er bare berettiget hvis du gjør dette mer enn én gang om dagen. Ellers er det overutvikling som må vedlikeholdes etterpå.

Kontroller behovene uavhengig i disse eksemplene: prosedyre, kontekst- eller rolleisolasjon, verktøytilgang og distribusjon. Legg til hvert lag med et konkret formål, og kombiner dem når en oppgave trenger flere.

Hva Anthropic sier om fragmentering: Hvor går Claude Code i 2026?#

Hva dette betyr de neste seks månedene til et år.

For det første: skills blir hovedlaget for prosedyreoppgaver. Anthropic satser tydelig på dette laget fordi det er billigst og mest forutsigbart. Hvis du ikke forstår hvorfor du skulle trenge en skill i 2026, bør du sette deg inn i det først. Alle de andre lagene vil dreie seg rundt det.

For det andre: subagenter blir spesialiserte. Hovedoppgaven for subagenter er kontekstisolering ved krevende oppgaver. Generiske subagenter som qa-engineer vil forsvinne; spesifikke som migration-test-writer og api-route-reviewer vil bestå.

For det tredje: Anthropic sine nye kunngjøringer de siste 14 dagene – kommandoen /workflows (28. mai 2026) for å koordinere dusinvis av subagenter og separat fakturering for Agent SDK fra 15. juni – betyr at programmatisk bruk flyttes til en egen pott. Dette er et tegn på at Anthropic bygger infrastruktur for automatiserte systemer med 10+ agenter, ikke for individuelle økter.

For en vibe coder i 2026 betyr dette én enkel ting: De fire lagene vil vare i minst seks måneder til, og deretter vil noen av dem slås sammen. Men beslutningstreet med fire spørsmål vil fortsatt fungere etter sammenslåingen – det handler om oppgavens natur, ikke det konkrete navnet på laget.

Ferdig matrise: 10 typiske oppgaver → riktig lag#

Hovedregelen for å bruke denne tabellen er å ikke prøve å «gjøre alle 10 tingene på én gang». De fleste solo-vibe codere klarer seg med CLAUDE.md + 5–7 skills + 2–4 MCP-servere. Subagenter og plugins kommer til etter hvert som prosjektet vokser.

Hva nå: Slik bygger du arbeidsområdet ditt i Claude Code#

Disse fem lagene står ikke etter hverandre; de passer inn i hverandre. CLAUDE.md er prosjektets grunnmur, og de fire andre kobles til etter hvert som oppgavene vokser.

Bli kjent med Ailoot.