Diseñar, refinar y mantener habilidades de agente en Perplexity

Los productos de agentes de frontera de Perplexity se basan en un fundamento de conocimientos y experiencia técnica integrados en Habilidades de Agente modulares. Mantenemos una biblioteca cuidadosamente seleccionada de Habilidades en nuestros entornos técnicos. Estas Habilidades incluyen muchas de las utilidades de propósito general que potencian Perplexity Computer; capacidades específicas verticales en áreas como finanzas, derecho y salud; y una lista muy extensa de módulos para abordar las necesidades de los usuarios. Algunas Habilidades se invocan con poca frecuencia, pero son críticas cuando se invocan. Para garantizar una experiencia de usuario consistentemente excelente, el equipo de Agentes de Perplexity prioriza la calidad de las Habilidades tanto como la calidad del código.

Las intuiciones y las mejores prácticas necesarias para desarrollar una Habilidad de alta calidad difieren significativamente de las requeridas para crear software tradicional. El equipo de Agentes revisa muchas solicitudes de incorporación de cambios de excelentes ingenieros que desarrollan Habilidades en el curso de su trabajo. El resultado es casi siempre numerosos comentarios y sugerencias de revisión. Esto se debe a que muchos patrones útiles para escribir código se convierten en antipatrones en la creación de Habilidades.

Por ejemplo, si toma algunos de los aforismos de PEP20 – El Zen de Python, queda claro rápidamente que escribir buen código Python no es igual a escribir buenas Habilidades. De las 20 líneas de sabiduría, al menos la mitad son completamente incorrectas o activamente engañosas al escribir Habilidades. Aquí hay cinco de ellas:

Cinco contrastes entre el Zen de Python y la guía del artículo para escribir Skills.

Esta guía es el documento que los ingenieros de todo Perplexity utilizan al desarrollar y revisar Habilidades. También estamos publicando esta guía para que nuestros descubrimientos y aprendizajes puedan beneficiar a la comunidad en general. Tanto si es un ingeniero que diseña Habilidades de producción en su trabajo diario, un usuario de Computer que busca desarrollar su propia Habilidad en un área que conoce mejor, o ambos, esta guía es para usted.

¿Qué es una Habilidad?

Cuando escribe una Habilidad, no está escribiendo software convencional (aunque las Habilidades ahora forman parte de los motores lógicos principales para los sistemas de agentes). Más bien, está creando contexto para los modelos y sus entornos. Una Habilidad tiene restricciones diferentes y principios de diseño diferentes. Si escribe una Habilidad como escribe código, fracasará.

Una Habilidad es al menos cuatro cosas, especialmente en el contexto de cómo las construimos en Perplexity.

Una Habilidad es un Directorio

Una Habilidad no es solo un archivo SKILL.md. En muchos casos, una Habilidad incluye varios archivos. Bajo el directorio nombrado como su Habilidad, podría tener:

SKILL.md: frontmatter e instrucciones

scripts/: código que el agente ejecuta, no reinventa

references/: documentos pesados, cargados condicionalmente

assets/: plantillas, esquemas y datos

config.json: configuración de usuario para la primera ejecución

Este patrón de centro y radios le permite mantener las Habilidades muy enfocadas y compactas, y se puede utilizar la estructura de carpetas de una manera muy creativa. A veces, las Habilidades particularmente intrincadas se benefician de múltiples niveles de jerarquía para ayudar al modelo a navegar mejor. Suponga que una Habilidad requiere conocimiento sobre 300 temas, agrupables en 20 áreas temáticas. Elegir de manera confiable el tema correcto entre 300 es un desafío sin resolver incluso para los mejores modelos de frontera de la actualidad. Es un problema de elección mucho más fácil para un modelo centrarse en una de las 20 áreas, que entre los 15 temas dentro de esa área.

Como ejemplo de cómo la jerarquía multinivel proporciona valor, nuestro equipo empleó tres niveles de anidamiento temático dentro de las Habilidades que impulsan las capacidades de impuestos sobre la renta de EE. UU. de Computer la temporada fiscal pasada. Esta jerarquía fue absolutamente indispensable dada la complejidad de la ley fiscal: en nuestras pruebas iniciales, presentar al modelo una sola carpeta que contuviera las 1,945 secciones del Código de Rentas Internas de EE. UU. resultó en un rendimiento peor que no cargar la Habilidad en absoluto. Organizar la información en subdivisiones lógicas fue indispensable para garantizar operaciones de lectura de alta precisión.

