Skills, subagenter, MCP och plugins i Claude Code: vilket ska du välja

Just nu finns det i Claude Code fem sätt att göra samma kodgranskning: ett snedstreckskommando, en skill, en subagent, ett plugin eller helt enkelt en prompt i chatten. Och inget av dessa sätt är som standard bättre än de andra — valet beror på uppgiften, tokenbudgeten och vem utöver dig som ska använda det.

Den här guiden är vad jag önskar att jag hade fått för ett år sedan. Ett träd med 4 frågor, en färdig matris för ”uppgift → lager” och 5 vanliga misstag som slösar med tokens för varannan vibe-kodare jag arbetar med.

Om hur du arbetar med tjänsten – i Ailoot-dokumentationen.

Vad är skills, subagenter, MCP och plugins i en mening?#

Innan vi väljer behöver vi skilja på begreppen. Alla fyra lager har samma mål: att utöka vad Claude kan göra direkt. Men varje lager har sin egen karaktär.

Skill är en katalog med en fil som heter SKILL.md, där det står när och hur en viss metod ska användas. Anthropic jämför en skill med instruktioner för en nyanställd: du berättar inte varje steg för personen varje dag, utan ger hen en arbetsmetod.

Subagent är en separat Claude-session med egen kontext, som startas från huvudkonversationen. Den har en viktig egenskap: isolering. En subagent kan läsa 30 filer, skriva en sammanfattning och bara skicka tillbaka den till huvudchatten. Huvudkonversationens kontext förblir ren.

MCP (Model Context Protocol) är en öppen standard från Anthropic för att koppla Claude till externa system. I ett blogginlägg den 13 november 2025 förklarade Anthropic skillnaden så tydligt det går:

Plugin är någon annans färdiga samling av skills, subagenter, hooks och kommandon, paketerad på en marknadsplats. Installera den med en enda rad med /plugin install, så får du allt på en gång. Om en skill är din egen arbetsmetod är ett plugin en arbetsmetod som köpts från ett annat företag.

Kort sagt är skills recept, subagenter specialiserade kollegor och MCP tillhandahåller externa verktyg som Claude kan använda för att nå tjänster och data. Tokenkostnaden varierar: en skill är billigast (den laddas när den aktiveras), medan MCP är betydligt dyrare (varje ansluten server tar ständigt upp plats i kontextfönstret).

Varför 4 lager när man kan använda en enda CLAUDE.md?#

I projektet som beskrivs är CLAUDE.md en stor karta med regler: var saker ska ligga, hur man publicerar och vilka överenskommelser som gäller. Utan den filen skulle Claude börja om från början i varje ny session.

Men CLAUDE.md har en övre gräns. Låt mig förklara med tre situationer där den slutar fungera.

Situation 1: en regel fungerar bara ibland. CLAUDE.md säger: ”kör alltid npm run build före git push.” Claude läser den i början av sessionen, nickar, börjar skriva kod efter 25 meddelanden och glömmer. Jag har redan kommit på mig själv med att pusha utan att bygga tre gånger; de pusharna misslyckades i produktion. En korrekt konfigurerad och testad hook kan köra en deterministisk byggkontroll och neka den operation som omfattas. Täckningen beror på händelse och verktygsväg: en Claude Code-hook fångar inte i sig varje push från en annan terminal eller applikation. Verifiera att ett avsiktligt misslyckat bygge blockerar den faktiska väg du använder.

Situation 2: en process i 15 steg som upprepas. I exemplet som beskrivs går varje guide igenom 14 steg: research → struktur → MDX → 7 parallella QA-kontroller → publicering i produktion → IndexNow. Om jag varje gång skriver en prompt med ”kör steg 1, sedan 2, sedan 3” slösar jag med tokens innan jag ens har kommit i gång. Därför är hela arbetsflödet paketerat i skillen build-masterskaya-guide — en uppsättning instruktioner på 34 KB som startas med frasen ”nu gör vi en ny guide för projektet”.

Situation 3: en uppgift slukar kontext. För att kontrollera om en redan publicerad guide är aktuell måste Claude läsa en livestream-transkription på 30 KB, 20 retrospektiv på 5 KB vardera och jämföra dem med den aktuella webbplatsen. Om jag gör detta i huvudchatten har jag 200K värdelösa tokens i min kontext när granskningen är klar. En subagent gör samma arbete, skickar tillbaka en sammanfattning på bara 300 ord till huvudkonversationen och avslutar.

