Por qué lo hice
Hace muchos años que escribo software y casi toda la vida que emprendo cosas. Los agentes de código cambiaron mi forma de construir: ideas que antes esperaban un equipo o un mes libre ahora tienen una primera versión real. En el camino me encontré escribiéndoles siempre las mismas instrucciones a los agentes, y encontrando los mismos tipos de bugs después de que decían “listo”. Keelokit es lo que salió de ir resolviendo eso, proyecto a proyecto.
La idea
Las reglas importantes no pueden vivir solo en un prompt. En Keelokit cada regla apunta a algo que la verifica (un test, una regla de lint, un hook de git, un job de CI) y un script chico avisa cuando una regla se quedó sin su verificación. Lo que nadie sabe todavía queda escrito como pregunta abierta en vez de adivinarse, y el agente que escribe el código no es el que dice que está terminado. Los bugs vienen en clases, así que las reglas que siempre tienen que cumplirse (los totales cierran, un aviso sale una sola vez, un límite aguanta dos pedidos a la vez) quedan escritas y se prueban con tests pensados para romperlas.
Qué hace
| Comando | Qué pasa |
|---|---|
/keelokit:project-new | De una idea a un esqueleto que funciona: una entrevista que escribe el contexto del producto, un PRD corto, el stack, un monorepo generado con CI y un primer backlog |
/keelokit:project-adopt | Suma solo el harness a un repo que ya tenés, y deja lo que todavía no cumple como excepciones con fecha |
/keelokit:build-story | Una historia por vez: un verificador escribe primero los tests de aceptación, un builder los hace pasar, un revisor lee el diff, un breaker intenta romperla y el verificador la recorre en la app corriendo |
/keelokit:check-bugbash | Una cacería de bugs en datos, API, integridad, UX, traducciones, accesibilidad, seguridad y más; cada bug que se escapó suma un check para toda su clase, para que no vuelva |
/keelokit:project-dashboard | Una página que se arma desde el repo para seguir el proyecto: cada etapa y su estado, lo que espera tu revisión, las historias por ola y por épica, los bug bashes, las decisiones tomadas y botones para pedirle a Claude el próximo paso |
Ver todos los comandosVer menos
| Comando | Qué pasa |
|---|---|
/keelokit:plan-intake | Lee lo que ya tenés (briefs, notas, un repo) y pregunta solo lo que falta; lo que nadie sabe todavía queda escrito como pregunta abierta, con un responsable |
/keelokit:plan-backlog | Épicas e historias con escenarios de aceptación y las reglas que tienen que respetar, agrupadas en olas de desarrollo para que el trabajo en paralelo nunca toque los mismos archivos |
/keelokit:check-health | Verifica que cada regla siga teniendo un check que funcione; suma una regla nueva con su check o registra una excepción con fecha |
/keelokit:check-security | Seguridad y privacidad a fondo: un mapa de los datos personales, la ley de privacidad de cada mercado, abusos de los recorridos críticos, escaneos de dependencias y de staging; cada problema se corrige con un test y un control que cubre su clase |
/keelokit:ship-setup | Staging y producción para quien nunca desplegó nada: una guía con un checklist por entorno, los pasos que no necesitan tus credenciales, resueltos por Keelokit, y cada uno verificado |
/keelokit:ship-release | Una versión que se puede nombrar, leer y a la que se puede volver: notas de lo que entró, un tag después de tu sí, y producción solo cuando una persona lo aprueba |
/keelokit:harness-upgrade | Mantenimiento del harness, no de tu app: trae a tu proyecto las reglas y controles nuevos de Keelokit, en una rama, sin tocar el código del producto |
/keelokit | Dónde está el proyecto, qué sigue y qué espera tu decisión |
Los agentes que usa
| Agente | Qué hace |
|---|---|
| Verificador | Escribe los tests de aceptación antes de que exista el código, y es el único que puede dar una historia por terminada, después de recorrerla en la app corriendo |
| Revisor | Lee cada cambio en frío, contra la historia y las reglas, sin haberlo escrito |
| Breaker | Ataca cada historia antes de integrarla: envíos dobles, pedidos simultáneos, repeticiones, datos de otro cliente |
| Auditor de contexto | Revisa el contexto del producto buscando datos inventados, frases vagas y contradicciones antes de construir sobre él |
Lo que corre solo
| Cuándo | Qué |
|---|---|
| Antes de cada acción de un agente | Un guard frena secretos, cambios a archivos .env y a migraciones ya aplicadas, hooks de git salteados, tests silenciados y deploys a producción |
| Al empezar una sesión | Un estado corto: dónde está el proyecto y qué historias están listas |
| En cada etapa | El tablero se actualiza; en modo automático Keelokit sigue solo y se detiene únicamente donde hace falta una persona |
| En cada commit y push | El mismo guard como hook de git, y después el chequeo local completo antes de que algo llegue al remoto |
| En CI | Búsqueda de secretos, lint y tipos, tests unitarios, tests de integración contra un PostgreSQL real, recorridos de punta a punta con análisis de accesibilidad y contra la API real, mutation testing del código crítico, análisis estático y deploy a staging |
El stack que genera es el que me gusta usar: pnpm workspaces, TypeScript, NestJS con Prisma y PostgreSQL, Vite y React, Expo y Astro.
Para quién es
Para quienes están dando sus primeros pasos con agentes, y para emprendedores y equipos, técnicos o no, que están armando la base de su primer MVP. Es opinado y está hecho a mi gusto, así que no va a encajar en todos los proyectos ni en todos los equipos. Tomá lo que te sirva.
Probarlo
Keelokit tiene su propio sitio: keelokit.com. El código, las instrucciones y la licencia (MIT) están en GitHub: github.com/leosimini/keelokit. Ahí están abiertos los issues y las discusiones.