Keelokit

Open source · un harness personal de Claude Code

La quilla debajo de mis apps.

El harness que uso para convertir ideas en primeras versiones con agentes de código: mi stack, mis reglas, mi forma de trabajar. Lo mantengo los fines de semana y en noches de música y código, y lo comparto por si te sirve a vos también.

 claude plugin marketplace add leosimini/keelokit claude plugin install keelokit@keelokit

Ver en GitHub Sumergirse

Lo que construís va arriba. Lo que te mantiene el rumbo, abajo.

−2 m

De una idea a un monorepo que funciona

/keelokit:kickstart te lleva por cinco etapas. Se frena solo donde importa tu decisión, y va dejando todo por escrito.

  1. 01

    Intake

    Una entrevista que primero lee lo que ya tenés y después pregunta solo lo que falta. Lo que nadie sabe todavía queda escrito como pregunta abierta, con un responsable.

  2. 02

    Producto

    Un PRD corto: el problema, para quién es, qué entra y, explícitamente, qué queda afuera.

  3. 03

    Stack

    El stack de la casa. Lo que se desvía queda registrado como decisión, no improvisado.

  4. 04

    Esqueleto

    Un monorepo generado con CI, hooks de git y tests, en verde antes de escribir una feature.

  5. 05

    Backlog

    Épicas e historias con escenarios de aceptación, agrupadas en tandas que nunca tocan los mismos archivos.

Lo que obtenés
  • mi-app/
  • apps/
  • api/NestJS · Prisma · PostgreSQL
  • web/Vite · React
  • mobile/Expo · iOS y Android
  • site/Astro
  • packages/
  • shared/contratos zod · i18n
  • ui-tokens/una sola fuente para el diseño
  • docs/context/lo que se sabe y lo que falta
  • backlog/historias con ids de escenario
  • .keelokit/reglas, checks, guard, doctor

Elegís qué apps necesita cada producto.

El esqueleto, verificado de punta a punta
pnpm verify▶ Format▶ Lint▶ Typecheck▶ Harness doctor  ✔ harness healthy▶ Unit tests▶ Integration tests (throwaway PostgreSQL)▶ Build▶ End-to-end journeys▶ Dependency audit✔ verify passed

Por dónde empezar

Qué tenésEmpezá conQué obtenés
Una idea, nada más/keelokit:kickstartUn monorepo que funciona, con CI, contexto y un primer backlog
Un repo que ya existe/keelokit:adoptLas reglas mapeadas a sus checks, y el resto como deuda con fecha
Una historia para construir/keelokit:buildTests escritos primero, código que los pasa y un resultado verificado
Bugs que se siguen escapando/keelokit:bugbashArreglos en la causa raíz, y un check nuevo por cada bug que se escapó

−8 m

Todos los comandos

Nueve skills. Podés correrlos uno por uno, o dejar que /keelokit te diga qué sigue.

  • /keelokit:kickstart

    De una idea a un esqueleto que funciona: intake, PRD, stack, monorepo generado con CI y primer backlog.

  • /keelokit:adopt

    Suma solo el harness a un repo que ya tenés. Lo que todavía no cumple queda como excepción con fecha.

  • /keelokit:intake

    Lee briefs, notas o un repo, y pregunta solo lo que falta. Nunca completa un hueco adivinando.

  • /keelokit:backlog

    Épicas e historias con escenarios de aceptación, en tandas para que el trabajo en paralelo no choque.

  • /keelokit:build

    Una historia por vez: el verificador escribe primero los tests, un builder los hace pasar, un revisor lee el diff.

  • /keelokit:bugbash

    Una cacería de bugs en datos, API, UX, i18n, accesibilidad y seguridad. Cada bug que se escapó suma un check.

  • /keelokit:doctor

    ¿Cada regla sigue respaldada por un check que funciona? Suma reglas y registra excepciones.

  • /keelokit:upgrade

    Lleva un proyecto a un template más nuevo sin tocar el código del producto.

  • /keelokit

    Dónde está el proyecto, qué sigue y qué espera tu decisión.

