Claude Code-plugins: Vad de är och hur de används

Ett Claude Code-plugin är en mapp som levererar mer än en typ av tillägg samtidigt. Där en färdighet är en enda SKILL.md-fil som lär Claude ett beteende, kan ett plugin samla färdigheter, underagenter, krokar, snabbkommandon och till och med en MCP-server, och installera allt med ett enda kommando. Det är skillnaden mellan att ge någon ett receptkort och att ge dem ett utrustat kök.

Anthropic lade till plugins till Claude Code i slutet av 2025, och de löste ett verkligt problem: team installerade inte en färdighet i taget, de satte ihop konfigurationer. En "backend engineer"-konfiguration kan behöva en felsökningsfärdighet, en kodgranskningsunderagent, en pre-commit-krok och en databas-MCP-anslutning. Före plugins innebar det fyra separata installationer och fyra platser där konfigurationen kunde hamna ur synk. Ett plugin gör det till ett.

Vi testar och katalogiserar Claude-färdigheter på SkillProof, och plugins är nästa nivå upp från vad vi vanligtvis granskar: ett paketeringsformat, inte ett beteende. Den här guiden täcker vad som faktiskt finns inuti ett plugin, hur marknadsplatsystemet fungerar, och samma förtroendefråga som vi har ställt om färdigheter sedan vi började, nu tillämpad på något med mycket större yta.

Vad plugins faktiskt paketerar

Fyra ingredienser kan finnas inuti ett enda plugin, och de flesta verkliga plugins använder mer än en:

• Färdigheter — markdown-instruktioner som laddas när en uppgift matchar, samma format som täcks i vad Claude-färdigheter är.
• Underagenter — separata Claude-instanser med sin egen systemprompt och kontextfönster, användbara för att delegera en bullrig eller parallell uppgift.
• Krokar — shell-kommandon som körs automatiskt vid händelser som en filsparning, en commit eller när ett verktygsanrop avslutas. En lint-vid-sparande-krok är det klassiska exemplet.
• Snabbkommandon — anpassade kommandon som /deploy eller /standup som kör en fördefinierad prompt eller ett skript när en lagkamrat skriver dem.
• MCP-servrar — en anslutning till ett externt verktyg eller datakälla, konfigurerad en gång inuti pluginet istället för manuellt i varje projekt.

Ett plugin behöver inte alla fem. Många levererar bara ett par färdigheter, eller en enda krok plus kommandot som utlöser den. Vad som gör det till ett plugin snarare än en lös samling filer är att det installeras som en enhet, med ett manifest som beskriver vad som finns inuti.

Plugins vs färdigheter: npm-paketanalogin

Det renaste sättet att tänka på detta: en färdighet är en funktion, ett plugin är ett paket.

En enskild färdighet lär Claude ett beteende, oavsett om det är att formatera mötesanteckningar eller granska en SEO-sida. Den har inga beroenden och ingen konfiguration utöver sin egen markdown. Det är avsiktligt: en färdighet skriven för att täcka flera orelaterade uppgifter tenderar att utlösas opålitligt på alla dem, eftersom dess beskrivning inte kan vara specifik för någon enskild.

Ett plugin är distributionsenheten runt det beteendet. I npm-världen skickas inte en funktion ensam; den skickas inuti ett paket med en package.json, ett versionsnummer och kanske ett par andra funktioner som hör ihop. Ett plugin spelar samma roll för Claude Code: det är saken med ett namn, en version, en författare och ett manifest, och färdigheterna, krokarna och kommandona inuti det är exporten.

Denna distinktion är viktig av praktiska skäl. När något går sönder är "färdighetens trigger är för vag" och "pluginets krok kör fel shell-kommando" olika buggar med olika lösningar. Att skylla hela pluginet för en dålig färdighet inuti, eller vice versa, slösar tid. Läs manifestet först för att se vad som faktiskt levererades innan du diagnostiserar något.

