Compartir skills de agentes entre repositorios sin desvíos

Cómo compartir habilidades de agente entre repositorios

Para compartir habilidades de agente entre repositorios, deje de copiar el archivo y empiece a depender de él. Mantenga un único repositorio de habilidades, asígnele etiquetas y permita que cada proyecto fije una etiqueta. Después, añada una prueba básica por habilidad y revise cada actualización igual que revisaría la actualización de una dependencia.

Son cuatro partes: una fuente de verdad compartida, una versión fijada por repositorio, una prueba básica por habilidad y un proceso de revisión. Todo lo que sigue explica por qué existe cada parte, qué hacen al respecto las herramientas publicadas en 2026 y cómo crear el conjunto completo en un remoto de git autogestionado, sin usar un servicio externo de git ni un registro de paquetes. Las pruebas básicas son la única excepción. Ejecutan Claude Code, que envía cada solicitud a una API de modelo, por lo que ese paso todavía sale de su servidor.

Una habilidad de agente es una carpeta que contiene un archivo SKILL.md, además de los scripts y archivos de referencia que necesita. Si esta unidad es nueva para usted, lea primero qué es una habilidad de agente y cómo funciona SKILL.md. Esta página trata sobre la cadena de suministro que rodea a esa unidad.

Dónde vive una skill y por qué es difícil compartirla

Claude Code carga skills desde las siguientes ubicaciones, entre otras, y la documentación de skills enumera cada ruta.

• .claude/skills/<skill-name>/SKILL.md dentro del directorio de configuración administrada es la ubicación empresarial. Se carga para todos los usuarios de los equipos donde una organización la implementa.
• ~/.claude/skills/<skill-name>/SKILL.md es personal. Se carga en todos tus proyectos y en los proyectos de ninguna otra persona.
• .claude/skills/<skill-name>/SKILL.md corresponde al nivel del proyecto. Se carga para cualquiera que clone ese repositorio.
• <plugin>/skills/<skill-name>/SKILL.md se incluye en un plugin. Se carga en cualquier lugar donde ese plugin esté habilitado.

Claude Code también carga skills desde directorios de proyecto anidados, directorios proporcionados mediante --add-dir y skills habilitadas para tu cuenta de claude.ai.

La ubicación del nivel del proyecto es la útil para un equipo, porque se confirma en el repositorio y todos los que lo clonan la obtienen. También es donde empiezan los problemas. Una skill en .claude/skills/ pertenece a un repositorio. Tienes ocho repositorios. Por tanto, la skill se copia ocho veces.

El frontmatter no ayuda. La especificación Agent Skills permite seis claves, y las rutas de distribución que la aplican muestran la lista cuando usas otra:

Unexpected key(s) in SKILL.md frontmatter: argument-hint. Allowed properties are: allowed-tools, compatibility, description, license, metadata, name

Observa qué falta: no existe ninguna clave version. El archivo no registra qué copia es más reciente. Esto es razonable, porque una skill es un documento, no un paquete. Sin embargo, significa que el control de versiones debe proceder de la capa que rodea al archivo, y esa capa es responsabilidad tuya.

Problema uno: ocho copias que divergen sin que nadie lo advierta

Copiar y pegar funciona el primer día. Falla al día sesenta. Alguien corrige una instrucción incorrecta en el repositorio payments y no actualiza las otras siete copias. Otra persona añade una regla sobre paginación en orders. Ahora, el mismo nombre de skill produce dos revisiones diferentes según el directorio desde el que se inició el agente, y ningún desarrollador lo sabe.

El fallo es silencioso porque no existe un estado de error. Un skill es texto. Una instrucción obsoleta produce una respuesta segura pero incorrecta, que es el tipo de error más costoso. El agente no compara su copia con las de los demás, así que la única señal aparece cuando alguien detecta que dos repositorios no coinciden.

Problema dos: nada fija una versión

