Saltar al contenido principal
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.
ModoFuente del diff¿Incluye archivos?Cuándo usar
Árbol de trabajo (predeterminado)Cambios no confirmados en tu directorio de trabajoSíEn medio del desarrollo, antes de preparar nada.
Preparado (--staged)git diff --cachedSíA punto de confirmar — mismo ámbito que git commit.
Rama (--branch <base>)Diff confirmado de base..HEADNoRevisión previa a la fusión de toda la rama.
Commit (--commit <sha>)El diff introducido por un solo commitNoAuditar un commit, revisión de cherry-pick.
¿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. 
Regla
├── title          "No console.log en código de producción"
├── rule           "Evitar dejar console.log en el código confirmado"
├── severity       low | medium | high | critical
├── scope          file | pull request
├── path           **/*.ts       (glob para selección de archivos)
└── repo-id        <uuid> | global
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 list                 # Ver tus repos configurados
kodus config repo show                 # Ver la configuración del repo actual
kodus config repo setup                # Asistente guiado
kodus config repo set . reviewEnabled true
kodus config repo add-ignore-file . "**/*.generated.ts"
kodus config repo open                 # Ir al panel web
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: 
kodus config centralized status
kodus config centralized init owner/config-repo --sync-option pr
kodus config centralized sync
kodus config centralized disable
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.

​
Decision Memory

Decision Memory es la forma en que Kodus persiste el razonamiento detrás del trabajo de los agentes de IA, no solo el diff, sino el “por qué”. Cuando está habilitado, Kodus instala hooks en Claude Code, Cursor o Codex que se activan en cada evento de turno completado y capturan decisiones estructuradas en: 
.kody/
├── pr/by-sha/<head-sha>.md    # Decisiones a nivel de PR (versionadas con el código)
├── memory/<module-id>.md      # Decisiones a nivel de módulo (largo plazo)
└── modules.yml                # Configuración de módulos
La memoria a nivel de PR vive en la rama. Cuando se fusiona un PR, promueve sus decisiones a la memoria de nivel de módulo (kodus decisions promote) para que el trabajo futuro en ese módulo comience con el contexto acumulado. Guía completa: Decision Memory.

​
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. 
kodus pr business-validation --task-id KC-1441 --branch main
kodus pr business-validation --task-url https://linear.app/… --staged
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.

Decision Memory

Captura y promueve decisiones de agentes entre ramas.

Solución de Problemas

Errores comunes y códigos de salida.