−15 m

Lo que no se ve

Los agentes me decían “listo” y dejaban bugs. Estas tres ideas son lo que salió de ir resolviendo eso, proyecto a proyecto.

I

Una regla necesita un check

Cada regla apunta a algo que la verifica: un test, una regla de lint, un hook de git, un job de CI. El doctor avisa cuando una regla se quedó sin su check.

II

Lo que no se sabe queda como pregunta

Lo que nadie sabe todavía se escribe con un responsable y la pregunta exacta. No se inventan valores que suenan bien.

III

El que construye no se evalúa

Un verificador escribe los tests de aceptación antes del código, un revisor lee el diff en frío, y solo el verificador puede dar una historia por terminada.

El doctor, en un proyectoSalida de ejemplo
pnpm doctorKeelokit doctor  Gates: intake ✓ → product ✓ → stack ✓ → skeleton ✓ → backlog ✓  Rules: 26 · Context gaps: 2 (0 blocking)  Backlog: 4/11 done · next: AUTH-005, PAY-001  warn  exception for UI-1 until 2026-12-01: map SDK needs a literal colour  ERROR rule QA-1: CI job 'unit' has continue-on-error
Algunas reglas de la casa, y qué las hace cumplir
  • SEC-1Sin secretos en el repoescaneo en CI · guard · pre-commit
  • CFG-1Cada variable de config documentadaun test que compara schema, archivos .env y README
  • AUTHZ-1Cada ruta con su decisión de accesoun test que lee el router real
  • I18N-1Texto solo a través de traduccionesregla de lint · test de paridad de idiomas
  • QA-4Ningún test silenciadoguard · pre-commit
  • TRACE-1Cada escenario con su testdoctor, en CI

−24 m

Lo que corre solo

  1. Antes de cada acción de un agente

    Un guard frena secretos, cambios a archivos .env y a migraciones ya aplicadas, hooks salteados, tests silenciados y deploys a producción.

  2. Al empezar una sesión

    Un estado corto: dónde está el proyecto y qué historias están listas.

  3. 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.

  4. En CI

    Escaneo de secretos, lint y tipos, tests unitarios y de integración contra un PostgreSQL real, recorridos de punta a punta con análisis de accesibilidad, análisis estático y deploy a staging.

El guard, frenando a un agente
git commit -m "wip" --no-verifyBlocked by Keelokit — QA-2: never bypass git hooks echo "API_KEY=…" > apps/api/.envBlocked by Keelokit — SEC-2: don't write .env files from the shell;edit .env.example, real values go in the secret store

−32 m

Bueno saber

Es opinado

Está hecho a mi gusto y con mi stack. No va a encajar en todos los proyectos ni en todos los equipos. Si tu stack es otro, /keelokit:adopt igual te da las reglas y los checks.

Usa tokens

build y bugbash corren varios agentes por historia. Para cambios chicos existe /keelokit:build --light.

El guard es un reductor de velocidad

Frena a los agentes en los errores obvios, pero no es un sandbox. Los hooks de git y el CI son el respaldo real.

El doctor ve presencia, no calidad

Puede ver que un check existe y está prendido, no que sea un buen check. Para eso están las revisiones y las cacerías de bugs.

Ideas de las que aprendí. El desarrollo guiado por especificaciones (OpenSpec, Spec Kit), Superpowers por separar quién construye de quién revisa, Copier por los templates que se pueden actualizar, y mucha prueba y error en mis propios proyectos.

−40 m

Probarlo

 claude plugin marketplace add leosimini/keelokit claude plugin install keelokit@keelokit

En una carpeta vacía corré /keelokit:kickstart. En un repo que ya tenés, /keelokit:adopt.

Necesitás Node 22 con pnpm 10, Python 3.11+, uv, Docker y git. macOS o Linux.

Código, documentación y licencia en GitHub