Skip to main content

Publicación

La publicación envía una carpeta de skill o un paquete de plugin a ClawHub bajo el propietario que se elija. ClawHub comprueba que el token pueda publicar para ese propietario, valida los metadatos, el nombre, la versión, los archivos y la información del código fuente; después, almacena la versión e inicia comprobaciones de seguridad automatizadas. Si la validación falla, no se publica nada. Las versiones nuevas también pueden quedar fuera de las superficies normales de instalación y descarga hasta que finalice la revisión.

Skills

La vía de publicación más sencilla es la CLI. Inicie sesión y, después, publique una carpeta de skill local:
Use --owner <handle> al publicar para una organización propietaria. Omítalo para publicar como el usuario autenticado. La publicación omite el contenido que no haya cambiado. Una skill nueva comienza en 1.0.0, y los cambios posteriores publican automáticamente la siguiente versión de parche. Pase --version solo cuando necesite una versión explícita. Para repositorios de catálogo, use el flujo de trabajo skill-publish.yml reutilizable de ClawHub. Este llama a skill publish para cada carpeta de skill inmediata en root (valor predeterminado: skills), o solo para la carpeta proporcionada como skill_path.
Use dry_run: true para obtener una vista previa de las skills nuevas y modificadas sin publicarlas.

Plugins

Los plugins usan nombres de paquete al estilo de npm. Los nombres de paquete con ámbito incluyen al propietario en la primera parte del nombre:
El ámbito debe coincidir con el propietario seleccionado para la publicación. Si el paquete se llama @openclaw/dronzer, solo puede publicarse como @openclaw. Si se publica como @vintageayu, cambie el nombre del paquete a @vintageayu/dronzer. Esto impide que un paquete se apropie del espacio de nombres de una organización que el publicador no controla. Si es el propietario legítimo de una organización, marca, ámbito de paquete, identificador de propietario o espacio de nombres que ya esté reclamado o reservado en ClawHub, abra una incidencia de reclamación de organización o espacio de nombres con pruebas públicas y no confidenciales. Consulte Reclamaciones de organizaciones y espacios de nombres para saber qué incluir y qué debe mantenerse fuera de las incidencias públicas.

Antes de publicar un plugin

  • Elija un propietario que coincida con el ámbito del paquete.
  • Incluya openclaw.plugin.json. Los plugins de código también necesitan package.json con openclaw.compat.pluginApi y openclaw.build.openclawVersion.
  • Para mostrar un icono de catálogo personalizado para el plugin en la página de inicio y en las páginas de lista de plugins, añada icon a openclaw.plugin.json con cualquier URL de imagen HTTPS.
  • Incluya el repositorio de origen y los metadatos exactos del commit, o use la CLI desde un checkout respaldado por GitHub para que pueda detectarlos.
  • Ejecute clawhub package validate <source> antes de publicar. Para problemas del paquete, manifiesto, importación del SDK o artefacto, consulte Correcciones de validación de plugins.
  • Ejecute clawhub package publish <source> --dry-run antes de crear una versión.
  • Tenga en cuenta que las versiones nuevas permanecerán fuera de las superficies públicas de instalación hasta que finalicen las comprobaciones de seguridad automatizadas y la verificación.

Publicación de confianza para paquetes

La publicación de confianza de paquetes se configura en dos pasos:
  1. Publique el paquete una vez mediante clawhub package publish normal, ya sea manual o autenticado mediante token. Esto crea el registro del paquete y establece los administradores del paquete que pueden cambiar su configuración de publicador de confianza.
  2. Un administrador del paquete establece la configuración del publicador de confianza de GitHub Actions:
Una vez establecida la configuración, las futuras publicaciones compatibles de GitHub Actions pueden usar OIDC/publicación de confianza sin almacenar un token de ClawHub de larga duración en el repositorio. El repositorio y el nombre de archivo del flujo de trabajo configurados deben coincidir con la declaración OIDC de GitHub Actions. Si también se pasa --environment <name>, la declaración de entorno de GitHub Actions debe coincidir exactamente con ese nombre. ClawHub verifica el repositorio de GitHub configurado cuando se establece la configuración del publicador de confianza. Los repositorios públicos pueden verificarse mediante metadatos públicos de GitHub. Los repositorios privados requieren que ClawHub tenga acceso de GitHub a ese repositorio, por ejemplo, mediante una futura instalación de la aplicación de GitHub de ClawHub u otra integración autorizada con GitHub. El flujo de trabajo reutilizable actual para publicar paquetes admite la publicación de confianza sin secretos para publicaciones de workflow_dispatch cuando id-token: write está disponible. Las publicaciones reales mediante envío de etiquetas siguen necesitando clawhub_token, por lo que se debe mantener CLAWHUB_TOKEN disponible para versiones con etiqueta, primeras publicaciones, paquetes no confiables o publicaciones de emergencia. Inspeccione o elimine la configuración con:
Eliminar la configuración del publicador de confianza es la vía de reversión. Desactiva la futura emisión de tokens de publicación de confianza hasta que un administrador del paquete vuelva a establecer la configuración.

Preguntas frecuentes

El ámbito del paquete debe coincidir con el propietario seleccionado

Si el ámbito del paquete y el propietario seleccionado no coinciden, ClawHub rechaza la publicación:
Para corregirlo, elija el propietario indicado por el ámbito del paquete o cambie el nombre del paquete para que el ámbito coincida con el propietario con el que puede publicar. Si el nombre del paquete ya tiene el ámbito correcto, pero el paquete pertenece al publicador equivocado, transfiera la propiedad:
Use la transferencia de paquetes o skills solo cuando tenga acceso de administrador tanto al propietario actual como al publicador de destino. La transferencia de paquetes no permite publicar en un ámbito que no pueda administrar. Si no tiene acceso al propietario actual, pero considera que su organización, proyecto o marca es el propietario legítimo del espacio de nombres, abra una incidencia de reclamación de organización o espacio de nombres con pruebas públicas y no confidenciales para que el personal la revise. Consulte Reclamaciones de organizaciones y espacios de nombres antes de presentarla. Esto protege los espacios de nombres de las organizaciones. Un paquete llamado @openclaw/dronzer reclama el espacio de nombres @openclaw, por lo que solo los publicadores con acceso al propietario @openclaw pueden publicarlo.