Incluso cuando un equipo mantiene las instrucciones en un único lugar, el método habitual para compartirlas es un paso de copia: un script de configuración, una línea `curl` en el documento de incorporación o un alias de shell que sincroniza una carpeta. Todos estos métodos instalan lo que haya actualmente en la parte más reciente de la rama.

Esto significa que dos desarrolladores que trabajan con el mismo commit de la misma aplicación pueden ejecutar instrucciones diferentes porque realizaron la sincronización en días distintos. También significa que no se puede responder a la pregunta importante después de una ejecución incorrecta de un agente: ¿qué versión de la skill produjo este resultado? Sin una revisión registrada, la ejecución no es reproducible y el informe del error no permite actuar.

Problema tres: nadie sabe si la skill sigue funcionando

Una skill no tiene compilador. Son instrucciones dirigidas a un modelo, por lo que puede dejar de funcionar aunque el archivo siga siendo idéntico byte por byte. Una actualización del modelo cambia el grado de fidelidad con que sigue una instrucción larga. Una herramienta de línea de comandos que usa la skill cambia el nombre de una opción. Una URL de un archivo de referencia empieza a devolver 404 y el agente trabaja a partir de la página de error.

Ninguno de esos casos produce un fallo evidente. El agente sigue respondiendo. La respuesta simplemente es peor que el mes pasado, y eso es difícil de detectar cuando se revisa una solicitud de extracción cada vez.

Qué resuelven las herramientas disponibles en 2026

Ya están apareciendo varias respuestas, pero no coinciden en dónde debe residir la versión.

Archivos de bloqueo. La herramienta de línea de comandos skills de Vercel Labs (vercel-labs/skills, con licencia MIT y en la versión v1.7.2 a fecha de 9 de octubre de 2026) instala skills desde un repositorio git en el directorio que espere el agente y conoce la estructura de más de setenta agentes. npx skills add <repo> instala, npx skills update actualiza y npx skills list muestra lo que hay instalado. Mantiene dos archivos de bloqueo. Uno global, en ~/.agents/.skill-lock.json, registra lo que ha instalado un usuario. Desde v1.4.1 (20 de febrero de 2026), la instalación con alcance de proyecto también escribe skills-lock.json en la raíz del proyecto, y el código fuente de la herramienta indica que ese archivo debe incluirse en el control de versiones. npx skills experimental_install restaura las skills de un proyecto a partir de ese archivo. El issue 283, que solicitaba un comando skills install para restaurar el archivo de bloqueo global en otra máquina, se cerró como no planificado el 5 de noviembre de 2026; el mantenedor lo identifica como la misma solicitud que el issue 549. Ambos deben interpretarse como un informe de estado. El archivo de bloqueo por proyecto existe. El comando que restaura a partir de él sigue marcado como experimental en la versión publicada v1.7.6; la rama principal del proyecto también admite ahora npx skills install sin indicar un origen para restaurar el archivo de bloqueo del proyecto.

Especificaciones y pruebas. SkillSpec adopta el enfoque contrario. Trata una SKILL.md como un contrato que debe comprobarse, no como texto en el que se deba confiar, con el objetivo declarado de hacer que las skills sean «seguibles, comprobables y demostrables». skillspec doctor <path> informa de dónde es probable que un agente pierda el hilo. skillspec boundary map <path> muestra el contenido de la skill y skillspec boundary assess <path> informa de aquello a lo que puede acceder, ordenado por riesgo. Es un crate de Rust con licencia dual MIT o Apache 2.0. La versión 0.2.2 se publicó el 29 de julio de 2026 y sigue siendo la más reciente en crates.io a fecha de 10 de octubre de 2026. Instale la versión fijada en lugar de la más reciente:

cargo install skillspec --version 0.2.2 --locked
skillspec --version

