Agent-skills ontwerpen, verfijnen en onderhouden bij Perplexity

De frontier agent-producten van Perplexity rusten op een fundament van knowhow en domeinexpertise, verpakt in modulaire Agent Skills. Wij onderhouden een zorgvuldig samengestelde bibliotheek van Skills binnen onze technische omgevingen. Deze Skills bevatten vele algemene hulpprogramma's die Perplexity Computer aandrijven; verticale capaciteiten in gebieden zoals financiën, recht en gezondheid; en een zeer lange lijst van modules voor het adresseren van gebruikersbehoeften. Sommige Skills worden zelden aangeroepen, maar zijn kritiek wanneer ze worden aangeroepen. Om een consistent uitstekende gebruikerservaring te garanderen, geeft het Agents-team van Perplexity evenveel prioriteit aan Skill-kwaliteit als aan codekwaliteit.

De intuïties en best practices die vereist zijn om een hoogwaardige Skill te ontwikkelen, verschillen aanzienlijk van die voor het bouwen van traditionele software. Het Agents-team beoordeelt vele pull requests van uitstekende technici die tijdens hun werk Skills ontwikkelen. Het resultaat bestaat bijna altijd uit talloze opmerkingen en suggesties voor revisie. Dit komt doordat veel nuttige patronen voor het schrijven van code antipatronen worden bij het creëren van Skills.

Als u bijvoorbeeld enkele aforismen uit PEP20 – The Zen of Python neemt, wordt het al snel duidelijk dat het schrijven van goede Python-code anders is dan het schrijven van goede Skills. Van de 20 regels wijsheid zijn er minstens de helft volledig onjuist of actief misleidend bij het schrijven van Skills. Hier zijn er vijf van:

Vijf contrasten tussen de Zen van Python en de richtlijnen van het artikel voor het schrijven van Skills.

Deze gids is het document dat technici bij Perplexity gebruiken bij het ontwikkelen en beoordelen van Skills. We stellen deze gids ook beschikbaar aan het publiek, zodat onze ontdekkingen en leerervaringen de bredere gemeenschap ten goede kunnen komen. Of u nu een technicus bent die productie-Skills ontwerpt in uw dagelijkse werk, een Computer-gebruiker die uw eigen Skill wil ontwikkelen op een gebied dat u het beste kent, of beide, deze gids is voor u.

Wat is een Skill?

Wanneer u een Skill schrijft, schrijft u geen gewone oude software (ook al maken Skills nu deel uit van de belangrijkste logische engines voor agentsystemen). U bouwt veeleer context voor modellen en hun omgevingen. Een Skill heeft andere beperkingen en andere ontwerpprincipes. Als u een Skill schrijft zoals u code schrijft, zult u falen.

Een Skill is op zijn minst vier dingen, vooral in de context van hoe we ze bij Perplexity bouwen.

Een Skill is een map

Een Skill is niet slechts één SKILL.md-bestand. In veel gevallen bevat een Skill meerdere bestanden. Onder de map die naar uw Skill is vernoemd, heeft u mogelijk:

SKILL.md: frontmatter en instructies

scripts/: code die de agent uitvoert, niet opnieuw uitvindt

references/: uitgebreide documentatie, voorwaardelijk geladen

assets/: sjablonen, schema's en gegevens

config.json: gebruikersinstallatie bij eerste gebruik

Dit hub-and-spoke-patroon stelt u in staat om Skills zeer gefocust en strak te houden, en men kan de mappenstructuur op een zeer creatieve manier gebruiken. Soms profiteren bijzonder ingewikkelde Skills van meerdere niveaus van hiërarchie om het model te helpen beter te navigeren. Stel dat een Skill kennis vereist over 300 onderwerpen, onder te verdelen in 20 onderwerpengebieden. Het betrouwbaar kiezen van het juiste onderwerp uit 300 is zelfs voor de beste huidige frontier-modellen een onopgeloste uitdaging. Het is voor een model een veel gemakkelijker keuzeprobleem om zich te concentreren op een van de 20 gebieden dan tussen de 15 onderwerpen binnen dat gebied.

