Saltar al contenido principal
Los agentes personalizados están en beta. El comportamiento y las pantallas aún pueden cambiar.

​
Skills & docs

Las skills y los docs son guías que ya viven en tu repositorio. Kodus no las copia: las lee de la rama de destino del pull request en cada revisión. Así, los cambios en esa rama aplican sin volver a la configuración, y un pull request no puede cambiar la regla que lo evalúa. Una guía también puede venir de otro repositorio, como un repositorio de reglas compartido (consulta Desde otro repositorio más abajo). Los scripts dentro de una skill se muestran al agente como texto y nunca se ejecutan.

​
Dónde las encuentra Kodus

Las skills se detectan en:
  • .claude/skills/*/SKILL.md
  • .claude/agents/*.md
  • .agents/skills/*/SKILL.md
  • .github/skills/*/SKILL.md
Un SKILL.md empieza con un frontmatter YAML con name (letras minúsculas, dígitos y guiones, igual al nombre de su carpeta) y description. Una skill sin ellos aparece como “Not a valid skill”, con el motivo. El agente lee SKILL.md (hasta 500 líneas, unos 5.000 tokens) y los archivos junto a él, hasta una carpeta por debajo, como references/payments.md.
.claude/skills/ledger-rules/SKILL.md
Los docs se sugieren a partir de CONTRIBUTING.md, ARCHITECTURE.md, CONVENTIONS.md, STYLEGUIDE.md y docs/**/*.md (hasta 30). También puedes agregar cualquier ruta a mano: un archivo con extensión es un doc; una carpeta (o un SKILL.md dentro de una) es una skill.

​
Vincularlas

Hay dos lugares para vincular una skill o un doc:
  • En la página del agente, en Files & knowledge → Skills & docs: Add skill or doc lista lo que el agente puede seguir, o usa Add by path.
  • En la página Skills & docs (el enlace junto a Custom agents en What to review): todas las skills y docs registradas, con una casilla para Main review y para cada agente. Vincular a Main review le da la guía a la revisión propia de Kody.
En el nivel global, la página Skills & docs solo acepta rutas escritas a mano. Cada repositorio se lee por separado; abre la configuración de un repositorio para ver si cada ruta existe ahí.

​
Citados por hallazgos descartados

Cuando las revisiones descartan hallazgos porque citan un archivo que el agente no sigue (“is not a guide linked to this review”), Skills & docs del agente muestra ese archivo en Cited by dropped findings, con cuántos hallazgos se descartaron. Follow lo vincula, desde este repositorio o desde el repositorio donde está. Solo se ofrecen archivos que existen.

​
Desde otro repositorio

Es común que un equipo mantenga sus reglas en un repositorio y las aplique en varios. Elígelo en From al añadir un skill o doc en la página de un agente: primero aparecen los repositorios vinculados, y Other repository… lista todos los repositorios conectados a Kodus (seleccionados en Git settings). Si el repositorio de reglas no aparece, conéctalo ahí primero.
  • Una guía de otro repositorio se lee en la rama por defecto de ese repositorio, o en la rama o tag que definas con Use a branch or tag instead. Una rama o tag por repositorio. Un pull request nunca lo cambia.
  • Es solo para custom agents. La revisión principal lee las guías del repositorio revisado y sus instrucciones de agentes de código, no las de otro repositorio, por eso la página Skills & docs no ofrece Main review para ella.
  • Se carga como una guía del repositorio revisado, en cada review, sin sandbox y aunque el cambio no toque el otro repositorio.
  • El agente la cita como owner/repo:ruta, y el comentario enlaza el archivo.
  • Cuando el repositorio de reglas es privado y el revisado es público, el comentario nombra el archivo sin citar el texto.
Cuando las instrucciones de un agente nombran un repositorio vinculado del que no sigue nada, su página lo indica y ofrece Browse its rules. Cuando nombran un archivo de reglas (.md, .mdc, .mdx) que el agente no sigue, la página ofrece Follow it para ese archivo, en el repositorio donde las instrucciones lo ubican. Un doc seguido entra completo en el prompt del agente: ya no depende de que decida leerlo, y sus findings pueden citarlo.
Un archivo marcado como Also a Kody Rules source ya alimenta las Kody Rules. Vincularlo también a un agente puede hacer que la misma regla comente dos veces.

​
Presupuestos

Por agente, y para la revisión principal: La página Skills & docs avisa cuando un agente o la revisión principal supera un límite. En una revisión, los docs que exceden el presupuesto se recortan u omiten, y la revisión registra un aviso.

​
Cómo las usan los hallazgos

Un hallazgo de convención debe citar la regla que aplica. Kodus verifica la cita en la guía tal como está en la rama de destino y descarta el hallazgo cuando la cita no está. El comentario publicado cita la regla:
Una regla de otro repositorio se cita como owner/repo:ruta, con un enlace al archivo en la rama de la que se leyó.

​
Plugins (MCP)

Los agentes pueden consultar los plugins instalados en tu workspace: un gestor de tareas, una wiki, el monitoreo. En Tools → Plugins, activa un plugin para el agente y mantén Use every tool, o usa Customize para elegir la lista. Solo se ofrecen herramientas de lectura; las de escritura nunca. Un plugin que marca sus herramientas como de solo lectura se toma al pie de la letra. Para uno que no las marca, una herramienta solo califica cuando su nombre lleva un verbo de lectura (get, list, search, read, find…) y ningún verbo de escritura. Una revisión nunca crea un ticket ni publica un mensaje en nombre de tu equipo. El agente consulta un plugin cuando el cambio apunta a algo registrado ahí, como un ticket en la descripción del pull request, y cita lo que encontró. Consulta Plugins para instalar uno.

