Esta guía sale de construir chzr.llc —una plataforma real para negocios mexicanos— trabajando con un asistente de IA. Son los mensajes que más nos ahorraron errores. Copia, cambia lo que está entre [corchetes] por lo tuyo y pégalo en tu asistente.
Las 7 reglas de oro
Dale contexto permanente. Un archivo (AI.md, CLAUDE.md…) que el asistente lea siempre: qué es el proyecto, sus reglas y sus trampas. Sin él, cada sesión empieza de cero.
Pide el plan antes del código. Con «no hagas nada, solo responde» te enteras de riesgos y de lo que falta decidir antes de que se toque un solo archivo.
Exige la verdad incómoda. Un asistente complaciente te entrega algo que no funciona. Pídele que te diga lo que no sabe y lo que no probó.
Una cosa a la vez, y verificada. Cambios pequeños, cada uno probado con una petición real, no solo «compilado».
Datos de prueba que se borran. Toda prueba en un sistema real deja limpio al terminar. Si no puedes deshacerlo, no lo pruebes ahí.
Nada irreversible sin confirmar. Escribir datos, enviar mensajes, cobrar o borrar: siempre proponer → mostrar el detalle → confirmar → poder deshacer.
Registra lo que se hizo. Una bitácora corta (qué, por qué, qué NO se probó, qué falta) es lo que hace que la sesión de mañana no repita los errores de hoy.
🧭 Antes de escribir código
Lo que haces al abrir una sesión o un proyecto nuevo.
Resumen de contexto
Cuándo: Al abrir una sesión nueva.
Antes de proponer o programar nada, lee el archivo AI.md y devuélveme en 10 líneas: qué es este proyecto, qué tecnología usa, dónde vive cada cosa y qué reglas no debo romper. Si algo del archivo no cuadra con el código real, dime la diferencia: manda el código.
Por qué funciona: Evita que proponga construir algo que ya existe o que ignore una regla de la casa.
Crear el archivo de contexto
Cuándo: Al empezar un proyecto, o cuando ya lo tienes y nunca lo documentaste.
Crea un archivo AI.md en la raíz del proyecto con: qué es, tecnología, mapa de carpetas, convenciones no negociables, trampas conocidas (errores que ya nos costaron caros) y cómo se despliega. Máximo 200 líneas; solo referencia estable, nada de historial.
Por qué funciona: Lo corto y estable se lee siempre; lo largo se ignora.
Separar la bitácora
Cuándo: Cuando el archivo de contexto se empieza a llenar de historia.
El historial de lo que se hace no va en AI.md. Crea una bitácora aparte y, al terminar cada tarea, agrega: qué se hizo, por qué, qué NO se probó y qué quedó pendiente.
Por qué funciona: Mantiene el contexto liviano y deja rastro para retomar sin preguntar de nuevo.
¿Ya existe?
Cuándo: Antes de construir cualquier cosa «nueva».
Antes de construir [X], busca en el proyecto si ya existe algo parecido (carpetas, tablas, funciones, textos) y dime dónde. No construyas nada hasta que yo confirme que de verdad no existe.
Por qué funciona: Un caso real: casi se construye un constructor de formularios que ya existía.
🧠 Pensar antes de hacer
Prompts para decidir bien sin gastar tiempo ni tocar nada.
Solo responde
Cuándo: Cuando tengas una idea y quieras saber si es viable.
No hagas nada todavía, solo respóndeme: ¿es posible [X]? ¿Cómo lo implementarías? ¿Qué riesgos ves y qué decisiones me faltan tomar?
Por qué funciona: Separa pensar de hacer: evitas archivos modificados por una pregunta.
Crítica honesta
Cuándo: Antes de comprometerte con un plan o una decisión.
Revisa mi idea con honestidad total, a favor del proyecto: qué me falta, en qué me equivoco y qué harías distinto. Prefiero la verdad incómoda a un «se ve bien».
Por qué funciona: Los asistentes tienden a darte la razón; esto cambia el incentivo.
Por fases
Cuándo: Cuando el trabajo es grande.
Divide esto en fases pequeñas. Cada fase debe poder probarse y subirse por separado. Dime qué entrega cada una, qué riesgo tiene y qué NO incluye.
Por qué funciona: Cada fase es un punto de retorno; si algo sale mal, pierdes poco.
Opciones con recomendación
Cuándo: Cuando hay varios caminos.
Dame como máximo 3 opciones con pros y contras, y dime cuál recomiendas y por qué. Si una opción es mala, dilo.
Por qué funciona: Te obliga a comparar y evita que tú tengas que adivinar el mejor.
Qué necesitas de mí
Cuándo: Antes de empezar una tarea con datos o decisiones tuyas.
Antes de empezar, lista lo que necesitas que yo decida o te confirme (datos, permisos, precios, textos). No lo inventes.
Por qué funciona: Los datos inventados son los errores más difíciles de encontrar después.
🔨 Construir
Para que el código nuevo se sienta parte del proyecto.
Estilo de la casa
Cuándo: Al pedir código nuevo.
Escribe código que se lea como el que ya existe en este proyecto: mismos nombres, mismo estilo de comentarios y mismos patrones. No inventes estilos nuevos.
Por qué funciona: Un proyecto con tres estilos es imposible de mantener.
Reutiliza, no dupliques
Cuándo: Antes de cualquier función o pantalla nueva.
Antes de escribir una función nueva, busca si ya hay una que haga eso y úsala. Si tienes que duplicar lógica, dime por qué.
Por qué funciona: La lógica duplicada se desalinea con el tiempo.
Una cosa a la vez
Cuándo: Cuando el asistente se pone «creativo».
Haz solo [X]. Si ves otro problema en el camino, no lo arregles: anótalo y dímelo al final.
Por qué funciona: Los cambios no pedidos son los que rompen cosas.
Cambio mínimo
Cuándo: Al arreglar un error.
Propón el cambio mínimo que resuelve el problema. Nada de reescribir archivos completos ni renombrar cosas que no toqué.
Por qué funciona: Un cambio chico se revisa en minutos y se deshace fácil.
🧪 Probar de verdad
Lo que separa «parece que funciona» de «funciona».
De punta a punta
Cuándo: Al terminar cualquier cambio.
Prueba el cambio de punta a punta en el servidor real, con datos de prueba que borres al terminar, y muéstrame la salida. Dime con claridad qué NO pudiste probar.
Por qué funciona: Te obliga a separar lo verificado de lo supuesto.
Casos que deben fallar
Cuándo: Cuando algo escribe datos o toca permisos.
Escribe pruebas que deban FALLAR: datos inválidos, el id de otra cuenta, fechas absurdas, doble clic, sesión vencida. Confirma que el sistema los rechaza.
Por qué funciona: Probar solo el camino feliz deja abiertos los huecos de seguridad.
No digas «listo» sin verificar
Cuándo: Siempre.
No digas que algo está listo hasta haberlo verificado con una petición real. Si solo lo compilaste o lo leíste, dilo así.
Por qué funciona: La diferencia entre «revisado» y «probado» es la de un error en producción.
Repórtame lo malo
Cuándo: Cuando una prueba falla o algo no cuadra.
Si una prueba falla o un resultado no cuadra, muéstramelo tal cual con la salida completa. No lo maquilles ni lo omitas.
Por qué funciona: Un fallo visible se arregla; uno escondido crece.
🔒 Seguridad y confianza
Para que la IA ayude sin poner en riesgo tu sistema ni a tus usuarios.
Confirmar antes de actuar
Cuándo: Al diseñar cualquier acción automática.
Todo lo que escriba datos, mande algo al exterior o cueste dinero debe seguir este orden: proponer → mostrar el detalle exacto → pedir confirmación → ejecutar → poder deshacer.
Por qué funciona: La IA propone, la persona decide: así un error de la IA nunca es un error irreversible.
Auditoría de exposición
Cuándo: Cada cierto tiempo, y después de mucho trabajo con IA.
Busca en el servidor archivos que no deberían ser públicos: respaldos (.bak), scripts de una sola vez, logs, archivos .env, carpetas sin protección. Solo lista lo que encuentres; no borres nada sin que yo lo apruebe.
Por qué funciona: Lo que se olvida en el servidor es lo primero que encuentra un curioso.
Aislamiento entre cuentas
Cuándo: En cualquier sistema con varios clientes.
Revisa que cada consulta esté limitada al negocio del usuario que la hace, y que un id de otra cuenta nunca se acepte. Dame ejemplos de peticiones que deberían ser rechazadas.
Por qué funciona: El error más grave en un sistema multi-cliente es ver datos ajenos.
Secretos
Cuándo: Antes de compartir pantallas, código o logs.
Revisa que ninguna clave, contraseña o token aparezca en el código, en los logs, en comentarios ni en lo que me muestras. Si aparece alguno, avísame y no lo repitas.
Por qué funciona: Sobre todo si vas a grabar video o publicar tu trabajo.
🚀 Subir y documentar
Cerrar bien cada sesión de trabajo.
Despliegue seguro
Cuándo: Cada vez que subas algo.
Antes de subir: revisa la sintaxis de cada archivo cambiado, súbelos uno por uno mostrando los errores (sin silenciarlos), verifica cada dirección afectada y borra los datos de prueba. Dime qué subiste y qué verificaste.
Por qué funciona: Un error de subida silenciado se convierte en una página rota sin aviso.
Cierre de sesión
Cuándo: Al terminar de trabajar.
Resume lo que hicimos, lo que NO se probó y lo que quedó pendiente. Actualiza AI.md si cambió algo que deba saberse siempre, y agrega la entrada a la bitácora.
Por qué funciona: Es la memoria del proyecto: la sesión de mañana empieza donde terminó esta.
Para alguien que no estuvo
Cuándo: Después de una decisión importante.
Explica este cambio como si lo fuera a leer alguien que no estuvo aquí: qué problema resolvía, qué decisión se tomó y por qué, y qué no se debe romper.
Por qué funciona: Ese «alguien» eres tú dentro de seis meses.
🔧 Cuando algo falla
Para no adivinar ni empeorar las cosas.
Diagnóstico
Cuándo: Ante cualquier error.
No adivines. Reproduce el fallo, muéstrame el error exacto, dime la causa raíz y propón el arreglo mínimo. Si no puedes reproducirlo, dime qué necesitas.
Por qué funciona: Adivinar produce arreglos que ocultan el síntoma.
Mismo patrón, otros lugares
Cuándo: Después de arreglar un error.
Después de arreglarlo, revisa qué más pudo romperse por el mismo motivo y busca otros lugares con el mismo patrón.
Por qué funciona: Los errores casi nunca están solos.
Antes de borrar
Cuándo: Antes de eliminar archivos, carpetas o datos.
Antes de borrar algo, muéstrame qué es, dónde se usa y guarda un respaldo fuera de la carpeta pública. Espera mi confirmación.
Por qué funciona: Borrar es lo único que no se puede deshacer con «control + Z».
🐾 Ponle un asistente a tu app
Los tres prompts de diseño detrás de la mascota con IA de chzr.llc.
Asistente que responde con tus manuales
Cuándo: Cuando quieras que la app conteste dudas de uso.
Quiero un asistente dentro de mi app que responda dudas usando SOLO mis manuales. Diseña: cómo se buscan los fragmentos relevantes, qué recibe la IA, cómo evitar que invente y cómo enlazar solo a pantallas reales.
Por qué funciona: Enlazar solo a pantallas que existen y admitir «no lo encuentro» genera confianza.
Acciones con confirmación
Cuándo: Cuando quieras que el asistente haga cosas, no solo hable.
Diseña las acciones que el asistente puede proponer (crear una cotización, registrar un gasto…). Para cada una: datos obligatorios, qué valida el servidor, permisos, qué NO hace y cómo se deshace.
Por qué funciona: La lista de lo que NO hace es tan importante como la de lo que hace.
Límites de gasto
Cuándo: Antes de abrir el asistente a otras personas.
Diseña límites de uso de la IA por minuto, por día y por costo, con registro de tokens y una forma de ver quién gasta qué.
Por qué funciona: Sin topes, un ciclo o un abuso se vuelve una factura.
Ojo: una IA puede equivocarse aunque suene segura. Estos prompts reducen el riesgo, no lo eliminan: revisa lo que produce, prueba de verdad y no le des acceso a nada que no puedas deshacer.
¿Quieres ver cómo se construye?
Estamos grabando la construcción de esta plataforma, incluidos los errores. Si quieres asesoría para aplicar esto en tu negocio o tu proyecto, escríbenos.
