Návrh, vylepšování a údržba dovedností agenta v Perplexity

Produkty agenta Perplexity na špičce odvětví stojí na základech know-how a odborných znalostí v doméně, zabalených do modulárních Agent Skills. Udržujeme pečlivě kurátorovanou knihovnu Skills napříč našimi technickými prostředími. Tyto Skills zahrnují mnoho univerzálních nástrojů, které pohánějí Perplexity Computer; schopnosti specifické pro jednotlivé vertikály v oblastech, jako jsou finance, právo a zdravotnictví; a také velmi dlouhý „ocas“ modulů pro řešení potřeb uživatelů. Některé Skills se vyvolávají jen zřídka, ale jsou při vyvolání kritické. Aby tým Agentů společnosti Perplexity zajišťoval konzistentně vynikající uživatelský zážitek, klade na kvalitu Skills stejný důraz jako na kvalitu kódu.

Intuice a osvědčené postupy potřebné k vývoji vysoce kvalitní Skill se výrazně liší od těch, které jsou nutné pro tvorbu tradičního softwaru. Tým agentů kontem- tuje mnoho pull requestů od vynikajících inženýrů, kteří vyvíjejí Skill v průběhu své práce. Výsledkem jsou téměř vždy četné komentáře a návrhy na revizi. Je to proto, že mnoho užitečných vzorců pro psaní kódu se při vytváření Skill stává antipatterny.

Pokud si například vezmete některé aforismy z PEP20 – Zen Pythonu, rychle se ukáže, že psaní dobrého kódu v Pythonu se liší od psaní dobrých Skill. Z 20 řádků moudrosti je přinejmenším polovina zcela nesprávná nebo aktivně zavádějící, když píšete Skill. Zde je pět z nich:

Pět kontrastů mezi Zenem Pythonu a doporučeními článku pro psaní Skillů.

Tato příručka je dokument, který inženýři napříč Perplexity používají při vývoji a kontrole Skill. Tuto příručku také uvolňujeme veřejnosti, aby naše objevy a poznatky mohly prospět širší komunitě. Ať už jste inženýr navrhující produkční Skill při své každodenní práci, uživatel počítače, který chce vyvinout vlastní Skill v oblasti, kterou znáte nejlépe, nebo obojí, tato příručka je pro vás.

Co je to Skill?

Když píšete Skill, nepíšete obyčejný starý software (i když Skill jsou nyní součástí hlavních logických motorů pro systémy agentů). Spíše budujete kontext pro modely a jejich prostředí. Skill má jiná omezení a jiné zásady návrhu. Pokud píšete Skill stejně jako kód, selháte.

Skill je přinejmenším čtyřmi věcmi, zejména v kontextu toho, jak je stavíme v Perplexity.

Skill je adresář

Skill není jen jeden soubor SKILL.md. V mnoha případech Skill obsahuje několik souborů. V adresáři pojmenovaném po vašem Skill můžete mít:

SKILL.md: frontmatter a instrukce

scripts/: kód, který agent spouští, nikoli znovu vynalézá

references/: objemná dokumentace, načítaná podmíněně

assets/: šablony, schémata a data

config.json: úvodní nastavení uživatelem

Tento vzor typu hvězda-paprsky vám umožňuje udržovat Skill velmi soustředěné a úzké a strukturu složek lze používat velmi kreativním způsobem. Někdy zvláště složité Skill těží z více úrovní hierarchie, které modelu pomáhají lépe se orientovat. Předpokládejme, že Skill vyžaduje znalosti v 300 tématech, které lze seskupit do 20 oblastí zájmu. Spolehlivý výběr správného tématu mezi 300 je nevyřešenou výzvou i pro dnešní nejlepší špičkové modely. Pro model je mnohem snazší vybrat si jednu z 20 oblastí než vybírat z 15 témat v rámci dané oblasti.

Jako jeden příklad toho, jak multilevelová hierarchie přináší hodnotu, náš tým využil tři úrovně tematického vnoření v rámci Skill pohánějících schopnosti daně z příjmů v USA v Computeru během minulé daňové sezóny. Tato hierarchie byla naprosto nepostradatelná vzhledem ke složitosti daňového zákona: v našich počátečních testech vedlo předložení jediné složky obsahující všech 1 945 sekcí zákona o vnitřních příjmech USA modelu k horšímu výkonu než nenahrání Skill vůbec. Uspořádání informací do logických pododdílů bylo nepostradatelné pro zajištění vysoce přesných operací čtení.