Als één voorbeeld van hoe hiërarchie op meerdere niveaus waarde biedt, heeft ons team drie niveaus van topische nesteling toegepast binnen de Skills die de Amerikaanse inkomstenbelastingcapaciteiten van Computer aandreven tijdens het afgelopen belastingseizoen. Deze hiërarchie was absoluut onmisbaar gezien de complexiteit van de belastingwetgeving: in onze vroege tests resulteerde het presenteren van een enkele map aan het model met daarin alle 1.945 secties van de U.S. Internal Revenue Code in slechtere prestaties dan het helemaal niet laden van de Skill. Het organiseren van de informatie in logische onderverdelingen was onmisbaar voor het garanderen van uiterst nauwkeurige leesoperaties.

Toch kwam deze hiërarchie niet gratis. Toenemende hiërarchische niveaus vereisen toenemende niveaus van curatie over de informatiearchitectuur om de resulterende indirectie te beheren. We hebben snelle naslaggidsen, aangepaste zoekhulpprogramma's en andere tools bedacht om het model te ondersteunen bij het vinden van informatie met een minimum aan indirectie. In dit geval leverde het harde werk van curatie uiteindelijk een positief eindresultaat op: een Skill waarmee modellen belastinggerelateerde taken veel bekwamer konden uitvoeren dan door alleen algemene tools te gebruiken.

Vergroten

Een Skill is een indeling

Een Skill is een indeling. Het kernbestand SKILL.md moet zowel een naam als een beschrijving hebben. Bovendien moet de Skill exact overeenkomen met de mapnaam waarin de Skill zich bevindt. De naam moet uit kleine letters bestaan, mag geen spaties bevatten en kan koppeltekens gebruiken. De beschrijving is de routeringstrigger. Dit is een veelvoorkomend faalpunt: de beschrijving is geen interne documentatie voor wat de Skill doet. Het komt neer op instructies voor het model over wanneer de Skill moet worden geladen. U zult dus vaak “Laden wanneer” zien, niet “Deze Skill doet”. Dit is belangrijk vanwege de manier waarop de meeste implementaties de beschrijving in de modelcontext injecteren.

Binnen de frontmatter staat ook “depends:”, waarmee u hiërarchische Skill-afhankelijkheden kunt creëren, en “metadata:”, die wordt gebruikt voor beoordelingen en evaluaties. Verschillende agentsystemen kunnen zelfs hun eigen frontmatter-velden definiëren, die op een voor die systemen specifieke manier kunnen worden gebruikt. Als alternatief kan Skill-specifieke metadata worden verpakt in een aanvullend JSON- of YAML-configuratiebestand. Dit is wenselijk bij het bouwen van agentsystemen die verschillende soorten runtime-gedrag per Skill moeten faciliteren zonder de context van het model te vervuilen met kleinigheden. Ten slotte is vergelijkbaar gedrag haalbaar door Skill-frontmatter bij het lezen te verwijderen. Computer gebruikt deze methodologie, waardoor configuratie in het rootbestand SKILL.md behouden kan blijven. Zorgvuldige aandacht voor detail is vereist in de parsing-logica, en men wil wellicht voorwaardelijke verwijdering implementeren als er bepaalde velden zijn die nuttig zijn om binnen de modelcontext te hebben.

Een Skill is aanroepbaar

Een Skill is aanroepbaar. De agent laadt een Skill tijdens runtime. Belangrijk is dat Skills niet altijd in de context worden gebundeld. Standaard vouwen de meeste agentsystemen Skills progressief uit op basis van specifieke behoeften.

Er zijn ten minste drie niveaus van contextkosten in de manier waarop we Skills in Computer hebben geïmplementeerd. Hier is het proces:

Computer roept load_skill(name="...") aan

Computer kopieert de Skill-map naar de geïsoleerde uitvoeringssandbox

Computer laadt recursief automatisch afhankelijkheden in de “depends:”-tag

Computer verwijdert vervolgens de frontmatter en de agent ziet dus alleen de hoofdtekst en de extra bestanden

Verschillende agentsystemen kunnen ervoor kiezen om Skill-inhoud op verschillende manieren bloot te stellen. Als voorbeeld zouden sommige systemen ervoor kunnen kiezen om de bestandsstructuur helemaal niet bloot te stellen, en het aan het model overlaten om de hiërarchie te ontdekken via bestandssysteemoperaties. Andere systemen kunnen ervoor kiezen om het model een kaart te geven van de gehele boomstructuur tot een bepaalde inkorting en/of dieptelimiet. Om de context schoon te houden, laat Computer volledige bestandsstructuren weg uit de aanroepcontext; dit is echter per Skill overschrijfbaar.

Een Skill is progressief

Skills zijn progressief. In Computer zijn er drie verschillende niveaus van contextkosten, en we krijgen te maken met alle drie in verschillende stadia:

De drie niveaus van Skill-context: index, volledige Skill-lading en runtime-referentiebestanden.

Computer bouwt een Skill-index met de naam en de beschrijving voor elke beschikbare Skill. Het budget hiervoor is ongeveer 100 tokens per Skill (korter is zelfs nog beter). Het is zo krap omdat u deze kosten in elke sessie betaalt, voor elke gebruiker. Dit wordt aan het begin van het gesprek in de systeemprompt geïnjecteerd. Het model heeft toegang tot een heleboel genoemde Skills en beschrijvingen, zodat het kan beslissen of het “load_skill()” moet aanroepen. De drempel om in deze index te komen is extreem hoog. Uw Skill moet erg nuttig zijn en de beschrijving moet extreem dicht en kort zijn, omdat iedereen de hele tijd de kosten betaalt.

Nadat het agentsysteem de Skill heeft geladen, is er de volledige SKILL.md-hoofdtekst. Idealiter overschrijdt de hoofdtekst niet de 5.000 tokens. Zelfs dan wilt u dat elke zin er toe doet, want zodra u een Skill laadt, moet de rest van het gesprek daarvoor betalen totdat u de compactiegrens bereikt. Veel threads laden tussen de drie en vijf verschillende Skills, wat deze kosten vermenigvuldigt. Skills met veel overtollige informatie zullen bijna zeker andere Skills en de algehele agent-capaciteiten verslechteren. Kortom, als uw Skill laadt en het doet niet het juiste, dan is dat verspilde context.

Het laatste niveau van progressie is scripts of speciale gevallen, zoals subskills of formattering. Dit is waar u ongebonden voorwaardelijke vertakte logica wilt plaatsen. De agent zal het alleen gebruiken wanneer dat nodig is, wat betekent dat er een veel lagere drempel is voor wat u hierin wilt plaatsen.

In de index is elk token belangrijk. De geladen Skill-hoofdtekst is meer ontspannen en de runtime is het meest ontspannen. Dit kunnen 20.000 tokens of nul tokens zijn. Dit is het niveau waarop u zou kunnen nadenken over het progressief uitbreiden van de context van het model.

Wanneer heeft u een Skill nodig?

Het Agents-team wordt vaak gevraagd om een oordeel te geven over de vraag of een Skill echt nodig is voor een bepaald domein of gebruiksscenario. Zelden hebben we een definitief antwoord op basis van louter eerste principes. De enige manier om hier echt achter te komen, is door met uw agent te beginnen zonder de Skill, een aantal hero-query's uit te voeren en vervolgens te achterhalen of de agent goed werk levert.

Wanneer u een Skill nodig heeft

