--- title: "Mantener skills en varios repositorios · SourceAnt" description: "Cómo compartir skills de agentes sin perder el control de las actualizaciones: skills locales, fijación con Git, MCP, excepciones por repositorio y pruebas para instrucciones revisadas." url: "https://sourceant.ai/es/blog/maintain-skills-across-repositories/" --- [Todas las publicaciones](https://sourceant.ai/es/blog) 26 de septiembre de 2026 · SourceAnt skillsmcpcolaboración # Cómo mantener una skill en varios repositorios Supón que escribes una skill para revisar cambios de API. Pide a tu asistente de programación que compruebe permisos, preserve la compatibilidad y pruebe las solicitudes rechazadas. Funciona lo bastante bien como para que la copies de tu repositorio de facturación a tu servicio de cuentas y a tu API pública. Después, un revisor encuentra una comprobación que falta. El asistente comprobó si un usuario había iniciado sesión, pero pasó por alto si ese usuario era el propietario del registro. Mejoras la skill en facturación. Las otras dos copias siguen conteniendo las instrucciones antiguas. Podrías volver a copiar la corrección. Pero alguien ya ha cambiado la versión de la API pública para atender a un cliente antiguo. Reemplazar ese archivo borraría su cambio. Dejarlo como está mantendría la comprobación ausente. Aquí es donde compartir una skill se convierte en mantener una. Necesitas saber qué instrucciones son compartidas, qué diferencias son deliberadas y cómo llega una mejora a quienes las usan. ## Decide cuándo debe llegar una actualización a un repositorio Una ubicación compartida responde dónde vive la skill. No responde cuándo debería alguien empezar a usar un cambio. Para una skill de redacción, quizá quieras que todos reciban instrucciones más claras en su siguiente tarea. Para una skill de publicación, quizá quieras que cada repositorio revise un procedimiento nuevo antes de usarlo. Ninguna de las dos políticas es adecuada para todas las skills. Hay varias formas de tomar esa decisión. ### Las skills de una persona en varios proyectos Si eres el único usuario, un directorio personal de skills puede bastar. Claude Code, por ejemplo, admite skills personales en varios proyectos de una misma máquina. También admite directorios de skills enlazados a otra ubicación del disco. Son funciones documentadas, así que copiar una skill en cada repositorio es innecesario en ese caso. Consulta [las ubicaciones de skills de Claude Code](https://code.claude.com/docs/en/skills#choose-where-skills-load). Un enlace puede apuntar varios proyectos a una copia local. No puede mantener actualizada la máquina de un compañero. En cuanto otra persona necesite la skill, decide cómo obtiene esa copia y sus actualizaciones. ### Un repositorio Git compartido con actualizaciones revisadas Mantén las skills en un repositorio aparte cuando quieras que su historial y su proceso de revisión estén en Git. Cada proyecto consumidor puede incluir una revisión elegida mediante un submódulo. Git registra un commit concreto para ese submódulo; no sigue en silencio cada cambio del repositorio compartido. Consulta [la documentación de submódulos de Git](https://git-scm.com/book/en/v2/Git-Tools-Submodules). Eso le da al propietario de un repositorio una decisión clara: conservar las instrucciones actuales o adoptar una revisión más reciente. También añade una tarea de actualización a cada proyecto consumidor. Tu configuración debe colocar la skill donde la herramienta de programación pueda descubrirla, y las nuevas copias de trabajo deben obtener el contenido del submódulo. Elige este enfoque cuando poder identificar y restaurar las instrucciones exactas importe más que recibir cada mejora de inmediato. Fijar las instrucciones no hace que la salida del modelo sea idéntica, pero elimina una fuente de cambio. ### Obtén las instrucciones compartidas cuando se necesiten Otro enfoque es dejar que la herramienta de programación solicite la skill a un servicio compartido. MCP proporciona una conexión mediante la cual una herramienta puede recuperar esas instrucciones. Con un servicio que devuelve la versión actual, una actualización puede llegar a la siguiente solicitud sin cambiar cada repositorio. Esto cambia el trabajo de actualización local por una dependencia del servicio. Decide qué ocurre si una solicitud falla. Si mantienes una copia de respaldo, registra de dónde vino y cuándo se actualizó por última vez. De lo contrario, habrás recreado el problema de la copia olvidada con otro nombre. Mi recomendación es elegir la política de actualización antes que la herramienta de distribución. Usa revisiones revisadas para procedimientos que necesiten una adopción controlada. Obtén las instrucciones actuales cuando el equipo quiera una versión común y al día. Un equipo puede usar ambas para skills distintas. ## Separa la regla del detalle del repositorio Ni siquiera una distribución perfecta puede hacer que una instrucción específica de facturación sea útil en todas partes. Considera esta instrucción: > Ejecuta las pruebas de la API de facturación y luego comprueba que los usuarios no puedan leer las facturas de otro cliente. Contiene una comprobación reutilizable y detalles locales. Separa esas ideas: > Para cada endpoint modificado que acceda a un registro propiedad de un usuario, comprueba tanto la propiedad como la autenticación. Encuentra el comando de pruebas documentado del repositorio y prueba la solicitud rechazada a través del endpoint. La skill compartida ahora describe qué comprobar. El repositorio aporta su comando de pruebas y sus ejemplos de dominio. Esto no significa volver vaga cada instrucción. «Sigue las buenas prácticas» le da poco que hacer a un asistente. «Comprueba si un usuario autenticado puede acceder al registro de otro usuario» nombra un fallo concreto y sigue siendo útil en varios servicios. Una prueba de edición útil es preguntar si una frase seguiría teniendo sentido en el segundo repositorio. Si nombra un script, un directorio o un destino de despliegue local, pon ese detalle junto al proyecto que lo posee. Indica a la skill compartida dónde buscarlo y qué hacer si falta. Comprueba también qué estás compartiendo. La [especificación de Agent Skills](https://agentskills.io/specification) define una skill como un directorio, que puede incluir scripts, referencias y recursos junto con `SKILL.md`. Un documento que hace referencia a `scripts/check-api.py` está incompleto sin ese script. Mover solo el Markdown no traslada sus dependencias. ## Tratar una anulación como una versión separada que mantener A veces la API pública realmente necesita instrucciones diferentes. Quizá sus clientes antiguos dependen de un campo de respuesta que los servicios internos ya no utilizan. Mantenga esa excepción acotada. Registre por qué existe, quién es responsable de ella y qué permitiría eliminarla. Cuando sea posible, conserve el procedimiento compartido y proporcione la restricción local por separado. Si su herramienta reemplaza la habilidad completa cuando encuentra una anulación del repositorio, la anulación se convierte en otra versión que mantener. Una corrección de la habilidad compartida no llegará necesariamente a ella. Para la comprobación de titularidad de nuestro ejemplo, el mantenedor debería revisar ambas versiones. La regla de compatibilidad de la API pública no explica por qué debería omitirse una comprobación de titularidad. Son cuestiones independientes. Esta es también una razón para evitar anular una habilidad completa solo para cambiar un comando de prueba. Una pequeña diferencia local no debería obligarle a mantener una segunda copia de cada regla compartida. ## Probar una mejora antes de compartirla Una instrucción que parece más clara puede aun así producir una revisión peor. Conserve algunas tareas reales de repositorios que usan la habilidad, junto con el resultado que espera. La [guía de evaluación de Agent Skills](https://agentskills.io/skill-creation/evaluating-skills) recomienda comparar ejecuciones con una habilidad frente a una línea base, que puede ser la versión anterior. Use sesiones nuevas para que una conversación previa no aporte instrucciones que la propia habilidad no tiene. Juzgue los resultados observables, en lugar de si la respuesta suena exhaustiva. Para la habilidad de revisión de API, seleccione cambios reales del pasado que cubran estos casos: | Cambio pasado que seleccionar | Qué buscar en la revisión | | --- | --- | | Un error de titularidad conocido | Identifica el fallo de acceso y señala el código relevante | | Una corrección que ya aplica la titularidad | Reconoce la protección en lugar de repetir el hallazgo anterior | | Un cambio que afecta al campo de respuesta heredado | Respeta la restricción de compatibilidad documentada de la API pública | | Un cambio ajeno al comportamiento de la API | Evita inventar hallazgos de API para satisfacer la lista de comprobación | Ejecute la habilidad antigua y la revisada con los mismos cambios. Conserve juntas las entradas, las instrucciones y las salidas. Si un resultado le sorprende, repita la comparación antes de decidir que la edición ayudó. El segundo caso importa tanto como el primero. Una instrucción que hace que un asistente acuse a cada endpoint de omitir comprobaciones de acceso ha aumentado el ruido, aunque detecte el error original. Asigne a una persona o equipo la responsabilidad de aceptar cambios compartidos. Los compañeros de equipo deberían poder aportar mejoras, pero alguien debe decidir si la evidencia respalda convertirlas en el comportamiento predeterminado. ## Dónde encaja SourceAnt SourceAnt respalda el enfoque de servicio compartido. Una habilidad de espacio de trabajo está disponible en todos sus repositorios. Las herramientas de programación conectadas pueden buscar una habilidad, leerla o solicitarla mediante un prompt MCP. Actualizar la habilidad del espacio de trabajo cambia lo que recupera una solicitud posterior, a menos que ese repositorio tenga una anulación. La [guía de habilidades](https://sourceant.ai/es/docs/skills) cubre la configuración y el uso. Eso elimina la necesidad de mantener actualizado un archivo de instrucciones separado en cada copia de trabajo. No elimina la necesidad de probar cambios ni de mantener excepciones. Las anulaciones de repositorio de SourceAnt reemplazan la versión del espacio de trabajo; no fusionan en ella ediciones posteriores. Las instrucciones ya leídas en una conversación también deben solicitarse de nuevo tras una actualización. SourceAnt sobre MCP Usar una habilidad compartida desde su herramienta de programación 1. **Encontrar la habilidad**Escriba el prefijo. Cada habilidad del espacio de trabajo aparece listada con su finalidad. /sourceant:skill - `**/sourceant:skill:**test-culture`Describa el marco de pruebas, la estructura y los límites visibles sin suponer cobertura ni calidad. - `**/sourceant:skill:**contract-consistency`Compruebe si los cambios en entradas, salidas, errores o reglas de acceso rompen a los consumidores existentes. - `**/sourceant:skill:**duplicate-implementation`Compruebe si el código recién añadido duplica el comportamiento existente e introduce un problema concreto. 2. **Asignarle una tarea**Añada sobre qué trabajar. Indique un repositorio para usar su propia versión de la habilidad, si la tiene. /sourceant:skill:contract-consistency tarea Revisar el cambio en el endpoint de facturas repositorio billing 3. **Trabajar desde la versión actual**SourceAnt envía las instrucciones más recientes a la conversación con su tarea adjunta. Enviado al asistente Aplique la habilidad de revisión de coherencia de contratos a la tarea solicitada. Rastree cada contrato modificado desde el código que produce un valor hasta el código que lo usa. 1\. Lea ambos lados. Compare las entradas aceptadas, los campos devueltos, el manejo de errores y las comprobaciones de acceso. Repositorio: billing Tarea solicitada: Revisar el cambio en el endpoint de facturas Se muestra en Claude Code. Los nombres del prompt dependen de la conexión y de las habilidades disponibles. Empiece con una habilidad que ya use en dos repositorios. Compare las copias. Traslade las instrucciones genuinamente compartidas a una única versión mantenida y anote por qué existen las diferencias restantes. Antes de distribuir la siguiente edición, pruébela en una tarea real de cada repositorio. Eso le da una respuesta útil a la pregunta que copiar por sí solo no puede resolver: ¿se beneficiaron ambos proyectos del cambio? ## Dale a tu IA una memoria en la que pueda confiar Desde $49 al mes, con tus propias claves de modelo. Todos los ingenieros y todos los agentes incluidos, nunca por asiento. [Empezar gratis](https://app.sourceant.ai/) [Ver precios](https://sourceant.ai/es/pricing)