--locked compila con las versiones de las dependencias con las que se publicó el crate, por lo que la compilación no cambia sin que lo advierta. skillspec --version debería mostrar 0.2.2. Un número diferente indica que se está ejecutando un binario más antiguo situado antes en PATH.

Prácticas del proveedor. Google describió cómo compila las skills de google/skills en una publicación sobre cómo compila, prueba y escala las skills de los agentes. Si se deja de lado la escala, el mecanismo es la integración continua (CI) habitual. Cada skill pasa comprobaciones de lint para los metadatos de frontmatter, el número de líneas, la estructura de directorios y los nombres antes de integrarse. Un comprobador de enlaces hace fallar la compilación si alguna URL devuelve 404, lo que detecta el enlace plausible que un agente haya inventado. Los autores deben proporcionar, junto con la skill, un conjunto de prompts de evaluación y una rúbrica de puntuación. Después, trabajos de evaluación programados se ejecutan semanalmente contra toda la biblioteca para detectar regresiones, y cada skill tiene un responsable asignado que debe corregirla cuando baja su calidad.

El patrón común a las tres respuestas

No tiene que elegir una de ellas. Debajo de todas hay una única estructura, y git sin extensiones le proporciona todo lo necesario.

1. Una única fuente de verdad. La skill tiene exactamente una ubicación, y cada repositorio hace referencia a ella en lugar de guardar una copia.
2. Una versión fijada por repositorio. Cada proyecto registra la revisión exacta que utiliza, de modo que actualizarla consiste en hacer un commit en ese proyecto, con autor y fecha.
3. Una prueba de humo por skill. Una comprobación ejecutable demuestra que la skill sigue produciendo el resultado que promete.
4. Un proceso de revisión. Los cambios en una skill compartida pasan por revisión, y cada consumidor ve un diff antes de incorporarlos.

Esa es la estructura de una dependencia. Las skills se convirtieron en artefactos compartidos más rápido de lo que evolucionaron las herramientas para gestionarlas, por lo que recurrir a las herramientas en las que ya confía es la opción más segura.

Diseño para un equipo pequeño con un remoto Git autohospedado

Un repositorio contiene las habilidades. No contiene nada más, por lo que su historial funciona como un registro de cambios de las instrucciones.

agent-skills/
  skills/
    api-review/
      SKILL.md
    release-notes/
      SKILL.md
  tests/
    api-review.sh
    release-notes.sh
  CHANGELOG.md

Las versiones son etiquetas. Use etiquetas anotadas porque incluyen un mensaje y una fecha. Escriba el mensaje como el motivo por el que un consumidor querría actualizar la versión:

git tag -a v1.4.0 -m "api-review: require pagination on list endpoints"
git push origin v1.4.0

Si el remoto es Gitea, Forgejo, GitLab o un repositorio bare mediante SSH en su propio VPS, nada de lo siguiente cambia. Todo se basa en git y un enlace simbólico.

Anclar con un submódulo de git

Un submódulo registra un commit exacto de otro repositorio dentro del repositorio actual. Ese registro es el anclaje. En cada proyecto consumidor:

git submodule add https://git.example.com/team/agent-skills.git vendor/agent-skills
git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills checkout v1.4.0
mkdir -p .claude/skills
ln -s ../../vendor/agent-skills/skills/api-review .claude/skills/api-review
git add .gitmodules vendor/agent-skills .claude/skills/api-review
git commit -m "Pin shared agent skills to v1.4.0"

El enlace simbólico es lo que hace posible este mecanismo. Una entrada de skill en el nivel del proyecto puede ser un enlace simbólico a un directorio ubicado en otra ruta del disco, y Claude Code lo sigue y lee SKILL.md desde el destino. Así, la skill se carga como una skill normal del proyecto, mientras que los archivos se almacenan en el submódulo, en el commit que haya elegido.

Compruebe el anclaje:

git submodule status

Una línea correcta empieza con un espacio, continúa con el commit, la ruta y la etiqueta más cercana:

 4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602 vendor/agent-skills (v1.4.0)

