Todo equipo que ha adoptado agentes de IA para programar tiene un desarrollador cuyos prompts simplemente funcionan. Sus solicitudes de revisión vuelven estructuradas como le gusta al equipo. Sus instrucciones para escribir tests generan tests que siguen el estilo de la casa a la primera. Si le preguntas cómo lo hace, la respuesta suele ser un archivo temporal, un repositorio de dotfiles o un párrafo que pega en una sesión nueva cada mañana. El oficio es real. El problema es dónde vive.
El arte del prompt que vive en la cabeza de una sola persona no escala, no sobrevive a las vacaciones y no aparece en las ejecuciones del agente de nadie más. Cuando ese desarrollador no está, la calidad cae. Cuando el equipo pasa de un agente a cinco, esos cinco no se ponen de acuerdo sobre cómo debería hacerse el trabajo.
Los Skills son la respuesta de Sharkly a esa brecha. Un Skill empaqueta instrucciones reutilizables y archivos de apoyo para el trabajo de los Agents, con un propietario, un alcance y permisos explícitos. Si prefieres empezar por el concepto general, qué es un Skill de agente de programación cubre la definición y el ecosistema en conjunto. Este artículo trata del flujo de trabajo dentro de Sharkly.
TL;DR
Un Skill en Sharkly empaqueta instrucciones reutilizables y archivos de apoyo para el trabajo de los Agents: reglas de revisión, checklists de entrega, estándares de redacción, un proceso de equipo. Puedes crearlo desde cero, instalar un Skill publicado desde una fuente pública compatible, importar uno descubierto por un Runtime local o subir un SKILL.md, un archivo .skill o un paquete zip. Cada Skill tiene exactamente un alcance —Organization, Space o Agent—, que se elige al crearlo y queda fijo de por vida. Los Agents vinculan los Skills elegibles desde su configuración de Skills, los cambios se aplican a las ejecuciones posteriores y los derechos de edición quedan en manos de su creador y de los Owners y Admins de la Organization. El resultado: el arte del prompt deja de vivir en los dotfiles de un desarrollador y se convierte en infraestructura de equipo compartida y controlada por permisos.
Qué cambia cuando el arte del prompt tiene un hogar
La diferencia entre un buen prompt y un Skill no está en el texto, sino en todo lo que rodea al texto.
Un prompt en un archivo temporal no tiene propietario, ni audiencia, ni ciclo de vida. Nadie sabe que existe, nadie puede saber si la copia que encontró en Slack está actualizada y nadie es responsable de actualizarla cuando el proceso cambia. Un Skill tiene las tres cosas. Pertenece a una organización. Su alcance indica exactamente qué Agents pueden usarlo. Sus permisos de edición indican exactamente quién puede modificarlo. Cuando el proceso cambia, actualizas el Skill una sola vez y las ejecuciones posteriores de todos los Agents vinculados adoptan el cambio.
Esa es la tesis del apalancamiento en miniatura. El apalancamiento de un equipo no viene de abrir más chats de IA, sino de compartir roles, reglas, contexto y flujos de trabajo. Y como los Agents devuelven sus resultados a la Task, el resultado de una ejecución guiada por un Skill acaba en el registro compartido, donde el equipo puede revisarlo.
Una frontera antes de entrar en el flujo de trabajo. Un Skill no es un requisito de una Task. Los requisitos puntuales déjalos en la descripción o en los comentarios de la Task. Si solo esta Task lo necesita, es contexto. Si las ejecuciones del mes que viene también lo necesitan, es infraestructura.
Crear un Skill desde cero
Un Skill empieza con tres cosas: un nombre, una descripción y unas instrucciones. Esa separación importa más de lo que parece.
La descripción indica cuándo debe usar el Agent el Skill. Es la condición de activación, la frase que le dice a un Agent que está repasando sus capacidades que esta se aplica al trabajo que tiene delante. Las instrucciones definen el proceso repetible y el resultado esperado: los pasos, las comprobaciones y el formato que debe adoptar el resultado. Una prueba útil es comprobar si puedes decir en una sola frase cuándo debería recurrir un Agent a este Skill. Si no puedes, probablemente estés ante dos Skills, o ante ninguno.
Por dentro, las instrucciones principales viven en un archivo SKILL.md: los campos YAML name y description en la parte superior, seguidos de las instrucciones. Los archivos de apoyo pueden viajar con él para aportar plantillas, ejemplos o datos de referencia. Un Skill de checklist de entrega podría llevar la plantilla del checklist; un Skill para redactar migraciones podría incluir dos ejemplos comentados. Mantenlos centrados. Las colecciones de archivos grandes o que no vienen al caso añaden contexto sin mejorar las decisiones del Agent.
Importar el arte que ya tienes
La mayoría de los equipos no parte de cero. El arte del prompt ya existe; simplemente está disperso. Sharkly te ofrece tres vías de importación.
Instalar desde una fuente pública compatible. Sharkly puede obtener un Skill publicado y crear una copia gestionada en el alcance que elijas. Que la copia sea gestionada importa: no estás enlazando al archivo de otra persona, estás tomando una instantánea que tu organización controla. Revisa la fuente y el contenido importado antes de vincularlo a cualquier Agent. Trata las instrucciones externas como código de terceros, no como política de confianza de la organización.
Importar desde un Runtime local. Esta es la vía pensada justo para el problema de los dotfiles. Un Runtime local conectado puede informar de los Skills que descubre en sus directorios locales de Skills, lo que significa que el arte que un desarrollador ha ido acumulando en silencio se vuelve visible para la organización. Al importar, el Skill se copia en la organización; la copia local original permanece aparte, así que nada de la configuración de ese desarrollador se rompe. Una advertencia mantiene esto honesto: los Skills locales disponibles directamente para el Runtime de un Agent no necesitan vincularse en el producto en absoluto. Importa uno cuando deba convertirse en un Skill gestionado y reutilizable con un alcance explícito, no solo porque exista.
Subir un paquete. Si el Skill vive en un repositorio o te lo pasó un colega, sube un SKILL.md, un archivo .skill o un paquete zip. Sharkly valida lo que entra: las rutas de archivo deben ser relativas y no pueden salirse del Skill, y tanto la subida como la importación rechazan rutas ocultas o sensibles, contenido binario no admitido, entradas de archivo no seguras, rutas duplicadas y paquetes que superan los límites del servicio. Un Skill son instrucciones que un Agent va a seguir; merece el mismo escrutinio que una dependencia.
Alcance: decidir quién puede usar un Skill
Todo Skill pertenece a una organización y tiene exactamente un alcance, elegido al crearlo. El alcance determina qué Agents pueden vincularlo y no se puede cambiar después.
| Alcance | Quién puede usarlo | Elígelo cuando | Regla de vinculación |
|---|---|---|---|
| Organization | Los Agents elegibles de toda la organización | El procedimiento es realmente de toda la empresa, como un estándar de revisión o un checklist de seguridad | Cualquier Agent de la misma organización puede vincularlo |
| Space | Los Agents asociados a ese Space | Un equipo o área de producto es el dueño del proceso | Un Agent no puede vincularlo a menos que pertenezca a ese Space |
| Agent | Un único Agent | La capacidad define el rol de un solo especialista | Se vincula a su Agent de destino al crearlo o importarlo |
La regla general de la documentación es la correcta: elige el alcance más restringido que coincida con la audiencia prevista. El alcance también es un radio de impacto. Un Skill con alcance de Space que queda obsoleto confunde a los Agents de un equipo; uno con alcance de Organization los confunde a todos. Un prompt en dotfiles tiene una audiencia de una sola persona, de forma permanente. La audiencia de un Skill es una decisión deliberada, registrada en el sistema.
Vincular Skills a los Agents
Un Skill no hace nada hasta que un Agent lo lleva consigo. En Sharkly, un Agent es una configuración de trabajo guardada, y vincular un Skill le añade una capacidad.
La mecánica es sencilla. Usa la configuración de Skills del Agent para añadir o quitar Skills elegibles, o selecciona Skills mientras creas el Agent. La elegibilidad sigue las reglas del alcance. Los cambios se aplican a las ejecuciones posteriores del Agent, así que una vinculación que añadas hoy da forma al trabajo de mañana sin alterar nada de lo que está en marcha.
La decisión de criterio es cuántos Skills debería llevar un mismo Agent. La documentación es tajante: evita vincular muchos Skills que se solapen, porque las instrucciones contradictorias o redundantes hacen que la ejecución sea menos predecible. Dos Skills precisos superan a seis que se pelean entre sí. Si la lista de Skills de un Agent parece un cajón desastre, sus ejecuciones también lo parecerán.
También hay un reparto de tareas entre las instrucciones propias del Agent y sus Skills. Las instrucciones del Agent contienen el comportamiento estable de ese rol concreto: su alcance, cuándo pedir intervención humana y el formato de los informes. Un procedimiento reutilizable que varios Agents pueden compartir pertenece a un Skill. Cuando te descubras pegando el mismo párrafo en las instrucciones de un tercer Agent, ese párrafo quiere ser un Skill.
La vinculación es lo que hace que el resto de la plataforma se potencie. El mismo Agent que lleva tu Skill de revisión es el que activan tus Automations según una programación o un cambio de estado, de modo que un estándar capturado una vez aparece en ejecuciones recurrentes que nadie lanza a mano. Los Skills también se pueden usar desde scripts: la CLI expone sharkly skill list y sharkly skill view con salida JSON.
Gobernanza: quién edita, quién elimina, quién revisa
Una capacidad compartida necesita un control compartido, y aquí es donde los Skills se distancian más de los archivos de prompts.
Un Skill puede ser editado o eliminado por su creador o por un Owner o Admin de la Organization. Un Skill con alcance de Space también requiere permiso de escritura en su Space. Crear o importar un Skill con alcance de Agent, y cambiar las vinculaciones de Skills de un Agent, requiere permiso para gestionar el Agent de destino. Nadie reescribe en silencio el estándar de revisión un viernes por la tarde.
El mantenimiento sigue el mismo principio de un único lugar. Cuando un proceso cambia, actualiza las instrucciones y los archivos de apoyo del Skill, y las ejecuciones posteriores adoptan la nueva versión. La eliminación es la operación en la que conviene frenar: quita el Skill de todos los Agents que lo usan, así que revisa antes las vinculaciones actuales.
Las reglas de seguridad son breves e innegociables. No guardes nunca contraseñas, tokens de acceso, claves privadas ni otros secretos en las instrucciones o los archivos de apoyo de un Skill. Revisa cada Skill externo o importado localmente antes de usarlo. Mantén los comandos y los ejemplos con el mínimo privilegio. Y vuelve a comprobar las vinculaciones después de cambiar las asociaciones de Space de un Agent o el contenido de un Skill, porque la elegibilidad puede cambiar bajo una vinculación.
A lo largo de todo esto, el contrato entre personas y agentes se mantiene. Los Agents cargan Skills, siguen el proceso y devuelven los resultados a la Task. Las personas deciden qué Skills tienen autoridad en el equipo. Un Skill eleva el mínimo de consistencia. No elimina al revisor.
Cuándo no crear un Skill
Los Skills son infraestructura, y la infraestructura tiene un coste de mantenimiento. El par de decisiones honesto: deja los requisitos puntuales en la descripción o los comentarios de la Task; crea un Skill cuando la misma capacidad deba estar disponible en ejecuciones futuras.
Algunos casos más en los que la respuesta correcta es no crear ningún Skill. Si un procedimiento vive en el directorio de Skills de un Runtime local y solo lo necesitan las ejecuciones de ese Computer, déjalo en local. Si dos Skills candidatos se solaparan mucho en el mismo Agent, fusiónalos o afínalos antes de vincular ninguno de los dos. Y si no puedes escribir la frase de la descripción, el proceso aún no es lo bastante estable como para capturarlo.
Empieza con un solo procedimiento
Elige un procedimiento que tu equipo repita y del que dependa en silencio una sola persona. Escríbelo como un único Skill concreto: un nombre, una descripción que indique cuándo se aplica y unas instrucciones que definan el proceso y el resultado esperado. Dale alcance de Space. Vincúlalo a un Agent, asígnale a ese Agent una Task real y lee lo que devuelve.
Ese es todo el ciclo. El arte que vivía en la cabeza de un desarrollador ahora tiene un nombre, un alcance, un propietario y un único lugar donde actualizarlo. Si eres nuevo en la plataforma, la descripción general de Sharkly explica cómo encajan los Skills junto a las Tasks, los Agents y los Computers, y primeros pasos con Sharkly recorre la primera conexión de principio a fin. La documentación de Skills cubre con detalle todas las reglas anteriores.
Preguntas frecuentes
¿Cuál es la diferencia entre un Skill y las instrucciones de un Agent?
Las instrucciones de un Agent definen el comportamiento estable de un rol: su alcance, cuándo pedir intervención y cómo informar. Un Skill es un procedimiento reutilizable que varios Agents pueden compartir, empaquetado con sus propios archivos de apoyo y permisos. Si un párrafo se copia de un Agent a otro, pertenece a un Skill.
¿Puedo cambiar el alcance de un Skill después de crearlo?
No. El alcance de un Skill queda fijo al crearlo. Cuando la audiencia tenga que cambiar, crea un Skill nuevo con el alcance adecuado y vuelve a vincular los Agents que lo necesiten. Por eso la documentación recomienda elegir desde el principio el alcance más restringido que coincida con la audiencia prevista.
¿Los Skills importados se mantienen sincronizados con su origen?
No. Instalar desde una fuente pública compatible crea una copia gestionada en el alcance que elijas, e importar desde un Runtime local copia el Skill en la organización mientras la copia local original permanece aparte. A partir de ese momento, tu organización controla su copia.
¿Vincular un Skill nuevo afectará a las Tasks que un Agent tiene en ejecución?
No. Los cambios en las vinculaciones de Skills de un Agent se aplican a las ejecuciones posteriores. El trabajo que ya está en marcha termina con la configuración con la que empezó, y la siguiente ejecución adopta el conjunto de Skills actualizado.
¿Es seguro instalar Skills desde fuentes públicas?
Pueden serlo, con revisión. Trata cada Skill externo o importado localmente como código o configuración de terceros: lee las instrucciones y los archivos de apoyo antes de vincularlo, mantén los comandos con el mínimo privilegio y no dejes nunca que un secreto entre en un Skill. La validación de subidas de Sharkly rechaza rutas y entradas de archivo no seguras, pero el juicio sobre si unas instrucciones merecen la confianza de tu equipo sigue siendo cosa de las personas.