Situation 4: jag vill att teamet ska få samma mallar som jag har. En färdig uppsättning regler för frontend-design, hooks för publicering via Coolify och MCP för Playwright-kontroller. Det är ett plugin: jag paketerar mitt upplägg, publicerar det på marknadsplatsen och en kollega installerar det med en enda rad.

CLAUDE.md täcker grunderna: ”så här gör vi här”. De 4 lagren ovanpå täcker sådant som CLAUDE.md rent fysiskt inte kan hantera: upprepning via utlösare, kontextisolering, åtkomst till omvärlden och delning.

När behöver du en skill i stället för CLAUDE.md?#

Testet för en skill är enkelt: du kommer på dig själv med att kopiera samma långa prompt från dina anteckningar till chatten. Tredje gången är redan en signal.

Just nu har jag 7 kataloger i ~/.claude/skills/: build-masterskaya-guide, build-vc-spoke, build-reel-script, build-practicum-instruction, update-config, simplify och keybindings-help. Den som används mest är build-masterskaya-guide (den här guiden skrevs med den). Inuti finns 34 KB metodik: vilka steg som ska följas, vilka QA-kontroller med flera agenter som ska köras, vilka grindvillkor som ska stoppa processen och vilka artefakter som ska sparas i /tmp/.

När du inte ska skapa en skill.

• En regel som ”svara på användarens föredragna språk” hör hemma i CLAUDE.md, inte i en skill. En skill laddas när den aktiveras, men den regeln ska alltid gälla.
• En engångsinstruktion som ”kör omstruktureringen nu” hör hemma i chatten, inte i en skill.
• En uppgift som behöver separat kontext kan använda en subagent; om den också följer en återkommande procedur behåller du metodiken i en skill.

Det främsta felmönstret. Det vanligaste misstaget bland vibe-kodare är att klämma in en procedur i en subagent när den borde vara en skill. En subagent kostar fler tokens (den har egen kontext), startar långsammare och är ofta överdriven. Om uppgiften ryms inom 1 500–2 000 ord metodik utan att läsa externa filer är den en skill.

Så här strukturerar du en skill, vad du ska ha i frontmatter och vilka utlösande fraser som fungerar – i guiden Claude Code Skills 2026: Så bygger du ett personligt skillsbibliotek.

När behöver du en subagent i stället för en skill?#

En skill lagrar metoden; en subagent utför arbetet. Det är olika lager, som ofta blandas ihop eftersom båda startas ”från chatten”.

En subagent är bara meningsfull för kontextisolering. Den huvudsakliga Claude-sessionen har en budget på 200 000 tokens (eller 1 miljon i beta). Om du ber den läsa 30 filer och analysera var och en i huvudchatten förbrukar du halva fönstret på mellanliggande läsning. En subagent gör samma arbete i en separat session och skickar bara resultatet tillbaka till huvudchatten.

Ett konkret projexempel. Varje guide genomgår flera parallella QA-kontroller: stil, citat och fakta mot primärkällor, struktur för sökmotorer samt integritet hos interna och externa länkar. Varje kontroll använder sin egen kontext: en ordlista med regler, WebFetch på dussintals URL:er och sökningar genom texten.

Om jag körde alla de här kontrollerna i en enda chatt skulle kontexten äta upp mig innan den första var klar. Att köra subagenter parallellt med run_in_background: true löser det: de arbetar i bakgrunden, huvudchatten går vidare och efter 4–6 minuter får jag korta rapporter och gör ändringarna.

Ett andra exempel – omfattande research. När jag väljer ämne till en ny guide samlar 4 subagenter in signaler parallellt:

• V1 - forum och communities under 14 dagar
• V2 - sociala nätverk
• V3 - videoplattformar + Anthropics blogg
• V4 - SEO-luckor

Var och en returnerar 30–40 poster med virala poäng. Jag samlar dem i en pool, viktar dem över 9 dimensioner och väljer en vinnare. Utan subagenter tar det här steget 2–3 timmar och bränner huvudkontexten.

När du inte ska skapa en subagent.

• En uppgift som inte kräver att du läser filer eller använder WebFetch hör hemma i huvudchatten.
• En återkommande procedur hör hemma i en skill, men kan köras i en subagent när isolering är användbar.
• Extern åtkomst behöver ett godkänt verktyg som MCP eller CLI; en subagent kan använda verktyget när uppgiften delegeras.