Tato hierarchie však nebyla zadarmo. Rostoucí úrovně hierarchie vyžadují rostoucí úroveň správy napříč informační architekturou pro zvládnutí vzniklé nepřímosti. Vymysleli jsme rychlé referenční příručky, vlastní vyhledávací nástroje a další pomůcky, abychom model podpořili při vyhledávání informací s minimem nepřímosti. V tomto případě přineslo provedení náročné práce na správě nakonec pozitivní konečný výsledek: Skill, který modelům umožnil provádět úkoly související s daněmi mnohem schopněji než při použití pouze obecných nástrojů.

Zvětšit

Skill je formát

Skill je formát. Základní kořenový soubor SKILL.md musí mít jak název, tak popis. Skill se navíc musí přesně shodovat s názvem adresáře, ve kterém se nachází. Název se musí skládat výhradně z malých písmen, nesmí obsahovat žádné mezery a může používat pomlčky. Popis je spouštěčem směrování. Toto je časté místo selhání: popis není interní dokumentací toho, co Skill dělá. Rovná se instrukcím pro model, kdy má Skill načíst. Často tedy uvidíte „Načíst, když“, nikoli „Tento Skill dělá“. To je důležité kvůli způsobu, jakým většina implementací vkládá popis do kontextu modelu.

V rámci frontmatteru se nachází také „depends:“, který umožňuje vytvářet hierarchické závislosti Skill, a „metadata:“, jenž se používá pro recenze a hodnocení. Různé systémy agentů mohou dokonce definovat vlastní pole frontmatteru, která se použijí způsobem specifickým pro tyto systémy. Alternativně lze metadata specifická pro Skill zabalit do pomocného konfiguračního souboru JSON nebo YAML. To je žádoucí při vytváření systémů agentů, které potřebují usnadnit různé typy chování za běhu pro jednotlivé Skill, aniž by se kontext modelu zatěžoval detaily. Podobného chování lze dosáhnout také odstraněním frontmatteru Skill při čtení. Computer tuto metodiku využívá, což umožňuje uchovat konfiguraci v kořenovém souboru SKILL.md. V logice analýzy je vyžadována pečlivá pozornost k detailům a možná budete chtít implementovat podmíněné odstranění, pokud existují určitá pole, která je užitečné mít v kontextu modelu.

Skill je vyvolatelný

Skill je vyvolatelný. Agent načte Skill za běhu. Důležité je, že Skill nejsou vždy zabaleny v kontextu. Ve výchozím nastavení většina systémů agentů rozvíjí Skill postupně podle konkrétní potřeby.

Způsob, jakým jsme v Computeru implementovali Skill, zahrnuje nejméně tři úrovně nákladů na kontext. Zde je postup:

Computer zavolá load_skill(name="...")

Computer zkopíruje adresář Skill do izolovaného spouštěcího sandboxu

Computer rekurzivně automaticky načte závislosti v tagu „depends:“

Computer pak odstraní frontmatter a agent tak vidí pouze tělo a doplňkové soubory

Různé systémy agentů se mohou rozhodnout vystavit obsah Skill různými způsoby. Některé systémy se například mohou rozhodnout nevystavit hierarchii souborů vůbec a ponechat na modelu, aby hierarchii objevil prostřednictvím operací se souborovým systémem. Jiné systémy se mohou rozhodnout poskytnout modelu mapu celého stromu souborů až do určitého limitu zkrácení a/nebo hloubky. Aby byl kontext čistý, Computer vynechává úplné hierarchie souborů z kontextu vyvolání; to lze však potlačit pro každý Skill zvlášť.

Skill je progresivní

Skill jsou progresivní. V Computeru existují tři různé úrovně nákladů na kontext a v různých fázích vynakládáme všechny tři:

Tři úrovně kontextu Skillu: index, plné načtení Skillu a referenční soubory za běhu.