Un - inicial indica que el submódulo nunca se ha inicializado, por lo que .claude/skills/api-review no apunta a nada y la skill no se carga sin mostrar errores. Corríjalo con git submodule update --init. Un + inicial indica que el commit extraído no coincide con el registrado, por lo que ese desarrollador está ejecutando instrucciones que nadie más tiene. Los clones nuevos necesitan git clone --recurse-submodules, y esa línea debe aparecer en el README, porque un clon normal deja vendor/agent-skills vacío y no muestra ningún error.

La actualización es deliberada, que es precisamente el objetivo:

git -C vendor/agent-skills fetch --tags
git -C vendor/agent-skills diff v1.4.0 v1.5.0 -- skills/
git -C vendor/agent-skills checkout v1.5.0
git add vendor/agent-skills
git commit -m "Bump shared agent skills to v1.5.0"

La línea diff es la ruta de revisión. Muestra el mismo cambio que verá cualquier otro repositorio consumidor y puede incluirse en una pull request.

En lugar de fijar la versión con un marketplace de plugins

Si prefiere no pedir a cada desarrollador que aprenda a usar submódulos, el sistema de plugins de Claude Code se encarga de la distribución y funciona con un remoto autohospedado. Coloque un catálogo en .claude-plugin/marketplace.json dentro del repositorio de skills:

{
  "name": "acme-agents",
  "owner": { "name": "Platform team", "email": "platform@example.com" },
  "plugins": [
    {
      "name": "team-skills",
      "description": "Shared review and release skills",
      "version": "1.4.0",
      "source": {
        "source": "url",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0",
        "sha": "4d1a7c2f0b93e5a1c8d6f2b40e7a95c3d1f8b602"
      }
    }
  ]
}

Aquí intervienen dos fuentes distintas, y confundirlas es el error habitual. La fuente del marketplace, es decir, el lugar desde el que se obtiene el catálogo, acepta ref para una rama o una etiqueta y no acepta sha. Una fuente de plugin dentro del catálogo acepta ambas opciones y, cuando se especifican las dos, sha es la fijación efectiva. Por tanto, la fijación al commit exacto debe estar en la entrada del catálogo. Los nombres de tipo también son distintos. Dentro del catálogo, url significa un repositorio git que se debe clonar. En una fuente de marketplace, url significa un enlace directo a un archivo marketplace.json, mientras que un repositorio git se especifica con git.

Cada repositorio consumidor declara después el marketplace en su .claude/settings.json versionado:

{
  "extraKnownMarketplaces": {
    "acme-agents": {
      "source": {
        "source": "git",
        "url": "https://git.example.com/team/agent-skills.git",
        "ref": "v1.4.0"
      }
    }
  },
  "enabledPlugins": {
    "team-skills@acme-agents": true
  }
}

Claude Code registra el marketplace para un miembro del equipo cuando este acepta el diálogo de confianza del espacio de trabajo para la carpeta del proyecto, sin que una página de la wiki tenga que indicarle cómo hacerlo. La entrada del catálogo apunta a una URL git en lugar de a una ruta relativa, por lo que el plugin no se instala únicamente desde la configuración del repositorio. Cada miembro del equipo ejecuta claude plugin install team-skills@acme-agents --scope project una vez. Hasta entonces, Claude Code informa de que el plugin está habilitado en la configuración del proyecto, pero no está instalado. Las skills responden entonces a /team-skills:api-review, porque las skills de los plugins usan el espacio de nombres del nombre del plugin y no pueden entrar en conflicto con una skill del proyecto que tenga el mismo nombre. Después de publicar una etiqueta nueva, los consumidores actualizan con /plugin marketplace update acme-agents y ejecutan /reload-plugins si el resumen de instalación lo solicita.

Escribir una prueba de humo para una skill

