Genera texto e instrucciones para cualquier agente de IA — Claude, Gemini, ChatGPT, Antigravity, el que uses. No ejecuta despliegues ni toca Hostinger: eso lo hace tu agente en tu entorno, siguiendo lo que aquí se genera.
1 Datos del proyecto
Aquí va solo el nombre, no la ruta. La carpeta donde se instala todo te la pregunta el .bat cuando lo ejecutes en tu computadora (paso 5).
2 Generalidades del proyecto
Web-app universal: fijo, no configurable. Una sola base de código que funciona desde el navegador en cualquier sistema operativo — Windows, macOS, Linux, Android e iOS — sin depender de ninguno en particular. Sin complementos ni instalaciones propias de un sistema, y respondiendo igual a ratón, teclado y pantalla táctil.
EspañolTextos en archivo de traducción, nunca incrustados en el código.
InglésSegundo idioma base. Decidirlo ahora es barato; agregarlo después, caro.
Deja esto sin marcar en el caso normal. Marcar un sistema significa que el proyecto deja de ser una web-app universal y se ata a esa plataforma: cambia la arquitectura, el despliegue y el mantenimiento. No es una preferencia ni una prioridad de pruebas — es una decisión de alcance, y como tal queda registrada en la documentación del proyecto con su motivo.
WindowsSolo si el proyecto se construye para Windows en concreto.
macOSSolo si el proyecto se construye para macOS en concreto.
LinuxSolo si el proyecto se construye para Linux en concreto.
AndroidSolo si el proyecto se construye para Android en concreto.
iOSSolo si el proyecto se construye para iOS en concreto.
Adaptación a pantalla: obligatoria, no configurable. Laptop, tablet y teléfono. Sin desplazamiento horizontal, botones cómodos para el dedo, campos que no disparen zoom en móvil, contenido largo plegable. Se verifica en los tres anchos antes de dar por terminada cualquier pantalla.
Ningún archivo cargado. Si lo cargas, se descarga como ESTILOS.md para copiarlo a 06_design/brand_assets.
Ningún logo seleccionado. El archivo lo copias tú a 06_design/brand_assets; aquí solo se registra el nombre esperado.
3 Tu idea — por teclado o por voz
Dictado en el navegador, no sale de tu computadora
4 Propuesta preliminar de agentes y skills
Esto sale de detectar palabras clave en tu idea, no de un análisis profundo. Es un punto de partida para discutir: desmarca lo que sobra, y tu agente lo revisa y completa en su paso 1 antes de crear nada. Nada se crea sin tu aprobación explícita (regla 12 de policies.md).
(escribe tu idea arriba y presiona "Proponer agentes y skills")
5 Generar instrucciones
El .BAT del entorno completo crea una carpeta por cada agente y skill que dejaste marcado arriba, cada una con su README de rol, además de todos los archivos de gobernanza. Descarga también IDEA.TXT e INICIO.TXT y cópialos a la raíz del proyecto cuando el .bat termine.
Qué pasa al ejecutar el .bat — doble clic y se abre una consola que pregunta: Ruta del proyecto, SIN barra al final (ej: C:\PROJECT\CLASSEN):
Escribes por ejemplo C:\PROJECT\CLASSEN y Enter. No hace falta crear esa carpeta antes: el script la crea, junto con todas las intermedias. Al terminar abre el Explorador ahí.
Sin barra al final — coloca C:\PROJECT\CLASSEN, no C:\PROJECT\CLASSEN\. Tampoco uses comillas: el script ya las agrega.
Para qué sirve cada archivo Copiar INICIO.TXT — es lo que pegas en el chat del agente. Ya lleva tu idea completa adentro, no necesitas nada más para arrancar la conversación. Descargar INICIO.TXT — la misma instrucción como archivo, para guardarla en el proyecto y no depender del historial del chat. Descargar IDEA.TXT — tu especificación original sola, para que viva en la raíz del proyecto. Es la que el agente relee en cada re-baseline y la que consultan las sesiones futuras cuando el chat ya no existe. Si algún día difieren, IDEA.TXT es la que manda.
Ver el texto de INICIO.TXT
(completa los datos arriba y presiona Generar)
6 Prompt de infraestructura Hostinger
Incluye creación de base de datos y credenciales. Revisar antes de pegar: el primer despliegue y cualquier cambio de esquema deben pedir tu aprobación explícita — no corren solos.
Ver el prompt completo
7 Comando /plan — la regla que ordena todo lo demás
/plan no es un paso más de la lista: es el envoltorio de los demás. No eliges entre /plan y /arquitectura — usas /planpara ejecutar /arquitectura. Primero /plan propone qué se va a hacer y tú apruebas; después invocas el comando que hace el trabajo. Necesitan /plan antes:/arquitectura, /hostinger, /sincronizar, /mejora y cualquier cambio de código. No lo necesitan:/auditoria y /handoff — el primero solo lee, el segundo solo agrega al final de STATUS.md.
Ningún cambio se hace sin plan escrito y aprobado (regla 16). El agente propone, tú apruebas, y a partir de ahí ejecuta completo sin pedirte confirmación en cada paso — ya se la diste al aprobar. Con un límite que evita que eso sea vía libre: si durante la ejecución aparece algo que el plan no previó, se detiene y propone un plan nuevo. No improvisa.
Cuándo se usa: antes de tocar nada, en cualquier cambio que toque más de un archivo o que borre, mueva o publique algo. El momento exacto es cuando piensas «esto es chico, lo hago directo» — ese es el cambio que se sale de control. Explorar, leer y buscar no necesitan plan: eso es libre.
Instalar como: Antigravity → Customizations → Workflows → + Global · Claude Code → ~/.claude/commands/plan.md · Codex → ~/.codex/prompts/gob-plan.md
Ver el comando completo
Cada plan queda guardado — un .md en 03_state/planes/, con nombre AAAA-MM-DD_descripcion.md. Estados: PROPUESTO, APROBADO, EJECUTADO o DETENIDO.
Para repetir un cambio — abres el archivo del plan, lo copias y lo vuelves a ejecutar. Sirve también para aplicar el mismo cambio en otro proyecto. Por eso el plan incluye alcance, pasos y evidencia esperada: sin eso no sería reutilizable.
Un plan ejecutado no se edita — si hace falta otro cambio, es un plan nuevo. El historial no se reescribe, igual que STATUS.md.
8 Comando /arquitectura — SPEC.md y diseño
Esta página no redacta la arquitectura: solo detecta palabras clave, y un SPEC.md generado así saldría plausible pero hueco — y nadie revisa un documento que ya parece completo. Lo que el .bat sí crea son las plantillas con las preguntas que hay que responder (02_specs/SPEC.md y 01_architecture/system_design.md), y este comando hace que tu IA las complete leyendo tu idea, marcando lo que es supuesto y preguntando lo ambiguo antes de escribir.
Cuándo se usa: una sola vez, después de completar requirements.md y antes de la primera línea de código. Es el paso 5 del INICIO.TXT. Si más adelante el diseño cambia de verdad, eso no se arregla con este comando: es un re-baseline.
El auditor es un agente de núcleo: no construye, solo verifica contra el disco y deja rastro en STATUS.md. Corre en cada hito: 0 arranque · 1 propuesta aprobada · 2 antes de la primera corrida crítica · 3 rutina semanal · 4 antes de desplegar · 5 cambio de alcance. Su veredicto puede ser EN ORDEN, DESVIACIONES MENORES o BLOQUEADO.
Cuándo se usa: en los seis hitos, y siempre antes de algo largo, irreversible o público. No es un chequeo diario: auditar todos los días lo convierte en trámite y deja de leerse.
Dónde queda el historial — 03_state/STATUS.md: una entrada por cambio aceptado (con evidencia y quién aprobó) y una por auditoría de hito, con versión semver. Solo se agrega al final, nunca se reescribe hacia atrás.
Dónde quedan los problemas — 00_governance/audit_logs/incident_log.md: una fila por hallazgo, con causa raíz y lección.
Qué revisa — estructura vs. registro de agentes (deriva silenciosa), estado, activos canónicos y sus hashes, locks huérfanos, si safety_checks.py sigue sin implementar, trazabilidad de salidas, y autocertificación de agentes.
10 Comando /hostinger — actualizar la web
Guárdalo como comando /hostinger en Antigravity. A diferencia del prompt del paso 6 (que crea la infraestructura una vez), este es el de uso diario: muestra los cambios antes de subir, clasifica el riesgo, respalda, despliega, y comprueba la URL real antes de reportar éxito. Los cambios que tocan base de datos o credenciales se frenan y te piden aprobación.
Cuándo se usa: en cada publicación a producción, incluida la primera. Sobre todo cuando piensas «es solo un archivo, lo subo y ya». No sirve para crear la infraestructura: eso es el prompt del paso 6, una sola vez.
Instalar como: Antigravity → Workflows → + Global (si repites despliegue) · Claude Code → .claude/commands/hostinger.md · Codex → ~/.codex/prompts/hostinger.md
Ver el comando completo
11 Comandos de mantenimiento — /handoff y /mejora
Los dos que sostienen el proceso en el tiempo. /handoff ataca la causa más común de desorden: el agente que arrastra una conversación larga y empieza a mezclar decisiones viejas con nuevas. /mejora afina un agente solo cuando falló de verdad y hay un incidente que lo respalde — nunca por intuición.
Cuándo se usa /handoff: al cerrar cada jornada, y en cuanto la conversación se vuelva larga o el agente empiece a repetir cosas ya resueltas. Cuándo se usa /mejora: solo después de que un agente falló dos veces por el mismo motivo y hay un incidente registrado. Nunca por intuición: afinar sin incidente es cambiar el comportamiento sin causa, que es la definición de deriva.
/sincronizar — poner al día un proyecto viejo. El marco mejora, pero los proyectos ya creados no se enteran solos: siguen con el reglamento del día que se generaron. Este comando compara el proyecto contra el marco vigente y agrega sin borrar — las reglas que quedan obsoletas se marcan con fecha y motivo, no se quitan.
Instalar como: Antigravity → Customizations → Workflows → + Global · Claude Code → ~/.claude/commands/sincronizar.md
Ver /sincronizar — poner al día la gobernanza
Cuándo se usa cada comando — dentro del proceso
Los comandos no fallan porque el agente los ejecute mal. Fallan porque nadie se acuerda de invocarlos. Por eso cada uno lleva aquí cuatro cosas: su disparador concreto, cuándo no es su momento, la señal de que te lo saltaste, y qué prueba que se usó de verdad.
Los comandos no van en fila: se anidan./plan envuelve a los que escriben en disco. La secuencia real de cualquier trabajo es /plan → apruebas → el comando que hace el trabajo → se cierra el Registro de ejecución del plan. Un plan sin comando detrás no ejecuta nada; un comando sin plan delante es un cambio sin autorizar.
Orden en la vida del proyecto: INICIO → /plan + /arquitectura (una vez) → /plan + el cambio (cada vez) → /auditoria (hitos) → /plan + /hostinger (publicar) → /handoff (cerrar el día) → /plan + /mejora (tras fallo repetido) → /plan + /sincronizar (cambió el marco) → re-baseline (cambió el alcance)
/plan — antes de cualquier cambio
Disparador: vas a modificar, borrar, mover o publicar algo. Da igual el tamaño.
No es su momento: leer, buscar, listar o explorar. Eso es libre y no necesita plan; exigirlo ahí solo genera burocracia.
Señal de que te lo saltaste: el agente te devuelve trabajo hecho que tú no habías descrito antes.
Evidencia de que se usó: un archivo en 03_state/planes/ con el Registro de ejecución completado. Un plan aprobado y nunca cerrado es papel, no gobernanza.
/arquitectura — una vez, al principio
Disparador:requirements.md está completo y sin alternativas abiertas. Es el paso 5 del INICIO.TXT.
No es su momento: rediseñar sobre la marcha. Si el diseño cambia de fondo a mitad del proyecto, eso es un re-baseline, no una segunda pasada de este comando.
Señal de que te lo saltaste: el agente empieza a redactar SPEC.md sin haberte dicho antes qué entendió y qué quedó ambiguo.
Evidencia de que se usó:SPEC.md y system_design.md sin ningún TODO, y los supuestos marcados como supuestos en vez de escritos como hechos.
/auditoria — en los hitos, no a diario
Disparador: arranque, propuesta aprobada, antes de la primera corrida crítica, rutina semanal, antes de desplegar, y cambio de alcance.
No es su momento: todos los días. Una auditoría diaria se vuelve trámite, y un trámite no se lee.
Señal de que te lo saltaste: no puedes decir de memoria qué agentes existen en el proyecto ni cuál es el estado real.
Evidencia de que se usó: entrada en STATUS.md con veredicto y versión. Un veredicto EN ORDEN sin hallazgos, varias veces seguidas, merece sospecha: o el proyecto va perfecto o el auditor no está mirando.
/hostinger — en cada publicación
Disparador: vas a subir algo a producción. También la primera vez.
No es su momento: crear la infraestructura. Eso es el prompt del paso 6, que se usa una sola vez.
Señal de que te lo saltaste: no puedes decir con certeza qué versión está en línea ahora mismo.
Evidencia de que se usó: la URL real consultada después de subir, y el respaldo con su ruta escrita. El paso del respaldo es el que se salta quien tiene prisa: si falta, el despliegue no cuenta como hecho.
/handoff — al cerrar el día
Disparador: terminas la jornada, o la conversación se hizo larga y el agente empieza a mezclar decisiones viejas con nuevas.
No es su momento: durante el día. No sustituye a STATUS.md, lo cierra.
Señal de que te lo saltaste: al día siguiente abres el chat viejo en vez de empezar uno nuevo. Si necesitas el historial del chat para poder seguir, el handoff anterior no sirvió.
Evidencia de que se usó: se ve en la sesión siguiente, no al ejecutarlo — el agente arranca leyendo archivos y no preguntándote dónde quedaron las cosas.
/mejora — tras un fallo repetido
Disparador: la segunda fila igual en incident_log.md. Dos fallos del mismo agente por el mismo motivo.
No es su momento: cuando se te ocurre una redacción mejor. Afinar un agente sin incidente que lo respalde es cambiar el comportamiento sin causa — eso es exactamente la deriva que este framework intenta frenar.
Señal de que te lo saltaste: estás editando un AGENT.md a mano.
Evidencia de que se usó: el AGENT.md tiene historial de ajustes citando el incidente concreto que lo motivó.
Puede no dispararse nunca en todo un proyecto, y eso no lo vuelve peso muerto: cubre un evento que quizá no ocurra, igual que el protocolo de re-baseline.
/sincronizar — cuando el marco cambia
Disparador: actualizaste este panel, o vuelves a un proyecto que llevaba semanas parado.
No es su momento: reescribir policies.md. Este comando agrega sin borrar: las reglas obsoletas se marcan con fecha y motivo, no se eliminan.
Señal de que te lo saltaste: citas una regla por número y el agente no la encuentra en su archivo.
Evidencia de que se usó: el número de reglas que reporta el agente coincide con el del marco vigente, y hay una entrada en STATUS.md con la versión a la que se actualizó.
De todos, /plan es el que sostiene a los demás. Si no se usa en un cambio de tres archivos, no se va a usar en el grande. El momento de mayor riesgo para este proceso no es cuando el agente se equivoca — es la primera vez que tú tienes prisa.
Todos los comandos — referencia rápida
Quedan como archivos PROMPT_*.txt en la raíz de tu proyecto
INICIO.TXT — el primer mensaje del proyecto. Lleva tu idea y ordena proponer agentes y skills antes de crear nada. Una sola vez, al empezar.
/plan — propone el plan de un cambio y espera tu aprobación; aprobado, lo ejecuta completo sin más confirmaciones. Queda guardado en 03_state/planes/ para repetirlo cuando haga falta. Antes de cualquier cambio. Es la regla que ordena el resto.
/arquitectura — redacta SPEC.md y el diseño desde tu idea; primero te dice qué entendió y qué quedó ambiguo. Antes de la primera línea de código, y con un /plan aprobado por delante.
/auditoria — el auditor revisa todo contra el disco y da veredicto: EN ORDEN, DESVIACIONES MENORES o BLOQUEADO. En cada hito: arranque, propuesta aprobada, antes de una corrida larga, semanal, y antes de desplegar.
/handoff — cierra la sesión escribiendo el estado real en STATUS.md, para que al día siguiente arranques leyendo archivos y no arrastrando el chat. Al terminar cada jornada. Es el que más rinde.
/mejora — afina un agente o skill que falló, con el incidente que lo respalda; propone el cambio mínimo. Cuando algo falló dos veces, no cuando surge una idea.
/hostinger — publica cambios: los muestra antes de subir, clasifica el riesgo, respalda, despliega y comprueba la URL real. Cada vez que publiques cambios.
/sincronizar — compara la gobernanza de tu proyecto contra el marco vigente y agrega lo que falte, sin borrar lo que ya está. Cuando el marco se actualiza: los proyectos ya creados no se enteran solos.
re_baseline_protocol.md — no es un comando sino un procedimiento de 7 pasos. Cuando el alcance del proyecto cambia de verdad, antes de seguir.
Cómo instalar los comandos en tu herramienta
El .bat deja esta misma guía como INSTALAR_COMANDOS.md
Google Antigravity — menú de tres puntos del panel del agente → Customizations → pestaña Workflows → botón + Global (todos tus proyectos) o + Workspace (solo este). Nombra el workflow como el comando, pega el contenido del PROMPT_*.txt y guarda. Se invoca escribiendo /auditoria. Recomendado como Global: plan, arquitectura, auditoria, handoff, mejora y sincronizar — son genéricos y sirven en cualquier proyecto creado con este panel. Como Workspace: hostinger, si el destino de despliegue cambia de un proyecto a otro.
Claude Code — archivos .md en .claude/commands/ (proyecto, se versiona con git) o ~/.claude/commands/ (personal, todos tus proyectos). El nombre del archivo es el comando: .claude/commands/auditoria.md → /auditoria. Admite frontmatter con description y allowed-tools.
Codex (ChatGPT) — archivos .md en ~/.codex/prompts/; el nombre del archivo es el comando. Ojo: OpenAI marcó los prompts personalizados como obsoletos y recomienda skills — verifica qué mecanismo aplica en tu versión. Además es siempre global, así que conviene prefijar (gob-auditoria.md).
Cualquier otra IA — abre el PROMPT_*.txt, copia y pega en el chat. Los comandos son comodidad, no requisito: lo que gobierna es el texto.
Rules y Workflows no son lo mismo — y confundirlos rompe cosas. Workflows son comandos: duermen hasta que escribes /plan. Ahí van todos los PROMPT_*.txt. Rules son instrucciones permanentes: se inyectan en cada conversación, siempre.
Si pegas /plan como Rule, el agente arranca cada sesión leyendo «voy a pedirte un cambio, no lo hagas todavía» sin que le hayas pedido ningún cambio — y se queda esperando un plan que nadie pidió. El comando deja de ser una compuerta que abres cuando hace falta y pasa a ser un freno permanente. Los comandos van en Workflows, sin excepción.
Para qué sí sirve la pestaña Rules. Para un núcleo corto que quieres activo siempre. Corto de verdad: ocupa espacio en cada turno. Algo así basta: Antes de responder, lee 00_governance\policies.md y dime cuántas reglas tiene. Ningún cambio sin plan aprobado (regla 16). Crear no incluye borrar: todo borrado se pide aparte (regla 19). No afirmes que un archivo existe sin haberlo comprobado (regla 18). Si algo no se puede determinar, se deja en null: no se inventa (regla 3).
Cinco líneas que aplican siempre. El resto son comandos, y los comandos se invocan.
Generalidades de operación — lo que marcas en el paso 2 entra directo en el requirements.md del proyecto. La adaptación a pantalla es fija y no se puede desactivar. Por defecto también lo es la web-app universal: solo deja de serlo si marcas un sistema operativo en la sección de excepción, y en ese caso el requirements.md lo registra como decisión de alcance declarada, con su motivo y sus consecuencias escritas. Si cargaste guía de estilos o registraste un logo, también queda anotado en 06_design/brand_assets con una regla clara: si falta un archivo de marca, el agente lo pide — no inventa un logo ni elige una paleta por su cuenta.
¿Español o inglés? Están en español a propósito. En los modelos actuales la diferencia de rendimiento es marginal, y pesa más una razón de gobernanza: la regla 2 exige que un humano pueda verificar el trabajo, y un prompt que no lees con fluidez no lo puedes auditar. Los identificadores técnicos (nombres de archivo, claves de frontmatter, campos JSON) sí van en inglés, y no deben traducirse.
Guía rápida — cómo trabajar con esto
El .bat deja esta misma guía como GUIA_DE_USO.md en tu proyecto
Un día normal — abrís la sesión (si es nueva, que lea STATUS.md primero) → le pides algo → el agente propone antes de hacerlo → tu apruebas con palabras claras ("aprobado, procede") → ejecuta y trae evidencia real → queda en STATUS.md. Al cerrar la jornada, /handoff.
Las cuatro frases que más sirven
«Muestrame la evidencia, no me la describas.»
«Todavía no lo hagas. Dime primero cómo lo harías.»
«¿Eso lo verificaste tu mismo? Entonces no cuenta.»
«Esa tarea es muy grande. Dividela.»
No trates todo como rojo — 🟢 leer y explorar no pide permiso, 🟡 un cambio reversible pide evidencia y tu OK, 🔴 proceso largo o producción pide protocolo completo. Si todo cuesta, vas a saltear el proceso justo cuando hay prisa.
Lo que NO tienes que hacer — revisar cada línea de código. Para eso está la evidencia y el auditor. Tu trabajo es decidir, aprobar y exigir pruebas.
Secuencia de referencia
Primero — desplegar la carpeta de gobernanza del proyecto (una vez).
Segundo — pegarle INICIO.TXT a tu agente de IA: revisa la propuesta de agentes/skills, la afina, espera tu aprobación, y solo entonces construye.
Tercero — operación diaria: proponer → simular → medir → tu apruebas → implementa → verifica con evidencia → documenta. Fricción según riesgo: 🟢 libre, 🟡 con evidencia y aprobación, 🔴 protocolo completo.