Det innebär också att de två enheterna utvärderas olika. En färdighet lever eller dör på triggerkvalitet och om dess utdata överträffar Claudes standard. Ett plugin lever eller dör på om dess delar samarbetar: utlöses kroken före eller efter att färdigheten behöver dess utdata, anropar kommandot en MCP-server som faktiskt är konfigurerad, krockar installationen med något du redan har.

Pluginets anatomi

Varje plugin behöver en .claude-plugin-mapp i roten som innehåller plugin.json, manifestet. Allt annat (skills/, agents/, hooks/, commands/, .mcp.json) ligger bredvid som vanliga mappar som Claude Code känner igen enligt konvention.

Här är ett litet men komplett plugin, kommenterat:

team-standards/
├── .claude-plugin/
│   └── plugin.json
├── skills/
│   └── code-review/
│       └── SKILL.md
├── hooks/
│   └── hooks.json
└── commands/
    └── deploy.md

// .claude-plugin/plugin.json
{
  "name": "team-standards",
  "version": "1.2.0",
  "description": "Vår lint-krok, granskningsfärdighet och deploy-kommando i en installation.",
  "author": "platform-team"
}

Manifestet är medvetet tunt. Det identifierar pluginet och dess version; det listar inte varje fil inuti, eftersom Claude Code automatiskt upptäcker skills/, hooks/ och commands/ baserat på deras mappnamn.

// hooks/hooks.json
{
  "PreToolUse": [
    {
      "matcher": "Bash",
      "hooks": [{ "type": "command", "command": "./scripts/check-branch.sh" }]
    }
  ]
}

Denna krok körs före anrop till Bash-verktyg och kan blockera det, vilket är hur ett plugin kan tvinga fram något som "kör aldrig destruktiva git-kommandon på main" utan att förlita sig på att Claude kommer ihåg att kontrollera.

<!-- commands/deploy.md -->
---
description: Kör vår deploy-checklista mot staging
---

Verifiera att grenen inte är main, bekräfta att migreringar har tillämpats,
kör sedan `./deploy.sh staging`. Rapportera deploy-loggens sammanfattning.

Att skriva /deploy kör exakt detta, varje gång, formulerat identiskt för varje lagkamrat som installerar pluginet. Den konsekvensen är hela argumentet: tre komponenter, ett versionsnummer, en installationskommando, och ingen lokal konfiguration som driver isär från någon annans.

En separat fil, marketplace.json, är inte en del av själva pluginet. Det är indexet som ett marknadsplatsförråd publicerar så att Claude Code vet vilka plugins som finns där och var de ska hämtas ifrån. Ett förråds marketplace.json kan lista dussintals orelaterade plugins; tänk på det som registret, med plugin.json som det enskilda paketet inuti.

Installation från marknadsplatser

Att få ett plugin till din maskin är två kommandon. Först, peka Claude Code mot en marknadsplats:

/plugin marketplace add anthropic/plugins

Detta läser förrådets marketplace.json och lägger till alla plugins det listar till vad du kan bläddra bland. Installera sedan ett:

/plugin install code-standards@anthropic

Delen @anthropic anger vilken marknadsplats som ska hämtas från, eftersom du kan ha flera tillagda samtidigt och samma pluginnamn teoretiskt sett kan finnas i mer än en. Claude Code hämtar pluginets filer, registrerar dess färdigheter och kommandon, och kopplar ihop eventuella krokar eller MCP-servrar som det deklarerar.

Här är delen som borde låta bekant om du har läst något annat vi har skrivit: ingen granskar dessa. Att lägga till en marknadsplats innebär att lita på den som underhåller det förrådet, och att installera ett plugin från det innebär att lita på varje fil som pluginet medför, inklusive krokar som kör shell-kommandon och MCP-servrar som får nätverksåtkomst. Detta är exakt samma förtroendeproblem vi har dokumenterat för färdigheter, fast ett plugin har fler rörliga delar, vilket innebär fler platser för något dåligt att gömma sig. En färdighet kan bara vara övertygande text laddad i kontext. Ett plugin kan också vara en krok som körs vid varje commit oavsett om du tittar eller inte.