Sin embargo, esta jerarquía no fue gratuita. Los niveles crecientes de jerarquía requieren niveles crecientes de curación en toda la arquitectura de la información para gestionar la indirección resultante. Ideamos guías de referencia rápida, utilidades de búsqueda personalizadas y otras herramientas para apoyar al modelo en la localización de información con un mínimo de indirección. En este caso, realizar el arduo trabajo de curación finalmente produjo un resultado final positivo: una Habilidad que permitió a los modelos realizar tareas relacionadas con impuestos mucho más capazmente que usando solo herramientas generales.

Ampliar

Una Habilidad es un Formato

Una Habilidad es un formato. El archivo raíz principal SKILL.md debe tener tanto un nombre como una descripción. Además, la Habilidad necesita mapearse exactamente al nombre del directorio en el que se encuentra. El nombre debe estar escrito completamente en minúsculas, no tener Espacios y puede usar guiones. La descripción es el disparador de enrutamiento. Este es un punto de falla común: la descripción no es documentación interna sobre lo que hace la Habilidad. Equivale a instrucciones para el modelo sobre cuándo cargar la Habilidad. Por lo tanto, verá con frecuencia “Cargar cuando”, no “Esta Habilidad hace”. Esto es importante debido a la forma en que la mayoría de las implementaciones inyectan la descripción en el contexto del modelo.

Dentro del frontmatter, también hay “depends:”, que le permite crear dependencias jerárquicas de Habilidades, y “metadata:”, que se utiliza para revisiones y evaluaciones. Diferentes sistemas de agentes pueden incluso definir sus propios campos de frontmatter, para ser utilizados de una manera específica para esos sistemas. Como alternativa, los metadatos específicos de la Habilidad pueden empaquetarse en un archivo de configuración auxiliar JSON o YAML. Esto es deseable al construir sistemas de agentes que necesitan facilitar diferentes tipos de comportamiento en tiempo de ejecución por Habilidad sin contaminar el contexto del modelo con minucias. Finalmente, un comportamiento similar se puede obtener eliminando el frontmatter de la Habilidad al leer. Computer emplea esta metodología, lo que permite que la configuración se conserve en el archivo raíz SKILL.md. Se requiere una atención cuidadosa a los detalles en la lógica de análisis, y uno podría desear implementar la eliminación condicional si hay ciertos campos que es útil tener dentro del contexto del modelo.

Una Habilidad es Invocable

Una Habilidad es invocable. El agente carga una Habilidad en tiempo de ejecución. Es importante destacar que las Habilidades no siempre están incluidas en el contexto. Por defecto, la mayoría de los sistemas de agentes despliegan las Habilidades progresivamente según necesidades específicas.

Hay al menos tres niveles de costos de contexto en la forma en que hemos implementado las Habilidades en Computer. Este es el proceso:

Computer llama a load_skill(name="...")

Computer copia el directorio de la Habilidad en el entorno aislado de ejecución

Computer carga automáticamente y de forma recursiva las dependencias en la etiqueta “depends:”

Computer luego elimina el frontmatter y el agente, por lo tanto, solo ve el cuerpo y los archivos adicionales

Diferentes sistemas de agentes pueden optar por exponer el contenido de la Habilidad de diferentes maneras. Como ejemplo, algunos sistemas podrían optar por no exponer la jerarquía de archivos en absoluto, dejando que el modelo descubra la jerarquía a través de operaciones del sistema de archivos. Otros sistemas pueden optar por dar al modelo un mapeo de todo el árbol de archivos hasta cierto límite de truncamiento y/o profundidad. Para mantener el contexto limpio, Computer omite jerarquías de archivos completas del contexto de invocación; sin embargo, esto se puede anular por Habilidad.

Una Habilidad es Progresiva

Las Habilidades son progresivas. En Computer, hay tres niveles diferentes de costos de contexto, y incurrimos en los tres en varias etapas:

Los tres niveles de contexto de Skill: índice, carga completa de Skill y archivos de referencia en tiempo de ejecución.

Computer construye un índice de Habilidades que tiene el nombre y la descripción de cada Habilidad disponible. El presupuesto para esto es de alrededor de 100 tokens por Habilidad (más corto es aún mejor). Es tan ajustado porque está pagando este costo en cada Sesión, para cada usuario. Esto se inyecta en el aviso del sistema al comienzo mismo de la conversación. El modelo tiene acceso a un grupo de Habilidades y descripciones nombradas para que pueda decidir si llamar a “load_skill()”. La barrera para entrar en este índice es extremadamente alta. Su Habilidad necesita ser muy útil, y la descripción necesita ser extremadamente densa y concisa porque todos están pagando el costo todo el tiempo.

Después de que el sistema de agentes carga la Habilidad, queda el cuerpo completo de SKILL.md. Idealmente, el texto del cuerpo no debe exceder los 5,000 tokens. Incluso entonces, desea que cada oración importe porque una vez que carga una Habilidad, el resto de la conversación tiene que pagar eso hasta que llegue al límite de compactación. Muchos hilos cargan entre tres y cinco Habilidades diferentes, multiplicando este costo. Las Habilidades con mucho relleno degradarán casi con certeza otras Habilidades, así como las capacidades de los agentes en general. En resumen, si su Habilidad se carga y no hace lo correcto, eso es contexto desperdiciado.

El nivel final de progresión son los scripts o casos especiales, como subhabilidades o formato. Aquí es donde desea poner lógica de ramificación condicional sin límites. El agente solo lo usará cuando lo necesite, lo que significa que hay una barrera mucho más baja para lo que desea poner aquí.

En el índice, cada token es importante. El cuerpo de la Habilidad cargada es más relajado, y el tiempo de ejecución es el más relajado. Esto podría ser de 20,000 tokens o cero tokens. Este es el nivel en el que podría pensar sobre expandir el contexto del modelo de forma progresiva mediante el Razonamiento.

¿Cuándo necesita una Habilidad?

Al equipo de Agentes a menudo se le pide que opine sobre si una Habilidad es realmente necesaria para un dominio o caso de uso determinado. Rara vez tenemos una respuesta definitiva basada únicamente en principios fundamentales. La única forma de descubrir esto realmente es comenzar con su agente sin la Habilidad, ejecutar varias consultas heroicas y luego descubrir si el agente está haciendo un buen trabajo.

Cuando necesita una Habilidad

Hay muchas tareas que están en distribución para modelos entrenados. Solo necesita aplicar una Habilidad si desea cambiar ese comportamiento de alguna manera específica que no puede, por ejemplo, con una oración en su solicitud. Por lo tanto, necesita una Habilidad cuando el agente se equivocará sin contexto especial, o si hay alguna inconsistencia o no determinismo que necesite ser extremadamente consistente en todas las ejecuciones.

Podría ser que su conocimiento sea duradero pero no esté en los datos de entrenamiento. Podría haber límites o flujos de trabajo específicos de la empresa, o podría ser una cuestión de gusto. Por ejemplo, tenemos varias Habilidades relacionadas con el diseño en Computer escritas por Henry Modisett (nuestro jefe de diseño). La razón por la que cada token existe en esas Habilidades es porque Henry tiene muy buen gusto cuando se trata de diseñar sitios web y archivos PDF. Henry especifica qué fuentes usar y qué fuentes no usar, cómo se sienten esas fuentes, y otros asuntos de juicio que el modelo no puede aprender solo de los datos de entrenamiento.

Cuando no necesita una Habilidad

Vemos muchas Habilidades en las que los ingenieros han escrito una serie de comandos git que deben ejecutarse en orden. Eso es innecesario porque el modelo ya sabe cómo hacer eso, lo que significa que es una excelente documentación pero una Habilidad deficiente.

Vemos ejemplos donde las Habilidades recapitulan instrucciones del aviso del sistema. No necesita una Habilidad para eso. El conocimiento relevante para la mayoría de las solicitudes debe incluirse en el contexto global, no en una Habilidad cargada condicionalmente

