Un método —y un CLI— para desarrollo asistido por IA sin vibe coding y con trazabilidad real: separa el QUÉ del CÓMO, linkéalos una sola vez, y deja que la máquina avise sola cuando se desincronizan. De un dev solo a una organización entera — el mismo método.
El problema
Tres dolores que la IA no resuelve sola — al contrario, los amplifica si no hay método.
El requerimiento cambia, el código sigue con la versión vieja, y se descubre recién en la demo. Nadie se enteró a tiempo.
La IA construye sobre una idea vaga y sale cualquier cosa. Rápido, sí — pero sin garantía de que sea lo que se pedía.
El funcional se mete en la implementación; el dev redefine el negocio. Se pierde quién es dueño de qué.
La idea
El requerimiento (el QUÉ) y la implementación (el CÓMO) son cosas distintas, con dueños distintos. dai las mantiene atadas — y la dirección inversa se deriva, nunca se escribe a mano.
dueño: PO / analista · vive en Jira o ClickUp
dueño: dev / ingeniero · vive en el repo
implements: US@versión — una vezEl QUÉ nace con un ID único (el ticket). Es lo único que lo hace linkeable.
El código apunta al QUÉ. La cobertura inversa (quién implementó qué) la genera la máquina.
Número legible + hash de criterios. Si el QUÉ cambia, los CÓMO atrasados se marcan solos.
El flujo
dai no reemplaza tu proceso: lo potencia. En cada etapa hay una skill de IA o un comando que hace el trabajo pesado. QUÉ CÓMO máquina
El analista describe la idea. Una skill de IA lo interroga hasta que la User Story es testeable, y la publica en el tracker. La IA no inventa: pregunta.
/grill-intent → /grill-user-story → ClickUp / JiraEl dev arranca la implementación. dai trae la US del tracker, crea la branch y siembra el link — correcto por construcción, sin tipear el ID a mano.
dai link-us <ID> → branch + implements.yamlOpenSpec toma la US y genera la propuesta, el diseño y las tareas — co-localizados con el link, en la misma branch. El QUÉ se convierte en un plan técnico.
/opsx:propose → proposal · design · tasksTDD en rebanadas verticales: un test, el código mínimo, repetir. La IA escribe el test como spec ejecutable. Anti vibe-coding de verdad.
/tdd · red → green → refactor¿Tu código sigue al día con la US? dai re-deriva el hash de la US viva y compara. Si el QUÉ cambió, te avisa y te dice cómo resincronizar.
dai check → ✅ al día / ⚠️ atrasadodai arma el texto de la PR desde el template, precargado con la US, el estado del check y los enlaces. Tu PR la revisas tú; la de un compañero, con la skill de review.
dai pr · /dai-review (la PR de otro)Al mergear, dai escribe en el tracker quién implementó qué, contra qué versión, con branch y commit. La trazabilidad inversa — nadie la mantiene a mano.
dai stamp → cobertura en el trackerLa pieza que lo cambia todo
El PO edita un criterio en el tracker. Tú no tocaste una línea de código. Y aun así, dai lo detecta — porque compara el hash de la US viva contra el que dejaste estampado.
Nadie le avisó al dev. El link versionado lo avisó solo. Esa es la diferencia entre esperar que alguien se dé cuenta y que el sistema te lo diga.
Un solo método
No hay una versión para equipos chicos y otra para grandes. Hay un protocolo invariante y un dial de ceremonia que sube o baja según la escala. Cada capa se agrega cuando duele, no antes.
OpenSpec y el CLI, todo local. La US puede vivir como un .md. Cero
infraestructura. El link y el check funcionan igual.
Aparece el tracker (ClickUp/Jira) para coordinar. El link referencia la US; el check y el stamp corren a mano o en un hook.
Muchos repos, equipos separados, CI que estampa cobertura y matriz de ambientes. El mismo protocolo, con más plomería.
El dev que aprende el nivel chico ya sabe el grande. Nadie mantiene dos metodologías.
Empezar
Requiere Node ≥ 18. El CLI no tiene dependencias — anda incluso en redes corporativas cerradas.
npm i -g @dforce2055/dai
dai.dai init
dai link-us <ID>
dai check → dai pr → dai stamp