Er zijn veel taken die in distributie zijn voor getrainde modellen. U hoeft alleen een Skill toe te passen als u dat gedrag op een specifieke manier wilt wijzigen die u niet kunt bereiken met bijvoorbeeld één zin in uw prompt. Dus, u heeft een Skill nodig wanneer de agent het fout zal doen zonder speciale context, of als er enige inconsistentie of niet-determinisme is die u extreem consistent moet houden over runs heen.

Het kan zijn dat uw kennis duurzaam is maar niet in de trainingsdata staat. Er kunnen cut-offs of bedrijfsspecifieke workflows zijn, of het kan een kwestie van smaak zijn. We hebben bijvoorbeeld verschillende ontwerpgerelateerde Skills in Computer die zijn geschreven door Henry Modisett (ons hoofd ontwerp). De reden dat elk token in die Skills bestaat, is omdat Henry een zeer goede smaak heeft als het gaat om het ontwerpen van websites en PDF's. Henry specificeert welke lettertypes hij moet gebruiken en welke lettertypes hij niet moet gebruiken, hoe die lettertypes aanvoelen en andere zaken van oordeel die het model niet alleen uit trainingsdata kan leren.

Wanneer u geen Skill nodig heeft

We zien veel Skills waarin technici een reeks git-opdrachten hebben geschreven die achter elkaar moeten worden uitgevoerd. Dat is onnodig omdat het model al weet hoe dat moet, wat betekent dat het zorgt voor geweldige documentatie maar een slechte Skill.

We zien voorbeelden waarbij Skills instructies uit de systeemprompt herhalen. Daar heeft u geen Skill voor nodig. Kennis die relevant is voor de meerderheid van de verzoeken, moet worden opgenomen in de globale context, niet in een voorwaardelijk geladen Skill.

Als er iets is dat sneller verandert dan u kunt onderhouden, heeft u geen Skill nodig. Als u bijvoorbeeld een extern MCP-eindpunt bereikt en de tools of de versies van die tools veranderen vaak, moet u die niet in een Skill injecteren. Als u dat doet, krijgt u alleen maar drift en zal het model fouten maken.

Elke Skill is een belasting

Hier is een nuttige test die u op elke zin in uw Skill kunt toepassen: “Zou de agent dit fout doen zonder deze instructie?” Als de zin er niet hoeft te zijn, kan deze het zich niet veroorloven er te zijn, omdat iedereen deze kosten elke keer betaalt. Wanneer u besluit of u een Skill wilt toevoegen of niet, onthoud dan deze belasting waarbij elke sessie en elke gebruiker tokens kost.

Het volgende beroemde citaat, dat veel beter klinkt in het Frans, vertaalt zich grofweg naar “Ik heb deze brief alleen langer gemaakt omdat ik niet de tijd had om hem korter te maken.”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Net als Pascal moet u tijd investeren in elke Skill. Het is moeilijk om een korte Skill te schrijven. Als uw Skill gemakkelijk te schrijven is, is deze waarschijnlijk te lang of zou deze niet moeten bestaan. Een goede Skill is zo kort als mogelijk.

Als u merkt dat u Skill-generatie in één keer probeert te doen en PR's in vijf minuten plaatst, zullen de resultaten bijna zeker ondermaats zijn. Sterker nog, vroeg onderzoek heeft aangetoond dat als u LLM's gebruikt om Skills te schrijven, het LLM er waarschijnlijk niet van zal profiteren: “Zelf gegenereerde Skills bieden gemiddeld geen voordeel, wat aantoont dat modellen de procedurele kennis waar ze van profiteren niet betrouwbaar kunnen schrijven.”

Hoe bouwt u een Skill

Met andere woorden, u moet uw mening injecteren in elke Skill die u schrijft. Volg deze stappen.

Stap 0: Schrijf de Evals

Schrijf eerst enkele evaluaties. U kunt evaluatiegevallen afkomstig maken uit:

Echte gebruikersquery's: steekproef uit productie of uw brain trust