Computer vytvoří index Skill, který obsahuje název a popis pro každý dostupný Skill. Rozpočet na to je přibližně 100 tokenů na Skill (kratší je ještě lepší). Je to takto přísné, protože tuto cenu platíte v každé relaci za každého uživatele. To se vkládá do systémové výzvy hned na začátku konverzace. Model má přístup ke kupě pojmenovaných Skill a popisů, aby se mohl rozhodnout, zda zavolat „load_skill()“. Laťka pro vstup do tohoto indexu je extrémně vysoká. Vaše Skill musí být velmi užitečná a popis musí být extrémně hustý a stručný, protože tuto cenu platí každý neustále.

Poté, co systém agentů načte Skill, následuje úplné tělo SKILL.md. V ideálním případě text těla nepřesahuje 5 000 tokenů. I tak chcete, aby na každé větě záleželo, protože jakmile načtete Skill, zbytek konverzace za něj musí platit, dokud nenarazíte na hranici komprese. Mnohá vlákna načítají kdekoli mezi třemi a pěti různými Skill, což tyto náklady násobí. Skill s velkým množstvím zbytečného textu téměř jistě zhorší ostatní Skill a také celkové schopnosti agenta. Zkrátka a dobře, pokud se vaše Skill načte a neudělá to správné, je to promarněný kontext.

Poslední úrovní progrese jsou skripty nebo speciální případy, jako jsou podřízené dovednosti nebo formátování. Zde chcete umístit neomezenou podmíněnou rozvětvenou logiku. Agent ji použije pouze tehdy, když ji potřebuje, což znamená, že laťka pro to, co sem chcete umístit, je mnohem nižší.

V indexu je každý token důležitý. Načtené tělo Skill je uvolněnější a běhové prostředí je nejuvolněnější. Může jít o 20 000 tokenů nebo nulové tokeny. Toto je úroveň, na které byste mohli uvažovat o postupném rozšiřování kontextu modelu.

Kdy potřebujete Skill?

Tým agentů je často žádán, aby se vyjádřil k tomu, zda je Skill pro danou doménu nebo případ použití skutečně potřeba. Jen velmi vzácně máme jednoznačnou odpověď vycházející pouze z prvních principů. Jediný způsob, jak na to opravdu přijít, je začít s vaším agentem bez Skill, spustit několik hrdinských dotazů a pak zjistit, zda agent odvádí dobrou práci.

Když potřebujete Skill

Existuje mnoho úkolů, které jsou v distribuci pro trénované modely. Skill musíte aplikovat pouze tehdy, pokud chcete toto chování změnit nějakým specifickým způsobem, který nelze provést například jednou větou ve výzvě. Skill tedy potřebujete, když by to agent bez speciálního kontextu udělal špatně, nebo pokud existuje určitá nekonzistence či nedeterminističnost, u které potřebujete, aby byla napříč spuštěními extrémně konzistentní.

Může se stát, že vaše znalosti jsou trvalé, ale nejsou v trénovacích datech. Mohou existovat mezníky nebo pracovní postupy specifické pro podnik, případně může jít o záležitost vkusu. Máme například v Computeru několik návrhových Skill souvisejících s designem, které napsal Henry Modisett (náš šéfdesignér). Důvodem, proč v těchto Skill existuje každý token, je to, že Henry má velmi dobrý vkus, co se týče navrhování webových stránek a souborů PDF. Henry specifikuje, jaké fonty používat a jaké nepoužívat, jak tyto fonty působí a další záležitosti úsudku, které se model nemůže naučit pouze z trénovacích dat.

Když Skill nepotřebujete

Vidíme mnoho Skill, ve kterých inženýři napsali řadu příkazů git, které je třeba provést v pořadí. To není nutné, protože model už ví, jak to udělat, což znamená, že tvoří skvělou dokumentaci, ale špatnou Skill.

Vidíme příklady, kdy Skill rekapitulují instrukce ze systémové výzvy. K tomu Skill nepotřebujete. Znalosti relevantní pro většinu požadavků by měly být zahrnuty v globálním kontextu, nikoli v podmíněně načítaném Skill.