Vår säkerhetschecklista för färdigheter gäller här med ett tillägg. Innan du installerar ett plugin:

1. Läs manifestet och varje fil det refererar till innan du kör installationskommandot, inte efter. Ett plugin.json som påstår sig vara en "deploy-hjälpare" som också deklarerar en MCP-server som pekar på en okänd domän är en signal värd att stanna upp vid.
2. Lås versionen. Installera code-standards@1.2.0, inte vad latest löser sig till nästa tisdag. Ett plugin som ändrar sitt krokbeteende efter att du redan har litat på det är värre än ett som var dåligt från dag ett, eftersom du inte kommer att leta.
3. Kontrollera specifikt vilka krokar och kommandon som levereras. Krokar körs automatiskt, utan att du skriver något, vid händelser som verktygsanrop och filsparande. Det är den komponent som är mest värd att läsa i sin helhet, eftersom det är den som agerar utan en prompt från dig i stunden.
4. Behandla en MCP-server som är paketerad i ett plugin som vilken annan MCP-server som helst: den får verklig nätverksåtkomst och ofta verkliga autentiseringsuppgifter. Att paketeras inuti ett plugin gör det inte säkrare, det gör det bara enklare att installera utan att märka att det finns där.

Vi täcker hela hotmodellen, inklusive vad en illvillig krok eller färdighet faktiskt ser ut som i praktiken, i vår säkerhetsguide för färdigheter. Allt där om att behandla tredjepartsinstruktioner som ett beroende du inte har granskat gäller för plugins, bara med en större sprängradie.

När du ska paketera ditt teams konfiguration som ett plugin

Den tydligaste signalen att du är redo för ett plugin: du har skrivit samma konfigurationsinstruktioner i en README, en Slack-pin och ett onboarding-dokument, och de är redan ur synk på två av de tre platserna.

Ta ett konkret fall. Ett plattformsteam vill att varje ingenjörs Claude Code-session ska upprätthålla samma standarder: inga direkta commits till main, en konsekvent kodgranskningsrunda före merge, och en enkel deploy till staging. Paketerat separat är det en krok som någon måste komma ihåg att lägga till i settings.json, en färdighet som någon måste komma ihåg att installera, och ett kommando som någon måste komma ihåg existerar. Paketerat som ett team-standards-plugin är det en rad:

/plugin install team-standards@our-org

och varje nyanställd får branch-skyddskroken, kodgranskningschecklista-färdigheten och /deploy-kommandot i ett steg, versionshanterat tillsammans så att en uppdatering av deploy-skriptet och en uppdatering av granskningskriterierna levereras i samma release istället för att driva isär.

Det omvända signalen är också viktig: om din konfiguration är en enda färdighet utan krokar, kommandon eller MCP-beroende, lägger paketeringen som ett plugin till ett manifest och en marknadsplatslistning utan någon fördel. Publicera den som en färdighet på egen hand, som vi täcker i vad Claude-färdigheter är, och sträck dig efter ett plugin först när det finns mer än en rörlig del att hålla i synk. Om MCP-servern är den komplicerade delen av din konfiguration, finns våra anteckningar om att bygga en i MCP Builder, vilket är värt en titt innan du bestämmer om ett plugin behöver sin egen server alls jämfört med att peka på en som redan finns.

Vår egen 30-minuters Claude Code-installationsguide går igenom att bygga detta lager för lager för en individ; ett team-plugin är samma lagerövning, bara versionshanterat och delat istället för att monteras manuellt på varje laptop.

Ekosystemet 2026, ärligt talat