Bekende fouten: De agent faalde omdat de Skill niet bestond

Buurverwarring: Dicht bij uw domeingrens maar routeert naar een andere Skill

Op zijn minst moet u ervoor zorgen dat u test of de Skill wordt geladen wanneer dat nodig is. Idealiter voert u een steekproef uit van enkele van deze, misschien uit een productieomgeving. U kunt ook bekende foutgevallen overwegen: misschien is de hele reden dat u besloot de Skill te schrijven vanwege een specifieke fout die u opmerkte, of misschien bent u aan het refactoren en is er enige verwarring in twee nabijgelegen domeinen die door één Skill worden gedekt.

Begin met vergelijkbare negatieve en positieve voorbeelden. Negatieve voorbeelden zijn extreem krachtig en kunnen belangrijker zijn dan positieve voorbeelden.

Stap 1: De beschrijving

Dit is de moeilijkste regel in de Skill. Het is een routeringstrigger, geen documentatie. Om de naam en de beschrijving goed te krijgen, geeft u niet om de inhoud van de Skill. U geeft alleen om of de Skill wordt geladen en geïnjecteerd op de juiste punten en vrij is van bijwerkingen buiten het doel, wat de nummer één faalmodus is. Elke keer dat u een extra Skill toevoegt, riskeert u elke andere Skill iets slechter te maken, dus u moet ervoor zorgen dat u regressie minimaliseert.

Nogmaals, een slechte beschrijving beschrijft wat de Skill doet of waarom deze nuttig is. Een goede beschrijving zegt wanneer de agent de Skill moet laden. Stel bijvoorbeeld dat u iets heeft voor het monitoren van pull requests. Schrijf niet wat de Skill doet. Schrijf wat technici zeggen wanneer ze gefrustreerd zijn en ze willen dat u ervoor zorgt dat hun PR werkt, zoals “oppassen” of “CI bekijken” of “zorg dat dit landt.”

Hier is een korte checklist:

Begint met "Laad wanneer..."

Richt op 50 woorden of minder

Beschrijft de bedoeling van de gebruiker, idealiter uit echte query's

Vat de workflow niet samen

Echte query's zijn wat u kunt dekken in een 80-20. Meestal werken twee of drie voorbeelden goed. Het is niet eenvoudig om precies en alleen toe te voegen wat u nodig heeft.

Stap 2: Schrijf de hoofdtekst

Schrijf vervolgens de inhoud van de Skill zelf. Merk op dat dit niet Stap 0 of Stap 1 is.

Het communiceren van workflows aan een LLM is totaal anders dan het communiceren van workflows aan een collega, of zelfs aan uw runtimesysteem. Bij het leren van een nieuwe softwaretool moet een technicus misschien de documentatie lezen, een walkthrough krijgen van iemand met ervaring en leren hoe de tool te gebruiken. Ondertussen hoeft u bij bijna elke softwaretool die al minstens een jaar bestaat, alleen de naam te vermelden en het LLM heeft alle informatie die het nodig heeft.

Wanneer u de hoofdtekst schrijft, sla dan de voor de hand liggende dingen over. Veel technici hebben genoeg ervaring met het schrijven van readme.md-bestanden die elke opdracht vermelden die iemand moet uitvoeren. Het is gemakkelijk om daarop terug te vallen wanneer u een Skill schrijft omdat het voelt alsof u documentatie aan het schrijven bent, maar als u dat doet, zal uw Skill rommel zijn. Schrijf dus geen reeks opdrachten uit.

U hoeft bijvoorbeeld niet te schrijven: “git log # vind de commit; git checkout main; git checkout -b <schone-branch>; git cherry-pick <commit>;”

Schrijf in plaats daarvan: “Cherry-pick de commit naar een schone branch. Los conflicten op met behoud van intentie. Als het niet netjes kan landen, leg dan uit waarom.”