Pokud se něco mění rychleji, než to stíháte udržovat, Skill nepotřebujete. Pokud například přistupujete k nějakému vzdálenému koncovému bodu MCP a jeho nástroje nebo verze těchto nástrojů se často mění, neměli byste je vkládat do Skill. Pokud to uděláte, skončí to driftem a model bude dělat chyby.

Každá Skill představuje daň

Zde je užitečný test, který můžete aplikovat na každou větu ve svém Skill: „Udělal by to agent bez této instrukce špatně?“ Pokud tam věta nemusí být, nemůže si dovolit tam být, protože tuto cenu platí každý jedenkrát. Až se budete rozhodovat, zda přidat Skill, či nikoliv, vzpomeňte si na tuto daň, kdy každá relace a každý uživatel stojí tokeny.

Následující slavný citát, který zní ve francouzštině mnohem lépe, se zhruba překládá jako: „Napsal jsem tento delší dopis jen proto, že jsem neměl čas jej zkrátit.“

« 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

Stejně jako Pascal musíte věnovat čas každé Skill. Napsat krátký Skill je těžké. Pokud lze váš Skill napsat snadno, je pravděpodobně příliš dlouhý nebo by neměl existovat. Dobrá Skill je tak krátká, jak jen to jde.

Pokud zjistíte, že se snažíte o jednorázové generování Skill a vytváříte PR za pět minut, výsledky budou téměř jistě podprůměrné. Časný výzkum ve skutečnosti ukázal, že pokud používáte LLM k psaní Skill, LLM z toho pravděpodobně mít užitek nebude: „Vlastnoručně generované Skill neposkytují v průměru žádný přínos, což ukazuje, že modely nedokážou spolehlivě vytvořit procedurální znalosti, z jejichž konzumace těží.“

Jak vytvořit Skill

Jinými slovy, do každé Skill, kterou napíšete, musíte vnést svůj názor. Postupujte podle těchto kroků.

Krok 0: Napište vyhodnocení

Nejprve napište některá hodnocení. Případy pro vyhodnocení můžete čerpat z:

Skutečné dotazy uživatelů: vzorky z produkce nebo vašeho týmu odborníků

Známá selhání: Agent selhal, protože Skill neexistoval

Zmatek v okolí: Blízko hranice vaší domény, ale směřuje do jiné Skill

Přinejmenším byste se měli ujistit, že testujete, zda se Skill načte v případě potřeby. V ideálním případě některé z nich vzorkujete, možná z produkčního prostředí. Můžete také zvážit známé případy chyb: možná celý důvod, proč jste se pustili do psaní Skill, spočívá v konkrétním selhání, kterého jste si všimli, nebo možná provádíte refaktoring a v některých dvou blízkých doménách pokrytých jednou Skill panuje zmatek.

Začněte podobnými negativními a pozitivními příklady. Negativní příklady jsou extrémně silné a mohou mít větší význam než ty pozitivní.

Krok 1: Popis

Tento řádek je na Skill to nejtěžší. Jde o spouštěč směrování, nikoli o dokumentaci. Abyste měli název a popis správně, nezajímá vás obsah Skill. Záleží vám pouze na tom, zda se Skill načte a vloží na správných místech a zda neobsahuje nežádoucí vedlejší účinky, což je hlavní režim selhání. Pokaždé, když přidáte další Skill, riskujete, že každou další Skill mírně zhoršíte, takže se musíte ujistit, že minimalizujete regresi.

Opakujeme, že špatný popis popisuje, co Skill dělá nebo proč je užitečný. Dobrý popis říká, kdy má agent Skill načíst. Řekněme například, že máte něco pro sledování pull requestů. Nepište, co Skill dělá. Napište, co inženýři říkají, když jsou frustrovaní a chtějí, abyste zajistili, že jejich PR bude fungovat, například „ohlídat“, „sledovat CI“ nebo „zajistit, aby se to dostalo do produkce“.

Zde je rychlý kontrolní seznam:

Začíná „Načíst, když...“

Cíl 50 slov nebo méně

Popisuje záměr uživatele, ideálně ze skutečných dotazů

Nestrhuje pracovní postup

Skutečné dotazy jsou to, co můžete pokrýt pravidlem 80-20. Obvykle fungují dva nebo tři příklady. Není snadné přidat přesně a pouze tolik, kolik potřebujete.

Krok 2: Napište tělo