​
CLIs del equipo

Un agente puede ejecutar hasta 3 herramientas de línea de comandos de tu equipo: un detector de código duplicado, un verificador de esquemas, un linter interno. Las CLIs solo se ejecutan en el sandbox aislado de E2B, dentro del checkout del repositorio. En cualquier otro sandbox la CLI no se instala y el agente se ejecuta sin ella. En Tools → CLIs, haz clic en Add CLI: Reglas de instalación. Instaladores admitidos: npm, pnpm, yarn, pip, pip3, pipx, uv, go, cargo. Todo paquete debe estar fijado (tool@1.2.3, tool==1.2.3 o tool@sha256:…). Se rechazan etiquetas como @latest, rangos de versión, URLs, fuentes Git, rutas locales y sintaxis de shell.
Cómo se ejecutan las llamadas. El agente pasa argumentos, nunca un comando de shell: pipes, redirecciones, globs y variables se pasan literalmente. Una llamada que no empieza con un prefijo permitido se rechaza. Cada CLI se ejecuta con su propio usuario, con timeout, un directorio temporal privado y archivos legibles solo por ese usuario; su salida está limitada, y todo lo que inició o escribió en directorios temporales se elimina después de la llamada. Cada paso de una CLI se ejecuta como root a través del proveedor del sandbox, nunca a través del usuario con el que corre la revisión: ese usuario pierde toda forma de convertirse en root (sudo incluido) antes de descargar el repositorio, así que el código del pull request no alcanza el proceso ni los archivos de una CLI. Un sandbox en el que eso no pudo confirmarse no ejecuta ninguna CLI. Comandos bloqueados. En una CLI con secretos, Kodus rechaza, al guardar y al ejecutar, prefijos y argumentos que listan el entorno (printenv, env, set, export, declare, cualquier cosa bajo /proc), comandos comunes que imprimen tokens (auth token, auth status --show-token, auth:token, config get, configure get, print-access-token, get-access-token), un shell o intérprete como binario (bash, node, python, npx, …) y argumentos que nombran uno de sus secretos como $NOMBRE o ${NOMBRE}. Los argumentos nunca pasan por un shell, así que Kodus nunca los expande. Red. La allowlist se aplica por nombre de host. Las conexiones HTTPS de la CLI pasan por un proxy que solo reenvía una conexión cuando el nombre de servidor pedido está en la lista (nombre exacto, sin subdominios) y que resuelve ese nombre por su cuenta, rechazando direcciones privadas e internas. La CLI no tiene otro acceso a la red: ni DNS, ni HTTP sin TLS, ni otros puertos. Un host permitido sigue recibiendo lo que la CLI le envíe, credenciales incluidas, y la red no distingue una lectura de una escritura. Usa tokens de solo lectura y con el menor privilegio posible, y permite solo hosts de confianza. Cómo se guardan los secretos. Un secreto se cifra al guardarse (AES-256-GCM, vinculado a su agente, su CLI y el nombre de la variable) y nunca vuelve al navegador, que muestra Stored · hidden. Queda vinculado a la CLI para la que se guardó, en ese nivel de configuración: cualquier cambio en la CLI (nombre, instalación, binario, prefijos permitidos, dominios permitidos, Runs project code o los nombres de sus secretos) vuelve a pedir todos sus secretos, al guardar y en Try it. Solo las notas de uso y el timeout cambian sin eso. Un secreto guardado que ya no puede leerse también hay que escribirlo de nuevo. Try it usa solo los secretos guardados en el nivel que estás editando, nunca los heredados. Un secreto llega solo al proceso de esa CLI, nunca a su instalación, a las otras CLIs ni al prompt del agente. En la salida de la CLI, cada secreto se reemplaza por ***, también cuando se imprime en base64, codificado en URL, en hex o escapado en JSON, antes de que lo vean el agente, Try it, un comentario del pull request o un log. El enmascarado no reconoce toda transformación (un valor partido o parcial), y por eso se bloquean los comandos anteriores. Cuando un hallazgo viene de una CLI, el comentario muestra las líneas de salida de la CLI que nombran el archivo:
Si la instalación falla, el agente se ejecuta sin esa CLI y la ejecución registra el aviso. Try it lo muestra en Warnings.

​
Reglas de ast-grep

En Tools → Advanced → Structural search (ast-grep rules), dale al agente reglas de ast-grep, de una de estas formas:
  • Inline: el YAML de la regla. Separa varias reglas con ---. Cada una necesita un id y una rule.
  • Un archivo de reglas: una sola línea con la ruta de un archivo .yml o .yaml del repositorio, leído de la rama de destino del pull request.
Las reglas se ejecutan sobre los archivos cambiados del pull request. Una coincidencia es prueba: un hallazgo que cita una regla que coincidió en ese archivo durante la ejecución omite la verificación de la cita y la verificación del modelo. Las reglas tienen un límite de 64.000 bytes. La ayuda del campo lista las reglas que encontró y reporta las reglas sin id o sin rule. El agente también tiene búsqueda estructural libre en el repositorio, sin ninguna regla configurada.

​
Relacionado

Agentes Personalizados

Niveles, la página del agente, Try it y cómo se ejecutan los agentes en una revisión.

Código duplicado con jscpd

Un agente completo con una CLI del equipo.