Det främsta felmönstret. Att skapa en subagent som heter backend-engineer eller qa i hopp om att Claude ska förstå när den ska användas. Specifika subagenter (som migration-test-writer eller api-route-reviewer) ger ofta mycket bättre kvalitet än generiska. Ju mer exakt namn och instruktioner subagenten har, desto mer träffsäkert väljer Claude den.

Så skapar du subagenter för specifika uppgifter, syntax för frontmatter och 5 färdiga exempel – i guiden Claude Code Subagenter 2026: En steg-för-steg-guide.

När behöver du MCP i stället för en skill eller subagent?#

Anthropic gav den kortaste formeln för skillnaden i ett blogginlägg: MCP kopplar Claude till data; skills lär Claude vad den ska göra med datan.

Till exempel behöver en skill för GitHub-ärendegranskning ärendets innehåll. Ge det genom ett godkänt MCP-verktyg, CLI eller tillhandahållen text. Skillen definierar sedan hur granskningen görs och fynden struktureras; MCP-åtkomst ensam föreskriver ingen sådan procedur.

Min specifika MCP-uppsättning.

• Playwright MCP - visuell QA för varje guide. Öppna sidan på dator och mobil, kontrollera behållarens bredd och om blocken har renderats.
• Stitch MCP - åtkomst till designsystemet och generering av komponenter i varumärkets stil.
• vidIQ MCP - trendanalys och kontroll av idéers potential att spridas.
• Railway MCP - hantering av driftsättningsinfrastruktur.

Var och en av dessa 4 är en brygga till ett externt system. Utan MCP skulle jag antingen skriva egen wrapperkod eller byta till en webbläsare. Med MCP sker allt inuti Claude-sessionen.

Tokenkostnad. MCP är det dyraste lagret. Varje ansluten server tar ständigt upp plats i kontextfönstret: verktygsdeklarationer, argumentscheman och beskrivningar. Jag har 4 MCP-servrar – det är ungefär 8–12K tokens i varje ny session innan jag har frågat något.

Det innebär att vi bara ansluter MCP om det faktiskt behövs i de flesta sessioner. Om du använder Sentry MCP en gång i veckan är det bättre att aktivera det vid behov med flaggan --mcp sentry än att behålla det i den permanenta listan.

När du inte ska använda MCP.

• Metodik för ”hur man arbetar med data” hör hemma i en skill, inte i MCP.
• En lång läsuppgift kan ha nytta av en subagent; om vissa filer eller poster är externa kan subagenten också behöva MCP-åtkomst.
• Publicering med ett enda kommando kräver en hook eller ett plugin, inte MCP.

Det främsta felmönstret. Att bygga en MCP-server för något som hanteras bättre av en skill. Jag såg ett exempel i en HN-diskussion (samma tråd med 422 poäng den 27 maj): författaren skrev en MCP-server som tillhandahåller ”instruktioner för kodgranskning”. Men det är inte åtkomst till omvärlden, det är en procedur. En skill gör samma sak med 10 gånger färre tokens.

En incident med resurskonflikt. En gång hängde min Playwright MCP med felet ”Browser is already in use” — jag hade ett Chrome-fönster öppet samtidigt och MCP kunde inte ta kontroll över webbläsaren. Det är en viktig lärdom: en MCP-server använder delade systemresurser. Om resursen används av flera (en webbläsare, port eller fil), tänk på isolering från början.

En färdig guide för att ansluta 7 fungerande MCP:er finns i Claude Code MCP-servrar 2026: 7 färdiga upplägg.

När behöver du ett plugin i stället för en skill eller subagent?#

Skills, subagenter och MCP handlar om din metodik. Ett plugin är någon annans färdiga metodik som du importerar till ditt upplägg.

I oktober 2025 lanserade Anthropic Claude Code Plugins, en officiell distributionsmekanism. Ett plugin är en katalog som kan innehålla:

• egna snedstreckskommandon
• egna skills
• egna subagenter
• egna hooks
• egna MCP-konfigurationer
• egna utmatningsstilar

Allt detta paketeras i ett enda paket med plugin.json. Installationen sker med en rad i ~/.claude/settings.json eller kommandot /plugin install <name>.

Min specifika plugin-uppsättning.

