Benchmark Kilo Code para OPS
Fecha: 2026-05-09
Decision
Kilo Code se toma como benchmark de producto y arquitectura, no como formato a copiar ni como compatibilidad obligatoria.
No se va a implementar compatibilidad especifica con .kilo, kilo.jsonc o export/import hacia Kilo. OPS debe seguir su propio camino como capa de orquestacion operativa.
Lectura
Kilo Code es fuerte como agente de desarrollo en IDE, CLI, cloud y Slack. Su foco principal es escribir codigo, depurar, revisar cambios, automatizar tareas tecnicas y trabajar dentro del flujo del desarrollador.
OPS debe diferenciarse como sistema de control operativo:
- proyectos, workspaces y tareas;
- flujos recurrentes;
- decisiones humanas y bloqueos claros;
- credenciales y runtimes;
- perfiles/subagentes y skills;
- trazabilidad, tiempos y auditoria;
- despliegues y operaciones de cliente.
Que adoptar como aprendizaje propio
Perfiles mas configurables
Los perfiles/subagentes de OPS deben evolucionar hacia una configuracion mas explicita:
- rol funcional;
- descripcion clara de cuando usarlo;
- runtime preferido;
- modelo por defecto;
- skills asociados;
- permisos;
- limites de iteraciones;
- criterios de salida;
- modo de uso: principal, delegado o ambos.
Permisos por perfil
Un perfil no debe ser solo un prompt. Debe declarar que puede hacer y que necesita confirmacion:
- leer;
- editar;
- ejecutar comandos;
- usar navegador;
- crear o cerrar tareas;
- usar credenciales;
- desplegar;
- tocar workspaces, clientes o usuarios.
Esto es especialmente importante para el asistente interno de OPS.
Skills auditables
Los skills deben mantenerse como capacidades propias de OPS, con control de calidad:
- descripcion precisa;
- casos de uso;
- ejemplos;
- pruebas;
- solapes detectados;
- estado de auditoria;
- criterio para fusionar o retirar skills duplicados.
La prioridad no es tener un repositorio infinito, sino un catalogo confiable.
UX de catalogos grandes
El listado de perfiles y skills debe funcionar bien con volumen alto:
- vista de lista compacta;
- filtros utiles;
- categorias legibles;
- estado activo/inactivo claro;
- detalle bajo demanda;
- acciones simples;
- menos ruido visual en el inicio.
Complementariedad
Si en algun momento se usa Kilo, OpenCode, Codex, MiniMax u otro sistema, debe ser como runtime ejecutor opcional, no como centro del producto.
OPS decide:
- que tarea existe;
- que estado tiene;
- que humano debe decidir;
- que perfil conviene;
- que credencial o runtime se puede usar;
- que resultado se considera aceptable;
- que auditoria queda registrada.
El runtime ejecuta.
Linea de producto
Mensaje de posicionamiento:
> OPS no intenta ser otro editor con agente. OPS es la capa para orquestar trabajo real con agentes, tareas, humanos, credenciales, flujos y trazabilidad.
Acciones recomendadas
- Revisar el modelo de datos de perfiles para incluir permisos, limites y criterios de salida.
- Mejorar el asistente interno para que use razonamiento estricto y acciones confirmables.
- Consolidar el catalogo de skills con auditoria y fusion de solapes.
- Mantener la UI de perfiles y skills orientada a volumen alto, no a tarjetas extensas.
- Documentar el flujo mental: OPS orquesta, los runtimes ejecutan.