Una prueba de humo es una ejecución programada del agente contra un fixture con un fallo conocido, junto con una aserción. Claude Code se ejecuta de forma no interactiva con -p, y una skill invocada por el usuario también funciona ahí: incluya /skill-name en la cadena del prompt y se expandirá antes de iniciar la ejecución.

#!/usr/bin/env bash
set -euo pipefail

claude -p "/api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --allowedTools "Read" \
  --output-format json \
  --json-schema '{"type":"object","properties":{"rule_ids":{"type":"array","items":{"type":"string"}}},"required":["rule_ids"]}' \
  | jq -e '.structured_output.rule_ids | index("pagination-required")' > /dev/null

fixtures/orders-api.md es un archivo corto con un único fallo deliberado. La aserción comprueba que la skill lo mencione. jq -e termina con un código distinto de cero cuando su filtro produce null, por lo que una skill que deje de detectar el fallo introducido hace que el script falle. claude también termina con un código distinto de cero cuando falla la ejecución, y set -euo pipefail convierte cualquiera de los dos fallos en una prueba fallida.

Un modelo reformula sus respuestas entre ejecuciones, por lo que nunca debe comprobar una frase completa. Compruebe un identificador que la skill deba emitir o un campo de un esquema solicitado, y mantenga el fixture pequeño para que la ejecución consuma pocos recursos.

En CI, añada --bare. Sin esta opción, claude -p carga el mismo contexto que una sesión interactiva, incluidos los hooks, los plugins y CLAUDE.md de la máquina donde se ejecuta. Por tanto, la configuración personal de otro miembro del equipo puede cambiar el resultado. El modo bare omite el descubrimiento automático, excepto para las skills de .claude/skills/ situadas bajo un directorio indicado explícitamente con --add-dir. También omite la skill del proyecto que se está probando, por lo que debe cargarla de forma explícita. El modo bare tampoco lee el inicio de sesión de la suscripción, así que establezca primero ANTHROPIC_API_KEY en el entorno:

claude --bare -p "/team-skills:api-review Read fixtures/orders-api.md and list the rule ids it breaks." \
  --plugin-dir vendor/agent-skills \
  --allowedTools "Read" \
  --output-format json

Un plugin cargado con --plugin-dir toma su nombre de .claude-plugin/plugin.json. Sin ese manifiesto, recibe el nombre de su directorio. Confirme un plugin.json con "name": "team-skills" junto al catálogo del repositorio de skills. De lo contrario, el comando anterior debe llamar a /agent-skills:api-review.

Con --output-format stream-json, el evento system/init informa de qué plugins se cargaron e incluye un array plugin_errors con los que no se cargaron. El flujo se abre salvo que los eventos de inicio se emitan primero. Haga que el trabajo de CI falle si plugin_errors no está vacío. Esto detecta una referencia fijada a una revisión que ya no existe, un caso que de otro modo aparece como si el agente ignorara silenciosamente las reglas internas.

Una habilidad compartida contiene instrucciones ejecutables

Dos funciones hacen que esto sea literal, y ambas importan cuando el archivo procede de otro equipo.

Primero, una SKILL.md puede ejecutar comandos de shell antes de que el modelo lea nada. Una línea como esta en el cuerpo es un preprocesamiento:

- Current branch: !`git rev-parse --abbrev-ref HEAD`

El comando se ejecuta en la máquina que carga la habilidad, y su salida reemplaza el marcador de posición en el texto que recibe el modelo. Un bloque delimitado que comienza con tres acentos graves seguidos de ! ejecuta varios comandos de la misma forma. No se solicita confirmación para nada de esto durante la ejecución. Claude Code comprueba cada comando según las reglas de permisos. Fuera del modo automático, un comando que esas reglas no permiten cancela la habilidad, a menos que la habilidad lo autorice previamente mediante la segunda función siguiente. Las reglas de denegación y confirmación siguen teniendo prioridad sobre esa autorización previa. Leer una habilidad compartida implica leer sus sustituciones de comandos.