• frontend-design från den officiella claude-plugins-official — 67 stilar, 96 paletter, 57 typsnittspar och 13 ramverk. När jag skapar ett nytt block till webbplatsen eller en e-postmall laddar jag detta plugin och får hela biblioteket på en gång.
• playwright från samma officiella marknadsplats — en uppsättning skills plus MCP-konfigurationer för webbläsartestning.
• telegram — ett färdigt paket för att hantera ett Telegram-konto från Claude Code (policy, allowlist, ihopparning).
• trailofbits/skills — en uppsättning säkerhetsskills från Trail of Bits, ett företag jag litar på i säkerhetsfrågor.

Alla 4 upptar tre rader i settings.json. Utan plugins skulle jag lägga timmar på att bygga samma bibliotek för hand.

När du inte ska använda ett plugin.

• Om metodiken är helt din egen och inte ska användas av andra, behåll den som en skill.
• Om du inte vet vem som ska använda den än, prova den själv som en skill först.
• Om du snabbt behöver lägga tre filer på en ny dator räcker det med cp ~/.claude/skills/X /new/machine/.claude/skills/.

Det främsta felmönstret. Att använda ett plugin som ersättning för CLAUDE.md — till exempel ett plugin med regler om ”hur vi arbetar i det här projektet”. Ett plugin är gjort för distribution och återanvändning. Om reglerna gäller ett enda kodförråd hör de hemma i CLAUDE.md, inte i ett plugin.

Med blicken mot 2026: Anthropic rör sig tydligt mot en teammarknadsplats för plugins. Det innebär att företag kommer att kunna publicera sina interna metoder som plugins, versionshantera dem och uppdatera dem för alla anställda med ett enda kommando. För en soloföretagare betyder det: installera sådant som redan är färdigt och uppfinn inte hjulet på nytt.

Beslutsträd: 4 frågor att ställa före varje uppgift#

Fråga 1: finns en återkommande procedur som är värd att behålla?

Om ja paketerar du metodiken som en skill i en SKILL.md-fil med tydlig beskrivning av när den används. Den ger proceduren; den ger inte i sig extern åtkomst eller en separat kontext.

Fråga 2: bör arbetet ha separat kontext eller en fokuserad delegerad roll?

Om ja använder du en subagent. Ge den en precis uppgift och verktyg. Samma uppgift kan följa en skills metodik i den isolerade kontexten.

Fråga 3: behöver uppgiften ett verktyg eller tillgång till externa data?

Om ja ger du godkänd åtkomst genom MCP eller annat lämpligt verktyg, till exempel ett redan konfigurerat CLI. En skill beskriver hur åtkomsten används; en subagent kan vara aktören som använder den.

Fråga 4: ska konfigurationen distribueras och underhållas som ett paket?

Om ja använder du ett plugin för relevanta skills, agentdefinitioner, hooks eller MCP-konfiguration. Paketet kan vara ditt eget eller en annan författares.

Kombinerat exempel: återkommande granskning av GitHub-ärenden. En skill definierar granskningsprocedur och resultatform. Ett konfigurerat GitHub-MCP eller CLI ger godkänd ärendeåtkomst. En subagent kan läsa en lång ärendetråd i egen kontext och returnera fynd. Ett plugin kan distribuera kombinationen till teamet. Alla fyra svar kan vara ”ja”; inget upphäver något annat.

5 misstag när vibe-kodare väljer lager#

Jag ser de här 5 mönstren en gång i veckan bland vibe-kodarna jag arbetar med. Varannan gör minst ett av dem under sin första vecka.

Misstag 1: subagent i stället för skill.

Symptom: en författare skapade en subagent för ”att skriva ett nytt blogginlägg”. Varje gång författaren kör subagenten laddas den, läser 2 KB metodik, genererar ett inlägg och avslutas. Efter en vecka märker författaren att varje körning förbrukar ytterligare 5K tokens när subagenten laddas.

Vad som borde hända: ”hur man skriver ett inlägg” är en metod — det är en skill. Utlösaren är frasen ”nytt blogginlägg”. Skillen laddas i huvudchatten och öppnar ingen separat session. Den kostar 3–5 gånger mindre.

Misstag 2: MCP-server i stället för skill.