Si hay algo que está cambiando más rápido de lo que puede mantenerlo, no necesita una Habilidad. Por ejemplo, si está accediendo a algún punto final remoto de MCP y sus herramientas o las versiones de esas herramientas cambian con frecuencia, no debería inyectarlas en una Habilidad. Si lo hace, terminará con deriva y el modelo cometerá errores.

Cada Habilidad es un impuesto

Aquí hay una prueba útil que puede aplicar a cada oración en su Habilidad: “¿El agente se equivocaría sin esta instrucción?” Si la oración no necesita estar ahí, no puede permitirse estar ahí porque todos están pagando este costo cada vez. Cuando decida si agregar una Habilidad o no, recuerde este impuesto en el que cada Sesión y cada usuario cuestan tokens.

La siguiente cita famosa, que suena mucho mejor en francés, se traduce aproximadamente como “Solo he hecho esta carta más larga porque no he tenido tiempo para hacerla más corta”.

« 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

Al igual que Pascal, necesita invertir tiempo en cada Habilidad. Es difícil escribir una Habilidad corta. Si su Habilidad es fácil de escribir, probablemente sea demasiado larga o no debería existir. Una buena Habilidad es tan corta como puede ser.

Si se encuentra intentando generar una Habilidad de un solo intento y enviando PRs en cinco minutos, los resultados serán casi con certeza deficientes. De hecho, investigaciones tempranas han demostrado que si está utilizando LLMs para escribir Habilidades, el LLM probablemente no se beneficiará de ello: “Las Habilidades autogeneradas no ofrecen ningún beneficio en promedio, lo que demuestra que los modelos no pueden autorar de manera confiable el conocimiento procedimental del que se benefician al consumir”.

Cómo construir una Habilidad

Dicho de otra manera, necesita inyectar su opinión en cualquier Habilidad que escriba. Siga estos pasos.

Paso 0: Escribir las Evals

Escriba algunas de las evals primero. Puede obtener casos de evaluación de:

Consultas de usuarios reales: muestra de producción o de su grupo de confianza

Fallos conocidos: El agente falló porque la Habilidad no existía

Confusión de vecinos: Cerca de su límite de dominio pero se enruta a otra Habilidad

Como mínimo, debe asegurarse de estar probando que la Habilidad se carga cuando es necesario. Idealmente, muestrea algunos de estos, tal vez de un entorno de producción. También puede considerar casos de error conocidos: tal vez la razón por la que se propuso escribir la Habilidad es por un fallo específico que notó o tal vez está refactorizando y hay algo de confusión en dos dominios cercanos que están cubiertos por una Habilidad.

Comience con ejemplos negativos y positivos similares. Los ejemplos negativos son extremadamente poderosos y pueden importar más que los positivos.

Paso 1: La Descripción

Esta es la línea más difícil en la Habilidad. Es un disparador de enrutamiento, no documentación. Para obtener el nombre y la descripción correctos, no le importa el contenido de la Habilidad. Solo le importa si la Habilidad se carga e inyecta en los puntos correctos y está libre de efectos secundarios fuera del objetivo, que es el modo de fallo número uno. Cada vez que agrega una Habilidad adicional, arriesga hacer que cada otra Habilidad sea ligeramente peor, por lo que necesita asegurarse de minimizar la regresión.

Nuevamente, una mala descripción describe lo que hace la Habilidad o por qué es útil. Una buena descripción dice cuándo el agente debe cargar la Habilidad. Por ejemplo, digamos que tiene algo para monitorear solicitudes de incorporación de cambios. No escriba lo que hace la Habilidad. Escriba lo que dicen los ingenieros cuando están frustrados y quieren que se asegure de que su PR funcione, como “cuidar” o “verificar CI” o “asegurarse de que esto aterrice”.

Aquí hay una lista de verificación rápida:

Comienza con "Cargar cuando..."

Apunte a 50 palabras o menos

Describe la intención del usuario, idealmente a partir de consultas reales

No resume el flujo de trabajo

Las consultas reales son lo que puede cubrir en un 80-20. Por lo general, dos o tres ejemplos funcionan bien. No es fácil agregar exactamente y solo tanto como necesite.

Paso 2: Escribir el Cuerpo

A continuación, escriba el contenido de la propia Habilidad. Note que este no es el Paso 0 o el Paso 1.