Segundo, el frontmatter puede autorizar herramientas previamente. allowed-tools concede las herramientas indicadas sin solicitar permiso durante el turno que invocó la habilidad. La confianza en el espacio de trabajo no limita esta concesión: Claude Code aplica allowed-tools de una habilidad del proyecto incluso durante una ejecución -p en una carpeta en la que nadie ha establecido confianza. La documentación de Claude Code indica claramente la consecuencia: una habilidad puede concederse a sí misma acceso amplio a las herramientas, por lo que debe revisar allowed-tools de las habilidades registradas en un repositorio antes de ejecutar Claude Code allí. Una organización puede impedir que las habilidades del proyecto y personales utilicen ese campo mediante allowManagedPermissionRulesOnly en la configuración administrada. Esto requiere Claude Code v2.1.282 o posterior.

Por tanto, trate la actualización de una habilidad exactamente como la actualización de una dependencia. Fije la versión mediante el commit exacto siempre que el mecanismo lo permita, porque un tag puede cambiar de destino y una rama cambia por definición. En una máquina restringida, "disableSkillShellExecution": true en la configuración reemplaza cada sustitución de comandos por el texto literal [shell command execution disabled by policy] en lugar de ejecutarla. Si se aplica mediante la configuración administrada, el usuario no puede anularlo. Las habilidades incluidas y administradas están exentas de esta configuración.

La misma precaución se aplica a lo que lee una habilidad. Una habilidad que ejecuta env o abre un archivo de configuración incorpora al contexto del modelo todo lo que encuentra. Este es el fallo descrito en mantener los secretos fuera de los agentes que ejecuta. Una habilidad que obtiene una página o ejecuta una consulta expone esa misma información hacia el exterior, porque el texto recuperado llega al contexto con el mismo aspecto que las instrucciones que escribió. Es un límite que conviene conocer antes de dirigir un agente a su propia instancia de SearXNG para búsquedas web.

Qué leer al actualizar una versión

• El diff del cuerpo de cada SKILL.md, porque ese texto contiene las instrucciones que seguirá el agente.
• Todas las sustituciones de comandos, porque se ejecutan en su máquina cuando se carga la skill.
• Cualquier cambio en allowed-tools, porque esa línea concede herramientas sin solicitar confirmación.
• La ejecución de pruebas asociada a la etiqueta. Si el repositorio compartido ejecuta sus propias pruebas básicas en CI, la etiqueta a la que fija la versión debe tener una ejecución correcta asociada.

Si un revisor no puede leer todo el diff en diez minutos, la skill ha crecido demasiado. Divídala. El mismo criterio se aplica a los documentos del repositorio que leen los agentes: mantenga las reglas duraderas en los archivos descritos en la separación entre AGENTS.md y HUMAN.md y el razonamiento arquitectónico en un DESIGN.md escrito para agentes, y mantenga las skills como procedimientos específicos.

Cuando un cambio de modelo o de herramienta rompe una skill

Varios elementos subyacentes pueden cambiar sin que nadie edite una skill. Una actualización del modelo cambia la fiabilidad con la que sigue una instrucción larga, por lo que una skill que dependía de que el modelo llegara al paso nueve puede dejar de hacerlo. Una herramienta de línea de comandos cambia el nombre de un flag, así que el agente ejecuta el flag antiguo, lee el error e improvisa. Una URL referenciada empieza a devolver 404. Un arnés de agente cambia la forma en que selecciona las skills, por lo que un description que antes ganaba la coincidencia puede dejar de hacerlo. Cuando un procedimiento empieza a terminar antes de tiempo de esa forma, ningún cambio de versión lo corrige. Las propias instrucciones necesitan una estructura que obligue a ejecutar los últimos pasos. Ese es el enfoque de la skill unlazy y su método Depth Tree.

