SKILLS
Skill är ett paket — tool är en körbar gräns
Sedan december 2025 finns ett öppet format, Agent Skills, som flera leverantörer av agentverktyg har anslutit sig till: en skill är där en mapp med filen SKILL.md (obligatoriskt namn och beskrivning, därefter instruktioner) och valfria mappar med skript, referensmaterial och mallar. Agenten läser bara namn och beskrivning tills skillen aktiveras. Utanför det formatet används ordet fortfarande i egen betydelse: instruktioner och resurser på en plattform, kod, ett workflow eller en verktygssamling på en annan. Beskriv därför alltid innehållet i stället för att lita på etiketten — ett skript i mappen är kod som körs, och en förgodkänd verktygslista i SKILL.md är en behörighet.
Ett tool är mer precist: en anropbar funktion med namn, beskrivning, indataschema, resultat, felbeteende och faktiska behörigheter.
Håll isär instruktion, kontext och handling
- Instruktion/prompt: beskriver arbetssättet.
- Resource eller RAG-källa: tillför kontext som dokument eller databasposter.
- Minne/tillstånd: sparar vad som hänt i eller mellan körningar.
- Tool/function: läser eller förändrar ett externt system.
- Workflow: binder ihop förutbestämda steg och felvägar.
- Skill-paket: kan kombinera flera av ovanstående — i Agent Skills-formatet instruktioner plus valfria skript och resurser, på andra plattformar enligt deras egen definition.
MCP:s serverprimitiver tools, resources och prompts hjälper till att hålla tre av dessa roller tydliga, men implementeringen måste fortfarande styra åtkomst och dataflöde.
Dela upp mötesförberedelsen i smala verktyg
En bred ”kalender-skill” med läsning, bokning, ändring och radering gör ett misstag onödigt dyrt. Dela hellre upp den:
- calendar.list_upcoming: läs en begränsad tidsperiod.
- notes.read_by_meeting_id: läs endast behöriga anteckningar.
- agenda.create_draft: skriv ett utkast i sandbox.
- calendar.update_event: separat skrivverktyg som alltid kräver godkännande.
Då kan de tre första användas i test utan att agenten får ändra kalendern.
Läs manifestet, inte marknadsnamnet
Oavsett om en tjänst säger connector, action, plugin, function, tool eller skill behöver du kontrollera samma saker: kodens ursprung, vilka data som skickas, exakta scopes, hemlighetshantering, nätverksåtkomst, loggning, uppdateringar, felbeteende och om verktyget kan ändra något.
En uppladdad fil är kontext. En sparad prompt är en instruktion. En appkoppling är en integration. De blir inte automatiskt en agent eller en säker skill.
Specificera varje tool innan modellen får se det
- Entydigt namn och beskrivning utan överlappande verktyg.
- Strikt indataschema, längdgränser och allowlist för värden.
- Strukturerad output med tydliga felkoder, inte fri text som döljer fel.
- Timeout, rate limit, maxstorlek och idempotens för muterande anrop.
- Separata läs- och skrivfunktioner samt minsta OAuth-scope eller tjänsteroll.
- Godkännandekrav som kodregel, inte bara som en mening i prompten.
- Loggning med redaktion av token, hemligheter och känsliga payloads.
Fler verktyg ger större attackyta
Varje verktyg ökar antalet möjliga fel, prompt-injection-vägar och dataflöden. Börja med en allowlist, läsrättighet och en testidentitet. Lägg till skrivning först när verktyget har egna valideringar, evals och ett fungerande godkännandesteg.
Ta bort verktyg som inte används. Rotera och avgränsa token. Ett verktyg ska neka en otillåten handling även om modellen uttryckligen ber om den.
Skribent, källkontroll och begränsning
Skribent och teknisk källgranskare: C. Leijon. Funktioner, protokoll och säkerhetsråd har kontrollerats mot länkade primärkällor .
Extern sakgranskning: Ingen extern systemarkitekt, AI-säkerhetsspecialist eller dataskyddsspecialist har granskat sidan. Materialet är ett praktiskt orienteringsstöd och ersätter inte säkerhetsgranskning, hotmodellering, juridisk bedömning eller organisationens förändringsprocess.
Nästa: Din första agent
Bygg ett minsta säkert agentsystem med tre konkreta exempel.