Het model zal het met de laatste veel beter doen dan met de overdreven voorschrijvende reeks opdrachten van de eerste, vooral als er dingen misgaan. Wees niet rigide, of overdreven voorschrijvend, wat fragiel is, en wees in plaats daarvan flexibel waar meerdere benaderingen kunnen werken. Nogmaals, goede documentatie voor mensen is meestal slechte documentatie voor modellen.

Focus vervolgens op de addertjes onder het gras of negatieve voorbeelden. Dit is inhoud met een extreem hoog signaal omdat ze het model vaak begeleiden in termen van wat het niet moet doen. Als u elke keer dat de agent struikelt een regel toevoegt, zult u leren door het uit te voeren en zullen de addertjes organisch groeien.

Tot slot, als er een gedeelte is dat voorwaardelijk is of extreem zwaar qua inhoud, haal het dan uit de SKILL.md, wat de hub is, en zet het in een van de spokes. Zet het in een accessoire-bestand dat progressief kan worden geladen, waar we als volgende in duiken.

Stap 3: Gebruik de hiërarchie

Maak gebruik van de Skill-hiërarchie wanneer u een script heeft, referenties, of wanneer u een specifieke tool gebruikt:

Voorgestelde toepassingen voor scripts, referenties, assets en configuratie binnen een Skill.

Voor alles wat voorwaardelijk is of vertakt van de hoofd-Skill, breekt u het uit in een map. Onthoud ook dat hiërarchie op meerdere niveaus kan worden gebruikt voor bijzonder ingewikkelde Skills. Voor deze zult u zorgvuldig moeten nadenken over de vraag of de functionaliteit monolithisch moet worden geïmplementeerd of als een verzameling Skills (misschien met depends: gebaseerde laadrelaties).

Stap 4: Itereren

Doe vervolgens een aantal iteraties op een branch. Begin op de hoofd-branch zonder Skill, doe enkele iteraties, bouw uw hero-queryset en voer een hele reeks evaluaties uit. Iedereen die uw Skill-code beoordeelt, zal u dankbaar zijn voor het indienen van een enkele wijzigingenset compleet met een evaluatieset. Het beoordelen van opeenvolgende incrementele wijzigingen (behalve een nieuw addertje onder het gras) is erg moeilijk, dus probeer dit te minimaliseren.

U zult waarschijnlijk veel kleine woordwijzigingen doen. Kleine woordwijzigingen in beschrijvingen kunnen een buitenproportionele impact hebben op routering (inclusief overloopeffecten op andere Skills), dus doe al dat werk vóór Stap 5.

Stap 5: Verzenden

Verzend het.

Hoe onderhoudt u een Skill

Nu u een Skill heeft geschreven, moet u deze onderhouden.

Het vliegwiel voor addertjes

Vanaf dit punt neigt uw lijst met addertjes te groeien of veel te veranderen. We zien vaak technici die PR's doen die niet zijn geëvalueerd, bijvoorbeeld de beschrijving wijzigen. Als u de beschrijving wijzigt nadat uw Skill is samengevoegd, bent u van het pad af. Als u wijzigingen aanbrengt in het ding dat beslist of uw Skill moet worden gerouteerd, moet u enkele evaluaties schrijven die de wijzigingen ondersteunen.

Skills zijn grotendeels append-only. De sectie met addertjes krijgt in de loop van de tijd de meeste waarde:

Agent faalt bij iets → Voeg een addertje toe

Agent laadt de Skill buiten doel → Verscherp de beschrijving en voeg negatieve evaluaties toe

Agent laadt de Skill niet wanneer dat moet → Voeg trefwoorden en positieve evaluaties toe

Systeemprompt wijzigt → Controleer op strijd of duplicatie

Het is gemakkelijk om een enkel faalgeval op te merken bij interne tests of in productie en een addertje toe te voegen. Het is een negatief voorbeeld, dus het verandert niet echt de expliciete begeleiding, maar het laat het model weten: “Hé, er is deze bekende fout.”