Por eso la prueba de humo es tan importante en este esquema. Ejecute la prueba de cada skill con una periodicidad definida y también con cada push. Google ejecuta sus trabajos de evaluación semanalmente contra toda la biblioteca por este motivo. Para un equipo con diez skills, basta con un trabajo cron semanal en un VPS pequeño. Es la única forma de detectar el fallo antes que un desarrollador.

La portabilidad también ayuda. La especificación Agent Skills limita el frontmatter a seis claves, por lo que una skill escrita conforme a esa especificación se carga en herramientas distintas de aquella para la que se creó. En cambio, cada clave específica del arnés que añada es una apuesta por un proveedor. Escribir skills que sobrevivan a un cambio de modelo requiere una disciplina propia, descrita en hacer que una skill funcione con cualquier modelo.

FAQ

¿Cómo comparto una misma habilidad de agente entre varios repositorios?

Coloque la habilidad en un repositorio git dedicado, etiquete sus versiones y haga que cada proyecto consumidor haga referencia a una etiqueta en lugar de copiar el archivo. Hay dos mecanismos. Un submódulo git registra un commit exacto, y un enlace simbólico desde .claude/skills/<name> al submódulo hace que se cargue como una habilidad normal del proyecto. Un marketplace de plugins hace lo mismo mediante /plugin, con la versión fijada declarada en .claude/settings.json del repositorio consumidor. Ambos almacenan la versión en el historial de git, por lo que puede determinar qué instrucciones produjeron una ejecución concreta del agente.

¿Puedo fijar una habilidad de agente a una versión específica?

No desde SKILL.md, porque ese frontmatter no tiene ninguna clave version. La versión debe fijarse en la capa que rodea al archivo. Un submódulo git fija un commit exacto por diseño. En un marketplace de plugins de Claude Code, una fuente de plugin acepta ref para una rama o etiqueta y sha para un commit exacto; si ambos están presentes, prevalece sha. La fuente del marketplace sólo acepta ref. Prefiera fijar el commit, porque una etiqueta puede cambiar después de haberla revisado.

¿Qué debe comprobar una prueba rápida de una habilidad?

Compruebe algo estable. Ejecute la habilidad de forma no interactiva contra un fixture que contenga un fallo conocido y verifique que aparezca un identificador específico en la salida, por ejemplo, el identificador de una regla que la habilidad deba notificar. Solicitar una salida estructurada con --output-format json y --json-schema hace que la comprobación sea exacta, y jq -e hace que el script falle si falta el valor. Nunca compruebe una frase completa, porque un modelo reformula sus respuestas entre ejecuciones.

¿Es seguro instalar una habilidad compartida desde el repositorio de otro equipo?

Trátela como una dependencia de código, porque es una instrucción ejecutable. Un SKILL.md puede ejecutar comandos de shell al cargarse mediante la forma de sustitución de comandos !, y el campo de frontmatter allowed-tools puede autorizar herramientas previamente sin mostrar una solicitud. Revise el diff en cada actualización, fije un commit exacto en lugar de una rama y prefiera una fuente controlada por su propio equipo. En máquinas administradas, "disableSkillShellExecution": true en la configuración impide que se ejecuten sustituciones de comandos en habilidades de usuario, proyecto, plugin y directorios adicionales; las habilidades incluidas y administradas están exentas.

¿Funcionará una habilidad compartida en agentes distintos de Claude Code?

Depende del frontmatter que utilice. La especificación Agent Skills define seis claves: name, description, license, compatibility, metadata y allowed-tools. Una habilidad limitada a esas claves se carga en las herramientas que implementan la especificación, y también se carga en Claude Code sin cambios. Las claves específicas del entorno de ejecución y las funciones del cuerpo que no forman parte de la especificación se ignoran o se rechazan en otros entornos. Por tanto, no las incluya en una habilidad que pretenda compartir ampliamente.