Symptom: en författare skrev en MCP-server som ger instruktioner om ”hur man gör en kodgranskning”. Verktygsdeklarationer, beskrivningar av argumentscheman och dokumentation fortsätter att ta upp kontext. Varje begäran slösar 2–3K tokens i onödan.

Vad som borde hända: ”hur man gör en kodgranskning” är en procedur, inte åtkomst till ett externt system. Använd en skill. MCP är motiverat endast om du behöver aktiv åtkomst — till exempel till Sentry för att hämta de senaste felen.

Misstag 3: plugin i stället för CLAUDE.md.

Symptom: en författare paketerade projektregler (”använd alltid strikt TypeScript-läge”, ”använd inga tankstreck”, ”använd endast pnpm, inte npm”) i ett plugin och installerade det. Nu laddas ett plugin varje ny session och duplicerar regler som borde finnas i CLAUDE.md.

Vad som borde hända: regler för ett projekt hör hemma i det projektets CLAUDE.md. Ett plugin är till för metodik som kan användas av flera personer eller i flera kodförråd.

Misstag 4: försöka skapa en skill med en hook.

Symptom: en författare märkte att en hook körs automatiskt vid en händelse (till exempel innan en fil sparas). Hen bestämde sig för att skapa en ”skill genom en hook” så att Claude automatiskt skulle använda metodiken vid varje redigering. Resultatet blev en ändlös utlösarloop, förbrukad kontext och oförutsägbart beteende.

Vad som borde hända: en hook är deterministisk kod som kör ett kommando, formaterar resultatet eller blockerar en åtgärd. En hook laddar inte en skill och anropar inte Claude. Om du behöver ”alltid tillämpa metodik X” ska du använda antingen en skill med en utlösare eller en post i CLAUDE.md.

Misstag 5: ett extra lager när inget behövs.

Symptom: en författare hör talas om skills, läser guider, bestämmer sig för att ”jag behöver paketera den här metodiken” och lägger en kväll på att skapa en skill för en uppgift som förekommer en gång i månaden.

Vad som borde hända: en engångsuppgift hör hemma direkt i chatten. En skill är motiverad endast om du gör detta mer än en gång om dagen. Annars är det överkonstruktion som sedan måste underhållas.

Kontrollera behoven oberoende i dessa exempel: procedur, kontext- eller rollisolering, verktygsåtkomst och distribution. Lägg till varje lager som har ett konkret syfte; kombinera dem när uppgiften behöver fler än ett.

Vad Anthropic säger om splittringen: vart Claude Code är på väg 2026#

Vad detta innebär under de kommande sex månaderna till ett år.

För det första: skills håller på att bli det främsta lagret för procedurbaserade uppgifter. Anthropic satsar tydligt på detta lager eftersom det är billigast och mest förutsägbart. Om du inte förstår varför du skulle behöva en skill 2026, bör du börja med att lära dig om den. Alla andra lager kommer att kretsa kring den.

För det andra: subagenter blir mer specialiserade. Huvudsyftet med subagenter är kontextisolering för tunga uppgifter. Generiska subagenter som qa-engineer kommer att försvinna; specifika som migration-test-writer och api-route-reviewer blir kvar.

För det tredje: Anthropics nya besked under 14 dagar — kommandot /workflows (28 maj 2026) för att samordna dussintals subagenter och uppdelningen av Agent SDK-faktureringen från och med den 15 juni — innebär att programmatisk användning flyttas till en separat kvot. Det är en signal om att Anthropic bygger infrastruktur för automatiserade system med 10+ agenter, snarare än individuella sessioner.

För en vibe-kodare 2026 innebär det en enkel sak: de fyra lagren finns kvar i minst sex månader till, sedan slås några av dem ihop. Men beslutsträdet med fyra frågor fungerar även efter sammanslagningen — det handlar om uppgiftens natur, inte lagrets specifika namn.

Färdig matris: 10 vanliga uppgifter → rätt lager#

Huvudregeln för hur tabellen ska användas är att inte försöka ”göra alla 10 på en gång”. De flesta solo-vibe-kodare klarar sig med CLAUDE.md + 5–7 skills + 2–4 MCP-servrar. Subagenter och plugins läggs till när projektet växer.

Nästa steg: så bygger du din arbetsmiljö i Claude Code#

De här fem lagren ligger inte efter varandra, utan passar in i varandra. CLAUDE.md är projektets grund och de andra fyra kopplas på när uppgifterna växer.

Lär känna Ailoot.