Naarmate u beweegt van de 80-20 naar het bereiken van een succespercentage van 99,9% of 99,99%, is het gemakkelijk om deze lijst met addertjes te laten groeien. Naarmate u deze negatieve voorbeelden ziet, zou u grotendeels moeten toevoegen aan de sectie met addertjes. U zou geen langere instructies moeten toevoegen of de beschrijving moeten wijzigen.

Evaluatie-suites

Bij Perplexity voeren we veel evaluatie-suites uit om op verschillende dingen te controleren. Er zijn Skill-laden en Skill-bestandlezen, die de precisie, recall en verboden controles van het laden van de Skill zelf controleren. Zal de agent uw Skill routeren wanneer dat de bedoeling is? Deze zorgen ervoor dat nieuwe Skills geen bestaande grenzen doorbreken.

Er zijn ook evaluaties die kunnen controleren op goed progressief laden. De agent laadt de Skill misschien, maar leest hij ook het accessoire-bestand of bestanden? Bijvoorbeeld, als u een financiële Skill voor financiële query's heeft, leest hij dan het speciale FORMATTING.md-bestand?

Er zijn ook evaluaties voor Skills die testen op end-to-end taakvoltooiing binnen domeinen. We voeren de volledige agent-loop uit en gebruiken een LLM-rechter om de resultaten te beoordelen op basis van een rubriek van goed gedefinieerde criteria.

Ten slotte is het belangrijk om deze evaluaties uit te voeren tegen verschillende modellen. Computer ondersteunt ten minste drie verschillende orkestratiemodelfamilies: GPT, Claude Opus en Claude Sonnet. U wilt uw Skill-laden en de domein-Skills uitvoeren tegen deze verschillende agent-orkestratoren om ervoor te zorgen dat u geen ander gedrag krijgt. Sonnet en GPT gedragen zich heel anders als het om Skills gaat.

Laatste gedachten en takeaways

Hoe meer Skills u bouwt, hoe beter u erin wordt om ze te bouwen. Als u geen taken automatiseert of probeert reproduceerbaarder te maken die u dagelijks doet met behulp van Skills, begin dan onmiddellijk.

De handeling van het bouwen van Skills maakt u beter in het bouwen van meer Skills, maar ze zijn ook extreem goed in het automatiseren van bedrijfsprocessen. Als u iets kunt beschrijven dat u elke week doet voor uw standup, aan het einde van elke sprint, of iets dat u als technicus op dagelijkse, wekelijkse of zelfs kwartaalbasis doet, zou u een Skill moeten schrijven om uw tijd terug te winnen.

Kunt u postmortems automatiseren? Kunt u pull requests beoordelen? Elke taak die u kunt doen, kunt u op zijn minst als eerste pass een Agent Skill laten zijn. Het zal u aanzienlijk tijd besparen.

Dat gezegd hebbende, onthoud dat een Skill niet eenvoudig of zelfs altijd noodzakelijk is. Less is more. Enkele andere takeaways:

Schrijf evaluaties vóór de Skill. Voeg negatieve voorbeelden en verboden ladingen toe voor aangrenzende maar verschillende vaardigheden.

De beschrijving is het moeilijke deel. “Laad wanneer...” (elk woord kost aandacht).

Addertjes zijn extreem waardevolle inhoud. Begin dun, groei naarmate de agent faalt.

Onthoud dat het gemakkelijk is om andere reeds bestaande Skills te verbreken door een nieuwe Skill toe te voegen, ook al heeft u die niet aangeraakt (pas op voor actie op afstand).

Gebruik alle beschikbare tools elke keer dat u een Skill schrijft en onderhoudt. Als u meer wilt weten, heeft de Agent Skills-website veel goede voorbeelden, en zowel onze interne repository als het publieke ecosysteem bevatten veel voorbeelden van goed ontworpen Skills.

Citaat

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}