Dále napište samotný obsah Skill. Všimněte si, že toto není Krok 0 ani Krok 1.

Sdělování pracovních postupů LLM je zcela odlišné od sdělování pracovních postupů kolegovi nebo dokonce vašemu běhovému systému. Při uplatňování nového softwarového nástroje může inženýr potřebovat přečíst dokumentaci, získat průvodce od někoho se zkušenostmi a naučit se nástroj používat. Mezitím u téměř jakéhokoli softwarového nástroje, který existuje alespoň rok, stačí zmínit jeho název a LLM má všechny informace, které potřebuje.

Při psaní těla vynechte samozřejmé věci. Mnoho inženýrů má spoustu zkušeností s psaním souborů readme.md, které vypisují každý příkaz, který někdo potřebuje spustit. Je snadné do toho spadnout, když píšete Skill, protože máte pocit, že píšete dokumentaci, ale pokud to uděláte, bude váš Skill odpad. Takže nevypisujte řadu příkazů.

Například nemusíte psát: „git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Místo toho napište: „Cherry-pickněte commit do čisté větve. Vyřešte konflikty se zachováním záměru. Pokud se to nemůže čistě aplikovat, vysvětlete proč.“

Model odvede s tím druhým mnohem lepší práci než s příliš preskriptivní řadou příkazů toho prvního, zejména když se věci pokazí. Nepředkládejte direktivy ani buďte příliš preskriptivní, což je křehké, a místo toho buďte flexibilní tam, kde může fungovat více přístupů. Opakujeme, že dobrá dokumentace pro lidi je nejčastěji špatnou dokumentací pro modely.

Dále se zaměřte na úskalí nebo negativní příklady. Ty představují obsah s extrémně vysokým signálem, protože často vedou model v tom, co nedělat. Pokud přidáte řádek pokaždé, když agent zakopne, budete se učit jeho spouštěním a úskalí porostou organicky.

Nakonec, pokud existuje nějaká část, která je podmíněná nebo extrémně náročná na obsah, vyjměte ji ze souboru SKILL.md, který je centrem, a vložte ji do některého z paprsků. Vložte ji do pomocného souboru, který lze postupně načítat, a na ten se vrhneme vzápětí.

Krok 3: Využijte hierarchii

Využijte hierarchii Skill, když máte skript, reference nebo používáte nějaký specifický nástroj:

Doporučené použití skriptů, referencí, assetů a konfigurace v rámci Skillu.

Pro cokoli, co je podmíněné nebo se větví od hlavního Skill, to rozdělte do složky. Pamatujte také na to, že pro obzvláště složité Skill lze použít hierarchii na více úrovních. Pro tyto budete chtít pečlivě zvážit, zda by měla být funkčnost implementována monoliticky, nebo jako kolekce Skill (případně s načítacími vztahy založenými na depends:).

Krok 4: Iterujte

Dále proveďte řadu iterací na větvi. Začněte na hlavní větvi bez Skill, proveďte několik iterací, sestavte svou sadu hrdinských dotazů a spusťte řadu vyhodnocení. Každý, kdo kontroluje váš kód Skill, vám poděkuje za odeslání jediné sady změn kompletní se sadou pro vyhodnocení. Kontrola po sobě jdoucích přírůstkových změn (s výjimkou nového úskalí) je velmi obtížná, proto se ji snažte minimalizovat.

Pravděpodobně provedete mnoho malých změn slov. Malé změny slov v popisech mohou mít nadměrný dopad na směrování (včetně přelévacích účinků na ostatní Skill), takže proveďte celou tuto práci před Krokem 5.

Krok 5: Odeslat

Odešlete to.

Jak udržovat Skill

Nyní, když jste napsali Skill, musíte ji udržovat.

Setrvačník úskalí

Od této chvíle má váš seznam úskalí tendenci hodně růst nebo se měnit. Často vídáme inženýry, kteří vytvářejí PR, která nebyla vyhodnocena, například mění popis. Pokud měníte popis poté, co byl váš Skill sloučen, jste na špatné cestě. Pokud provádíte změny v tom, co rozhoduje o směrování vašeho Skill, musíte napsat nějaká vyhodnocení, která tyto změny podporují.