Comunicar flujos de trabajo a un LLM es completamente diferente a comunicarlos a un colega, o incluso a su sistema de tiempo de ejecución. Al aprender una nueva herramienta de software, un ingeniero puede necesitar leer la documentación, obtener un recorrido de alguien con experiencia y aprender a usar la herramienta. Mientras tanto, para casi cualquier herramienta de software que ha existido al menos un año, solo necesita mencionar su nombre y el LLM tiene toda la información que necesita.

Cuando esté escribiendo el cuerpo, omita las cosas obvias. Muchos ingenieros tienen mucha experiencia escribiendo archivos readme.md que enumeran cada comando que alguien necesita ejecutar. Es fácil caer de nuevo en eso cuando escribe una Habilidad porque se siente como si estuviera escribiendo documentación, pero si hace eso, su Habilidad será basura. Así que no escriba una serie de comandos.

Por ejemplo, no necesita escribir, “git log # encuentre el commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

En su lugar, escriba, “Haga cherry-pick del commit a una rama limpia. Resuelva conflictos preservando la intención. Si no puede aterrizar limpiamente, explique por qué.”

El modelo hará un trabajo mucho mejor con lo último que con la serie de comandos excesivamente prescriptivos del primero, especialmente cuando las cosas salen mal. No fuerce, ni sea excesivamente prescriptivo, lo cual es frágil, y en su lugar sea flexible donde múltiples enfoques pueden funcionar. Nuevamente, una buena documentación para humanos es a menudo una mala documentación para modelos.

A continuación, concéntrese en los problemas imprevistos o ejemplos negativos. Estos son contenido de señal extremadamente alta porque a menudo guían al modelo en términos de qué no hacer. Si agrega una línea cada vez que el agente tropieza, aprenderá ejecutándolo y los problemas imprevistos crecerán orgánicamente.

Por último, si hay alguna parte que es condicional o extremadamente pesada en contenido, sáquela del SKILL.md, que es el centro, y póngala en uno de los radios. Póngala en un archivo accesorio que pueda cargarse progresivamente, en lo que profundizaremos a continuación.

Paso 3: Utilizar la Jerarquía

Haga uso de la jerarquía de Habilidades cuando tenga un script, referencias o esté usando alguna herramienta específica:

Usos sugeridos para scripts, referencias, recursos y configuración dentro de un Skill.

Para cualquier cosa que sea condicional o que se ramifique de la Habilidad principal, divídalo en una carpeta. Recuerde, también, que la jerarquía multinivel se puede usar para Habilidades particularmente intrincadas. Para estas, querrá pensar cuidadosamente si la funcionalidad debe implementarse monolíticamente o como una colección de Habilidades (quizás con relaciones de carga basadas en depends:).

Paso 4: Iterar

A continuación, realice un montón de iteraciones en una rama. Comience en la rama principal sin Habilidad, haga algunas iteraciones, cree su conjunto de consultas heroicas y ejecute una serie de evals. Cualquiera que revise su código de Habilidad le agradecerá por enviar un solo conjunto de cambios completo con un conjunto de evaluación. Revisar cambios incrementales consecutivos (excepto un nuevo problema imprevisto) es muy difícil, así que intente minimizarlo.

Probablemente hará muchos cambios pequeños de palabras. Los pequeños cambios de palabras en las descripciones pueden tener un impacto enorme en el enrutamiento (incluidos los efectos secundarios en otras Habilidades), así que haga todo ese trabajo antes del Paso 5.

Paso 5: Enviar

Envíelo.

Cómo Mantener una Habilidad

Ahora que ha escrito una Habilidad, tiene que mantenerla.

El Volante de Problemas Imprevistos

Desde este punto en adelante, su lista de problemas imprevistos tiende a crecer o cambiar mucho. A menudo vemos ingenieros que hacen PRs que no están evaluados, por ejemplo, cambiar la descripción. Si está cambiando la descripción después de que su Habilidad se haya fusionado, está fuera de camino. Si está haciendo cambios en lo que decide si enrutar su Habilidad, necesita escribir algunas evals que apoyen los cambios.

Las Habilidades son principalmente para añadir. La sección de problemas imprevistos acumula el mayor valor con el tiempo:

El agente falla en algo → Agregue un problema imprevisto

El agente carga la Habilidad fuera del objetivo → Ajuste la descripción y agregue evals negativas

El agente no carga la Habilidad cuando debería → Agregue palabras clave y evals positivas

El aviso del sistema cambia → Verifique si hay contención o duplicación

Es fácil notar un solo caso de fallo en las pruebas internas o en producción y agregar un problema imprevisto. Es un ejemplo negativo, así que realmente no está cambiando la guía explícita, pero le permite al modelo saber: “Oye, existe este fallo conocido”.

A medida que avanza del 80-20 a llegar a una tasa de éxito del 99.9% o 99.99%, es fácil hacer crecer esta lista de problemas imprevistos. A medida que vea estos ejemplos negativos, debería estar añadiendo principalmente a la sección de problemas imprevistos. No debería estar agregando instrucciones más largas ni cambiando la descripción.

Conjuntos de Evaluación

En Perplexity, ejecutamos muchos conjuntos de evaluación para verificar diferentes cosas. Existen la carga de Habilidades y las lecturas de archivos de Habilidades, que verifican la precisión, el recuerdo y las verificaciones prohibidas de la carga de la Habilidad en sí. ¿El agente enrutará su Habilidad cuando se supone que debe hacerlo? Estos aseguran que las nuevas Habilidades no rompan los límites existentes.

También hay evals que pueden verificar la carga progresiva adecuada. El agente podría cargar la Habilidad, pero ¿lee el archivo o archivos accesorios? Por ejemplo, si tiene una Habilidad de finanzas para consultas financieras, ¿lee el archivo especial FORMATTING.md?

También hay evals para Habilidades que prueban la finalización de tareas de extremo a extremo dentro de los dominios. Ejecutamos el bucle completo del agente y usamos un juez LLM para calificar los resultados basados en una rúbrica de criterios bien definidos.

Finalmente, es importante ejecutar estas evals contra diferentes modelos. Computer admite al menos tres familias diferentes de modelos de orquestación: GPT, Claude Opus y Claude Sonnet. Quiere ejecutar la carga de su Habilidad y las Habilidades de dominio contra estos diferentes orquestadores de agentes para asegurarse de que no obtenga un comportamiento diferente. Sonnet y GPT se comportan de manera muy diferente cuando se trata de Habilidades.

Reflexiones finales y conclusiones

Cuantas más Habilidades construya, mejor se volverá construyéndolas. Si no está automatizando o intentando hacer más tareas reproducibles que está haciendo día a día usando Habilidades, comience de inmediato.

El acto de construir Habilidades lo hace mejor en la construcción de más Habilidades, pero además, son extremadamente buenas para automatizar procesos de negocio. Si puede describir algo que hace cada semana antes de su reunión diaria, al final de cada sprint, o cualquier cosa que haga como ingeniero de forma diaria, semanal o incluso trimestral, debería estar escribiendo una Habilidad para recuperar su tiempo.

¿Puede automatizar postmortems? ¿Puede revisar solicitudes de incorporación de cambios? Cualquier tarea que pueda hacer, al menos puede hacer que la primera pasada sea una Habilidad de Agente. Le ahorrará un tiempo significativo.

Dicho esto, recuerde que una Habilidad no es fácil ni siquiera siempre necesaria. Menos es más. Algunas otras conclusiones:

Escriba evals antes que la Habilidad. Incluya ejemplos negativos y cargas prohibidas para habilidades adyacentes pero distintas.

La descripción es la parte difícil. “Cargar cuando...” (cada palabra cuesta atención).

Los problemas imprevistos son contenido de valor extremadamente alto. Comience poco a poco, crezca a medida que el agente falla.

Recuerde que es fácil romper otras Habilidades preexistentes al agregar una nueva, aunque no la haya tocado (tenga cuidado con la acción a distancia).

Use todas las herramientas disponibles cada vez que esté escribiendo y manteniendo una Habilidad. Si desea aprender más, el sitio web de Habilidades de Agente tiene muchos ejemplos buenos, y tanto nuestro repositorio interno como el ecosistema público contienen muchos ejemplos de Habilidades bien diseñadas.

Citación

@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}
}