Plugins är unga, och det syns. Marknadsplatsformatet stabiliserades bara för några månader sedan, vilket innebär att de flesta marketplace.json-filer i vildmarken skrevs mot ett tidigt utkast av specifikationen och inte har rörts sedan dess. Dokumentationskvaliteten varierar enormt: vissa plugin-förråd har en tydlig README med en versionshistorik, andra är en enda commit utan förklaring av vad den paketerade kroken faktiskt gör.

Fragmentering är det större problemet. Eftersom ett plugin kan deklarera sina egna färdigheter istället för att referera till de du redan har installerat, återuppfinns samma beteende över ett dussin olika plugins med ett dussin olika kvalitetsnivåer. Vi har sett en kodgranskningsfärdighet paketerad inuti tre orelaterade plugins, ingen medveten om att de andra existerar, var och en skriven enligt en annan standard.

Detta ger samma kvalitetslotteri som vi dokumenterade över community-färdigheter generellt: ungefär hälften av det vi testar misslyckas vid första försöket, oavsett om det är från ett installationsskript som antar en katalogstruktur som författaren aldrig verifierade på en ren maskin, eller en krok som tyst gör ingenting eftersom den skrevs mot en tidigare version av krok-API:et. Ett plugin löser inte den felprocenten. Det paketerar bara fler komponenter som var och en kan misslyckas oberoende, och ett plugin fungerar bara om varje del inuti det gör det.

Inget av detta betyder att du ska hoppa över plugins. Det betyder att du ska tillämpa samma skepticism som du skulle tillämpa på vilket beroende som helst: kontrollera vem som underhåller det, kontrollera när det senast uppdaterades, och installera inte något med tre komponenter när du bara behöver en av dem. Paketeringsformatet är genuint användbart för att hålla ett team synkroniserat. Det är inte en ersättning för att läsa vad du installerar.

FAQ

Vad är skillnaden mellan ett Claude Code-plugin och en färdighet?

En färdighet är ett beteende i en markdown-fil. Ett plugin är en distributionsenhet som kan paketera flera färdigheter tillsammans med underagenter, krokar, snabbkommandon och en MCP-server, allt installerat tillsammans med ett kommando och ett versionsnummer. Varje plugins färdigheter är fortfarande färdigheter under ytan; pluginet är bara paketeringen runt dem.

Hur installerar jag ett Claude Code-plugin?

Lägg till marknadsplatsen först med /plugin marketplace add <repo>, installera sedan ett specifikt plugin från den med /plugin install <plugin-name>@<marketplace>. Lås en version istället för att installera vad marknadsplatsen för närvarande pekar på som senaste, så att en uppdatering inte tyst ändrar beteende du redan har granskat.

Är Claude Code-plugins säkra att installera?

Behandla dem som du skulle behandla vilket tredjepartsberoende som helst, och mer försiktigt än en vanlig färdighet, eftersom ett plugin också kan leverera krokar som kör shell-kommandon automatiskt och MCP-servrar med verklig nätverksåtkomst. Läs manifestet och varje paketerad fil innan installation, inte efter. Vår säkerhetsguide för färdigheter täcker den underliggande hotmodellen i detalj.

Kan jag lägga min egen MCP-server inuti ett plugin?

Ja. Ett plugin kan deklarera en .mcp.json som konfigurerar en MCP-server som en del av installationen, så att lagkamrater får anslutningen upprättad automatiskt istället för att konfigurera den manuellt i varje projekt. Om du bygger själva servern snarare än att bara koppla ihop en, se MCP Builder för byggsidan av det.

Var hittar jag Claude Code-plugins att installera?

Anthropic underhåller en officiell marknadsplats, och community-marknadsplatser har vuxit snabbt sedan formatet lanserades. Kvaliteten varierar lika mycket som den gör över community-färdigheter generellt, så kontrollera manifestet, kontrollera när det senast uppdaterades, och föredra plugins från underhållare som dokumenterar vad som faktiskt finns inuti innan du lägger till deras marknadsplats.