Skill jsou převážně rozšiřitelné přidáváním. Sekce úskalí nabírá časem nejvyšší hodnotu:

Agent selže v něčem → Přidat úskalí

Agent načte Skill mimo cíl → Zpřesnit popis a přidat negativní vyhodnocení

Agent nenačte Skill, když by měl → Přidat klíčová slova a pozitivní vyhodnocení

Změny systémové výzvy → Zkontrolovat spor nebo duplikaci

Je snadné zaznamenat jediný případ selhání při interním testování nebo v produkci a přidat úskalí. Jde o negativní příklad, takže nemění explicitní pokyny, ale dává modelu vědět: „Hele, je tady tohle známé selhání.“

Jakmile přecházíte od poměru 80-20 k dosažení 99,9% nebo 99,99% úspěšnosti, je snadné tento seznam úskalí rozšiřovat. Jakmile tyto negativní příklady uvidíte, měli byste je do sekce úskalí převážně připojovat. Neměli byste přidávat delší instrukce ani měnit popis.

Sady vyhodnocení

V Perplexity spouštíme mnoho evaluačních sad ke kontrole různých věcí. Existuje načítání Skill a čtení souborů Skill, což kontroluje přesnost, úplnost a zakázané kontroly samotného načítání Skill. Bude agent směrovat vaši Skill, když má? Tyto testy zajišťují, že nové Skill neporušují stávající hranice.

Existují také vyhodnocení, která mohou kontrolovat správné postupného načítání. Agent může Skill načíst, ale přečte si doplňkový soubor nebo soubory? Pokud máte například finanční Skill pro finanční dotazy, přečte si speciální soubor FORMATTING.md?

Existují také vyhodnocení pro Skill, která testují kompletní dokončení úkolů v rámci domén. Spouštíme úplnou smyčku agenta a používáme posuzovatele LLM k ohodnocení výsledků na základě rubriky dobře definovaných kritérií.

Nakonec je důležité tato vyhodnocení spustit proti různým modelům. Computer podporuje nejméně tři různé rodiny orchestračních modelů: GPT, Claude Opus a Claude Sonnet. Chcete spustit své načítání Skill a doménové Skill proti těmto různým orchestrátorům agentů, abyste zajistili, že nezískáte odlišné chování. Sonnet a GPT se při práci se Skill chovají docela odlišně.

Závěrečné myšlenky a poznatky

Čím více Skill vytvoříte, tím lepší v jejich budování budete. Pokud neautomatizujete nebo se nesnažíte zefektivnit úkoly, které děláte den co den, pomocí Skill, začněte okamžitě.

Samotný čin budování Skill vás činí lepšími v budování dalších Skill, ale také jsou extrémně dobré v automatizaci podnikových procesů. Pokud dokážete popsat něco, co děláte každý týden před poradou, na konci každého sprintu, nebo cokoli, co děláte jako inženýr denně, týdně nebo dokonce čtvrtletně, měli byste psát Skill, abyste získali zpět svůj čas.

Můžete automatizovat postmortemy? Můžete kontrolovat pull requesty? U každého úkolu, který dokážete udělat, můžete nechat první průchod provést jako Agent Skill. Ušetří vám to výrazně času.

I přesto pamatujte, že Skill není jednoduchý ani vždy nutný. Méně je více. Několik dalších poznatků:

Napište vyhodnocení před Skill. Zahrňte negativní příklady a zakázaná načtení pro přilehlé, ale odlišné Skill.

Popis je ta obtížná část. „Načíst, když...“ (každé slovo stojí pozornost).

Úskalí představují obsah s extrémně vysokou hodnotou. Začněte úsporně, rozšiřujte podle toho, jak agent selhává.

Pamatujte, že je snadné rozbít jiné již existující Skill přidáním nového Skill, přestože jste se ho nedotkli (mějte se na pozoru před akcí na dálku).

Používejte všechny dostupné nástroje pokaždé, když píšete a udržujete Skill. Pokud se chcete dozvědět více, web Agent Skills obsahuje spoustu dobrých příkladů a jak náš interní repozitář, tak veřejný ekosystém obsahují mnoho příkladů dobře navržených Skill.

Citace

@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://perplexity.coolkeypoint.com/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}