Skip to main content
Un breve recorrido por las ideas que aparecen en todo el CLI. Léelo una vez y el resto de la documentación tendrá más sentido.

​
Modos de Diff

Cada revisión necesita responder una pregunta: ¿qué cambió? El CLI admite cuatro modos de diff, cada uno con una fuente de verdad diferente.
¿Por qué importa incluir los archivos? Las revisiones del árbol de trabajo y las preparadas envían el contenido del archivo junto con el diff porque el backend no puede ver tu trabajo no confirmado. Los modos de rama y commit omiten la inclusión: el backend clona el mismo commit directamente. Por eso las revisiones de rama/commit funcionan en diffs enormes donde las revisiones del árbol de trabajo superarían los límites de tamaño de solicitud.

​
Modos de Revisión

Tres estilos de salida, la misma revisión subyacente.
  • Interactivo (predeterminado) — una TUI que lista archivos, expande problemas y aplica correcciones de una en una con una vista previa. La forma natural de trabajar en un terminal.
  • Corrección automática (--fix) — aplica todos los problemas corregibles a la vez con una sola confirmación. Úsalo cuando confíes en las reglas y quieras aplicarlas en lote.
  • Solo prompt (--prompt-only) — texto mínimo y estructurado diseñado para que los agentes de IA lo analicen y actúen sobre él. Combínalo con --fail-on en un bucle de agente para que el bucle termine limpiamente cuando la revisión esté limpia.
También puedes usar --format json o --format markdown con cualquier comando para consumidores no interactivos (CI, scripts, webhooks).

​
Modos de Autenticación

Elige uno por máquina. El CLI detecta automáticamente lo que está disponible.
  • Prueba — sin autenticación. 5 revisiones por día. Bueno para “probarlo una vez”.
  • Inicio de sesión personal (kodus auth login) — una cuenta individual. Los tokens se actualizan automáticamente.
  • Clave de equipo (kodus auth team-key --key kodus_xxxxx) — una clave compartida para un equipo, generada en el panel. Recomendada para agentes de IA y en cualquier lugar donde no quieras inicios de sesión interactivos.
  • Token de CI/CD (kodus auth token) — un token de larga duración para pipelines. Generado desde una máquina con sesión iniciada, usado mediante KODUS_TOKEN.
Consulta Primeros Pasos para el árbol de decisiones completo.

​
Kody Rules

Una Kody Rule es una regla estructurada que el revisor de Kodus aplica en cada revisión, con ámbito a un repositorio o global para tu equipo.
Las reglas se añaden sobre la revisión general de Kodus: la IA las usa como criterios adicionales, no como sustitutos. Gestiona las reglas desde el panel o desde el CLI con kodus rules create|update|view. El CLI es útil cuando quieres reglas bajo control de versiones (generarlas desde un script, incorporarlas a un repo, reaplicarlas en el aprovisionamiento).

​
Configuración del Repositorio

Cada repositorio en Kodus tiene configuraciones que rigen cómo se comportan las revisiones: archivos ignorados, patrones de ramas base, filtros de títulos, activadores de funciones. Estas viven en el backend de Kodus y se reflejan en cualquier lugar donde se revise el repo (PRs web, revisiones del CLI, bucles de agentes). Desde el CLI:
kodus config repo y kodus config remote son alias del mismo grupo de comandos.

​
Configuración Centralizada

Normalmente, la configuración de cada repositorio vive en Kodus. La Configuración Centralizada permite a un equipo almacenar esas configuraciones en un único repositorio git como fuente de verdad: cada cambio se convierte en un pull request contra ese repo, dándote revisión e historial de versiones sobre tu propia configuración de revisión. Habilitar, sincronizar o inspeccionar el estado:
Usa la Configuración Centralizada cuando tu equipo quiera un control auditable y versionado sobre la configuración de revisiones. Mantén el predeterminado (configuración por repositorio en Kodus) cuando esa ceremonia sea excesiva.

​
Validación de Negocio

Donde kodus review pregunta “¿es bueno este código?”, kodus pr business-validation pregunta “¿este diff realmente hace lo que decía la tarea?”. Lo apuntas a una tarea de Linear/Jira/URL y a una fuente de diff (árbol de trabajo, preparado, rama, commit) y verifica la implementación contra los criterios de aceptación de la tarea.
Combínalo con una verificación previa a la fusión para detectar “el código funciona, pero no es lo que se pidió” antes de la revisión humana.

​
Salida para Agentes de IA (--prompt-only y --agent)

Dos flags relacionados, trabajos diferentes.
  • --prompt-only — la salida está optimizada para que un agente de IA la analice y actúe sobre ella. Solo funciona en comandos que producen salida de tipo revisión (review, pr suggestions).
  • --agent — flag global que aplica salida determinista y legible por máquina en cualquier comando. Úsalo cuando un script o agente analice la salida del CLI; combínalo con --format json para mayor rigor.
La mayoría de las integraciones de agentes solo necesitan --prompt-only. Recurre a --agent cuando estés orquestando el CLI desde un arnés o un bucle de llamadas a herramientas con expectativas de formato estrictas.

​
Próximos pasos

Referencia de Comandos

Listado completo de comandos y flags.

Agentes de IA

Construye bucles de revisión y corrección con agentes de programación.

Solución de Problemas

Errores comunes y códigos de salida.