Saltar al contenido principal
Una directiva de revisión te permite indicarle a Kody dónde concentrar su análisis más profundo en una revisión concreta. En lugar de cambiar la configuración, adjuntas una instrucción breve al lanzar la revisión — por ejemplo, “enfócate en la lógica de auth y sesión” — y Kody dedica su análisis más riguroso al código modificado que coincide.
Una directiva es efímera: se aplica solo a esa ejecución de revisión. No se guarda en tu configuración ni afecta a revisiones futuras. Para cambiar el comportamiento de Kody de forma permanente, usa las instrucciones por categoría y la personalidad de Kody (Instructions & Personality, antes Custom Prompts) o Kody Rules.

​
Cuándo Usarla

  • Un PR toca muchos archivos pero te importa más un área de riesgo (auth, pagos, una migración).
  • Quieres que Kody rastree los callers y callees de un cambio específico y lo cuestione con más rigor.
  • Estás relanzando una revisión y quieres dirigir la atención sin editar ninguna configuración.

​
Prioridad, No Filtro

Esto es lo más importante de entender:
Una directiva establece prioridad, no un filtro. Kody prioriza el área de enfoque, pero sigue reportando cualquier bug, problema de seguridad o de rendimiento concreto que detecte en otras partes del diff. Nunca suprime hallazgos fuera del enfoque ni aprueba el resto del PR sin revisarlo.
Usa una directiva para decir “mira aquí con más atención” — no “mira solo aquí.”

​
Cómo Activarla

Escribe tu texto de enfoque justo después del comando de revisión en un comentario del pull request:
También puedes usar start-review y combinarlo con --force:
--force vuelve a ejecutar la review incluso cuando Kody normalmente la omitiría (“sin commits nuevos desde la última review”). Úsalo — con o sin directiva de enfoque — para obtener un nuevo análisis después de corregir lo que hizo fallar la ejecución anterior, o para aplicar configuraciones actualizadas a un PR ya revisado.
Solo se usa la primera línea después del comando como directiva. Todo lo que esté en líneas posteriores se ignora, así que mantén el enfoque en una sola línea.
Funciona en GitHub, GitLab, Azure DevOps, Bitbucket y Forgejo.

​
Heavy mode

Una directiva de foco le dice a Kody dónde mirar con más atención. --heavy le dice que mire de forma más amplia: junto a la revisión de siempre, nueve revisores especialistas leen el diff completo, cada uno en busca de un único tipo de defecto:
  • código que dice una cosa y hace otra (nombres, mediciones, resultados)
  • texto que llega a una persona — mensajes, comentarios, traducciones — en desacuerdo con el código
  • estado inválido, invariantes rotas y condiciones de carrera
  • suposiciones de límites, índices y orden
  • secretos e identidad: comparaciones, normalización, valores de respaldo
  • un contrato modificado que un llamador no acompañó
  • tests que seguirían pasando si el comportamiento que cubren se rompiera
  • datos que se filtran en respuestas, logs y mensajes de error
  • dos archivos modificados que no concuerdan entre sí
Cada hallazgo de un especialista pasa por la misma verificación que los de la revisión principal antes de que se publique nada, y luego por la deduplicación y la severidad habituales, así que una suposición que no se sostiene se descarta como cualquier otra.

​
Heavy por defecto, o para una revisión

El ajuste Review mode en Code review → General elige cómo se ejecuta cada revisión de un repositorio: Balanced (el predeterminado, solo la revisión principal) o Heavy. Se aplica a las revisiones automáticas, a @kody review y a kodus review. Una flag en un comando lo anula para esa revisión:
--heavy ejecuta una revisión heavy en un repositorio configurado como Balanced; --balanced ejecuta una revisión balanced en un repositorio configurado como Heavy. Si un comando lleva ambas, gana --heavy. Cualquiera de las dos flags puede ir en cualquier posición de la línea — antes o después del texto de foco — y se elimina de la directiva en ambos casos, así que @kody review enfócate en la lógica de retry --heavy se enfoca en “enfócate en la lógica de retry”. Las flags se combinan en cualquier orden: @kody review --heavy --force ejecuta una revisión heavy forzada. En un pull request que Kody ya revisó, pedir el modo distinto al de la última revisión revisa el pull request completo, no solo los commits desde entonces. El guion es obligatorio: un heavy o balanced suelto se lee como texto de directiva, así que @kody review heavy flujo de checkout se enfoca en “heavy flujo de checkout” en vez de activar la flag.

​
Qué esperar

  • Disponible para todos, en Cloud y en self-hosted. Sin solicitud de acceso. En la CLI requiere un equipo con sesión iniciada (kodus auth login): una revisión en modo trial se ejecuta sin él y lo avisa.
  • Tus categorías siguen aplicando. Los especialistas de una categoría desactivada no se ejecutan: siete son de Bug y dos de Security. Las Kody Rules y los agentes personalizados se ejecutan como siempre.
  • Se ejecuta en el modelo Heavy. En AI providers → Routing → Code Review, Model for Heavy elige el modelo de las revisiones heavy y Model for Balanced el de las revisiones balanced. Sin un modelo Heavy definido, una revisión heavy usa el predeterminado de la organización. Un modelo definido para un repositorio o directorio en Code review → General ejecuta ambos modos.
  • Cuesta más y tarda más. En nuestra evaluación con 30 pull requests, frente a Balanced con el mismo modelo, una revisión heavy tardó hasta cerca del doble y costó cerca de 2,5 veces más en modelo por pull request. Encontró cerca de un problema real más cada dos pull requests y publicó cerca de un comentario más por pull request que no era un problema real. Con tu propia clave de modelo (BYOK) el costo adicional va a la factura de tu proveedor, y un proveedor con un límite de concurrencia bajo puede encolar las llamadas.
  • Sin acceso al repositorio (sin sandbox), los especialistas leen solo el diff, como hace la revisión principal en ese caso.
  • La lista de pull requests muestra una insignia Heavy en los PRs cuya última revisión se ejecutó en heavy mode.
Configura Heavy como Review mode de los repositorios donde que se escape algo sale caro — un servicio de pagos, un módulo de auth — o pídelo con --heavy en un único cambio arriesgado.

​
Cómo Escribir una Buena Directiva

  • Sé específico sobre el área, no sobre el veredicto. “enfócate en la concurrencia del consumidor de la cola” funciona mejor que “encuentra bugs”.
  • Nombra el código, no el resultado. Apunta a un módulo, flujo o preocupación (“la lógica de retry”, “el SQL en el servicio de reportes”).
  • Sé breve. Las directivas tienen un límite de 500 caracteres; solo se lee la primera línea del comentario.
  • @kody review enfócate en el flujo de autenticación y refresh de token
  • @kody review enfócate en el nuevo manejo del webhook de Stripe
  • kodus review --focus "condiciones de carrera en el worker en segundo plano"
  • @kody review por favor sé exhaustivo — no hay área que priorizar.
  • @kody review comenta solo en el archivo X — una directiva no es un filtro; usa Ignored files para acotar archivos.

​
Notas y Límites

  • Longitud: las directivas se truncan en 500 caracteres.
  • Solo la primera línea: en comentarios de PR, solo la primera línea tras el comando se convierte en la directiva.
  • No confiable por diseño: como cualquiera que pueda comentar el PR puede aportar una directiva, el texto se sanea antes de usarse (se eliminan caracteres de control y los signos de menor/mayor). Esto no cambia tu enfoque — solo evita que el texto manipule el prompt interno de Kody.
  • No persistente: no se escribe nada en la configuración de tu repositorio u organización.