Deja de improvisar con la IA. Construye lo que quedó escrito.
Fabrik OS es un método de desarrollo guiado por especificación. El asistente implementa solo lo que tú aprobaste por escrito, y deja evidencia de que lo hizo.
- 10 comandos
- 14 skills
- 4 hooks
- En español
Lo que pasa cuando construyes con IA sin un contrato
Un asistente de IA escribe código más rápido de lo que nadie puede revisarlo. El problema no es la velocidad: es que nadie dejó escrito qué se pidió. Sin eso, cada sesión empieza de cero y el asistente llena los huecos con lo más probable.
Construye lo que no pediste
Pediste un formulario y volvió con un sistema de roles. Sonaba razonable, así que nadie lo cuestionó.
Cada sesión olvida la anterior
Lo que decidiste ayer vive en una conversación que ya no existe. Hoy el asistente decide otra cosa.
Nadie sabe por qué existe ese código
Funciona, pero no hay un requisito detrás. Tocarlo da miedo porque no se sabe qué rompe.
La seguridad queda para después
Una clave pegada en un archivo, una tabla sin reglas de acceso. Se descubre cuando ya está en producción.
Los datos personales no los mira nadie
Guardas correos y teléfonos sin haber escrito para qué, por cuánto tiempo ni quién los ve.
"Ya quedó" no significa que quedó
El asistente dice que terminó. No hay un test ni una evidencia que lo respalde.
Nada de esto se arregla con un mejor prompt. Se arregla cambiando qué manda: no la conversación, sino un documento que tú apruebas.
La idea: el spec es el contrato
En Fabrik OS, el spec de una tarea es un contrato que se puede comprobar. Cada requisito tiene un identificador y criterios de aceptación; el plan dice qué tarea cubre qué requisito; y cada requisito termina respaldado por un test o por una evidencia registrada.
- Ideacon tus palabras
- Spectú lo apruebas
- Plantú lo apruebas
- Códigoun commit por tarea
- Evidenciarequisito → test
Lo que no está en el spec no se implementa
Si en medio del trabajo aparece algo que el spec no dice, el asistente pregunta o lo anota para después. No lo supone.
Solo una persona aprueba
El asistente refina, planifica e implementa. Aprobar un spec, aprobar un plan y cerrar una tarea lo hace una persona.
Lo que no se sabe queda como pregunta
Un dato que no diste no se inventa: queda escrito como pendiente. Un spec con preguntas abiertas no se aprueba.
Cómo funciona, comando por comando
Se instala una vez como plugin de Claude Code y se usa en cada proyecto. Estos son los comandos, en el orden en que los vas a usar.
- 1
/fabrikos:quickstartDe tu idea a un backlog
Cuentas la idea con tus palabras y respondes solo lo que falte. Confirmas dos cosas: el documento de producto y un backlog inicial que sale de tu propio alcance. Para un proyecto que ya existe,
/fabrikos:init. - 2
/fabrikos:discoverOpcional: ordenar el negocio
Propuesta de valor, usuarios, alternativas, modelo de ingresos y dirección visual. Separa lo que sabes de lo que supones, y no inventa un mercado.
- 3
/fabrikos:refineUna tarea se vuelve spec
El asistente pregunta en un solo bloque, recorre los casos borde y escribe requisitos que se pueden comprobar. Tú apruebas.
- 4
/fabrikos:startLa tarea empieza, con su rama
Solo arranca una tarea aprobada. Antes de tocar código se escribe el plan: tareas pequeñas, cada una con los requisitos que cubre.
- 5
/fabrikos:executeEl plan se ejecuta
Las tareas que el plan declara independientes corren en paralelo; las demás, en secuencia. Un commit por tarea, verificada y revisada. Ante un conflicto, se detiene y pregunta.
- 6
/fabrikos:finishSe cierra con evidencia
Comprueba que cada requisito tenga su test, ejecuta las revisiones que apliquen y deja la tarea lista para que una persona la revise.
- 7
/fabrikos:launch-checkAntes de salir a producción
Junta todas las revisiones en una recomendación: listo, listo con riesgos aceptados, o no listo. No despliega nada.
Si tu equipo gestiona el trabajo en Azure DevOps, los mismos comandos leen y escriben los work items. Si no, el backlog vive en un archivo del repositorio.
Lo que revisa por ti
Cuatro listas de comprobación acompañan el ciclo. Cada punto se responde con una de cuatro cosas: cumple, no cumple, no aplica y por qué, o pendiente. Varias se apoyan en reglas que leen tu código y señalan candidatos.
Seguridad
Secretos, control de acceso, validación de entrada, dependencias, archivos subidos, sesiones, cabeceras, webhooks y uso de modelos de lenguaje. Con referencias para cinco stacks.
Datos personales
Qué dato, de quién, para qué, por cuánto tiempo y quién accede. Con perfiles orientativos de Colombia, la Unión Europea, México y Chile.
Experiencia y accesibilidad
Los cinco estados de cada pantalla, uso con teclado, etiquetas, contraste. Los puntos de accesibilidad citan su criterio de WCAG 2.2.
Salida a producción
Rendimiento, configuración, monitoreo, copias de seguridad, recorrido completo y contenido real.
Lo que estas revisiones no son
Fabrik OS no certifica nada. No dice que tu aplicación "es segura", que "cumple la ley" ni que "es accesible": dice qué revisó, qué encontró y qué no pudo comprobar. Los perfiles por país son resúmenes orientativos, no asesoría legal.
Qué trae el plugin
Todo esto se instala con el plugin. No instala nada dentro de tu proyecto ni elige tu stack.
- Comandos
- Los del ciclo, más diagnóstico de la instalación y migración del backlog.
- Skills
- Refinamiento, trazabilidad, ejecución, seguridad, datos, accesibilidad, lanzamiento y documentos legales en borrador.
- Plantillas
- Producto, spec, plan, backlog, listas de comprobación, políticas y términos en borrador.
- Hooks
- Avisos y un bloqueo que funcionan solos, sin que nadie se acuerde.
- Subagentes
- Un implementador que trabaja en una copia aislada, y un revisor sin herramientas de edición.
Lo que pasa solo
Al iniciar sesión
Un panel con el estado del proyecto: en qué vas, qué sigue y qué riesgos hay.
Al editar código sin plan
Un aviso. No bloquea: te recuerda que el método pide un plan antes.
Al escribir una clave
Si el contenido tiene una clave con formato conocido, la escritura se niega. Es el único hook que bloquea.
Al terminar con commits
Si hubo commits y el estado del proyecto no se actualizó, te lo dice una vez.
Para quién es, y para quién no
Prefiero decirlo antes de que lo instales.
Te sirve si…
- Ya construyes con Claude Code y te preocupa lo que queda en el repositorio.
- Trabajas para clientes y necesitas mostrar qué se pidió y qué se entregó.
- Tu producto guarda datos de personas y quieres dejar escrito qué haces con ellos.
- Prefieres ir más despacio al principio para no rehacer después.
No te sirve si…
- Buscas que una herramienta construya la app sin que tú decidas nada.
- Quieres un stack ya elegido y una plantilla de aplicación lista: Fabrik OS no trae código.
- Usas otro asistente: hoy el plugin es para Claude Code. El método se puede seguir a mano, sin automatización.
- Necesitas una certificación o una asesoría legal. Esto no lo es.
Llévate la plantilla del spec
Esta es la estructura de un spec de Fabrik OS, reducida a lo esencial. Úsala hoy, con o sin el plugin: copia la plantilla, llénala con tu próxima tarea y pídele al asistente que no escriba código hasta que digas que está aprobada.
# Diseño: <título de la tarea>
Estado: En revisión
## Contexto
Qué problema origina esta tarea y qué existe hoy.
## Alcance
- Lo que esta tarea entrega.
## Fuera de alcance
- Lo que no entrega, aunque alguien podría esperarlo.
## Datos personales
¿Crea, lee, guarda, muestra o envía datos de personas? Si no, por qué.
## Interfaz
¿Alguien verá una pantalla nueva o cambiada? Qué se ve vacía,
cargando, con error, con éxito y sin permiso.
## Requisitos
### LOGIN-R1 — Entrar con correo y contraseña
- CA1. Dado un usuario registrado, cuando escribe su correo y su
contraseña correctos, entonces entra y ve su panel.
- CA2. Dado un correo que no existe, cuando intenta entrar, entonces
ve "Correo o contraseña incorrectos" y no se dice cuál falló.
## Criterios de finalización
Cada criterio tiene un test que pasa.
## Preguntas abiertas
Ninguna. (Con una sola pregunta abierta, el spec no se aprueba.)Vamos a escribir el spec de una tarea antes de tocar código. Usa la plantilla que te pego abajo. Hazme en un solo bloque todas las preguntas que necesites para llenarla, empezando por las que cambian lo que hay que construir. Lo que yo no responda déjalo en "Preguntas abiertas": no lo supongas. Cada criterio de aceptación describe un solo comportamiento que se pueda comprobar con un test, sin adjetivos como "rápido" o "fácil". No escribas stack, nombres de archivos ni código en el spec. No implementes nada hasta que yo diga "spec aprobado".
El plugin hace esto mismo con más rigor: identificadores que los tests citan, casos borde recorridos uno por uno, un plan que cubre cada requisito y una verificación que no deja cerrar con huecos.
Fabrik OS todavía no está a la venta
Estoy abriendo el acceso por etapas, empezando por quienes quieran probarlo en un proyecto real y contarme qué falla. Escríbeme y te aviso cuando haya un cupo.
- Te escribo yo, no un formulario.
- Sin compromiso de compra.
- El precio se anuncia con el lanzamiento.
Sin lista de correo ni seguimiento automático: el mensaje me llega directo.
Preguntas frecuentes
¿Necesito saber programar?+
Necesitas poder decidir. Fabrik OS no te pide leer cada línea, pero sí aprobar un spec y un plan escritos en lenguaje claro. Si no quieres decidir nada, no es para ti.
¿Funciona con Cursor, Codex o Gemini?+
Los comandos, los hooks y la ejecución en paralelo son de Claude Code. El método y las plantillas son documentos: se pueden seguir a mano con cualquier asistente, sin la automatización.
¿Garantiza que mi aplicación cumple la ley o es segura?+
No. Te ayuda a dejar escrito qué haces con los datos y a revisar tu código contra listas concretas, y te dice qué encontró. La decisión y la responsabilidad siguen siendo tuyas, y para lo legal hace falta un profesional.
¿Mi código sale de mi máquina?+
El plugin son instrucciones y scripts que corren en tu equipo, dentro de tu sesión de Claude Code. Sus hooks no usan la red. Lo que tu asistente envía al modelo depende de Claude Code, no de Fabrik OS.
¿Qué tan probado está?+
Fabrik OS se construye con su propio método: 22 entregas, cada una con spec, plan y revisión independiente, y más de 1.000 pruebas automáticas sobre sus scripts, sus hooks y sus documentos. Lo que falta es justo lo que busco con el acceso anticipado: usarlo en proyectos reales de otras personas.
¿Puedes implementarlo en mi equipo?+
Sí. Si prefieres que lo configure con tu backlog y acompañe las primeras tareas, escríbeme y lo vemos.