# Plantilla de brief para construir un CRM con Claude Code Sirve para cualquier negocio que reciba mensajes y necesite hacerles seguimiento: tienda online, clínica, gimnasio, academia, agencia, taller, estudio de abogados, inmobiliaria o cualquier otro. Cómo se usa: 1. Rellena los corchetes del **Bloque 2**. Lo que no apliques, bórralo. 2. Abre Claude Code en una carpeta vacía, activa **plan mode** (`shift + tab`) y pega los bloques 1 a 5 juntos, en un solo mensaje. 3. Revisa el plan que devuelve. Recién cuando lo apruebes, pide fase por fase con los prompts del final. --- ## Bloque 1 · Rol y reglas de trabajo ``` Vas a construir un CRM multicanal desde cero. Trabaja como desarrollador senior a cargo de todo el proyecto: arquitectura, base de datos, frontend, integraciones y deploy. Reglas de trabajo: - Antes de escribir código, devuélveme un plan por fases. No escribas nada hasta que yo apruebe el plan. - Si algo del brief está incompleto o es ambiguo, pregúntame antes de asumir. Máximo 5 preguntas, las más importantes primero. - Una fase a la vez. Cada fase termina con algo que yo pueda abrir y probar. - No inventes funcionalidades que no estén en el brief. Si crees que falta algo importante, propónmelo como sugerencia aparte, no lo construyas. - Explícame en una línea qué hiciste al cerrar cada fase, sin pegarme el código completo. ``` --- ## Bloque 2 · El brief del negocio ``` ## Negocio - Rubro: [en qué industria opera] - Qué vende: [producto o servicio, y si es venta única o recurrente] - Tamaño del equipo que va a usar el CRM: [cuántas personas y qué hacen] - Cómo llegan los clientes hoy: [anuncios, redes, referidos, web, local físico] - Volumen aproximado: [mensajes o clientes nuevos al mes] ## El problema que resuelve el CRM - [qué se pierde hoy: leads sin respuesta, seguimiento que nadie hace, información repartida en varios teléfonos, falta de visibilidad del dueño] - [qué hacen hoy en vez de un CRM: planilla, cuaderno, WhatsApp personal] ## Usuarios y roles - Rol 1: [nombre del rol y qué puede ver y hacer] - Rol 2: [nombre del rol y qué puede ver y hacer] - Rol 3: [si aplica] - Regla de asignación: [cómo se reparten los clientes entre el equipo] ## Canales de mensajería - [qué canales se conectan y por cuál entra la mayoría del volumen] - Quién responde primero: [el agente de IA, una persona, o mixto] ## Módulos que SÍ van - [lista solo lo que el negocio usa de verdad: bandeja, contactos, pipeline, agenda, catálogo, plantillas, reportes, lo que corresponda] ## Módulos que NO van - [lo que explícitamente no quieres construir, para que no se infle el sistema] ## Pipeline - Etapas: [las etapas reales por las que pasa un cliente desde que escribe hasta que compra] - Qué mueve a un cliente de etapa: [a mano por el equipo, o automático cuando ocurre algo] ## KPIs del dashboard - [qué necesita ver el dueño para saber si el negocio va bien] - [qué necesita ver quien atiende para organizar su día] ## El agente de IA - Objetivo: [qué debe lograr en la conversación] - Tono: [cómo habla la marca, formal o cercano, y en qué idioma] - Herramientas que necesita: [acciones concretas: consultar información, agendar, cotizar, registrar datos, derivar a una persona] - Cuándo NO debe responder: [temas que siempre pasan a una persona] - Qué información puede usar: [catálogo, precios, horarios, preguntas frecuentes] ## Integraciones - [calendario, planillas, pasarela de pago, sistema que ya usan, u otras] ## Datos que ya existen - [si hay clientes en una planilla o en otro sistema, y si hay que migrarlos] ## Diseño e interfaz - Referencia visual: [adjunta una captura de un diseño que te guste, de Dribbble, Behance o de un producto real, y dime "quiero este estilo"] - Qué me gusta de esa referencia: [la densidad de información, los colores, la barra lateral, las tarjetas, lo que sea] - Identidad de marca: [colores, tipografía y logo si el cliente los tiene; si no, propón una paleta sobria] - Modo: [claro, oscuro, o ambos] - Densidad: [compacta para quien mira muchos registros al día, o amplia y espaciada] - Navegación: [barra lateral fija, menú superior, u otra] - Pantalla principal al entrar: [qué es lo primero que quiero ver al abrir] - En celular: [qué se simplifica y qué no puede faltar] - Qué NO quiero: [ej. nada de gráficos decorativos, nada de menús con 20 items, nada de tablas que obliguen a hacer scroll horizontal] ## Horarios y reglas del negocio - [horario de atención, tiempos de respuesta esperados, qué pasa fuera de horario] ``` --- ## Bloque 3 · Reglas técnicas del proyecto ``` ## Stack (esto no se negocia, ya está decidido) - Framework: [ej. Next.js con App Router y TypeScript] - Backend y base de datos: Supabase Cloud (no self-hosted, no otra base) - Autenticación: Supabase Auth - Mensajería: Zernio. WhatsApp, Instagram y Messenger se conectan exclusivamente por la API de Zernio. No se usa la API de Meta directa, no se usan librerías no oficiales, no se levanta ninguna sesión propia. - Repositorio: GitHub - Deploy: Vercel - Entrega en móvil: PWA instalable con notificaciones push ## Base de datos: todo por CLI - Todas las tablas, relaciones, índices, políticas RLS, funciones y triggers se crean con la CLI de Supabase, mediante archivos de migración versionados en el repositorio. - Nada se crea a mano desde el panel de Supabase. Si algo se creó a mano, hay que llevarlo a una migración. - Cada cambio de esquema es una migración nueva. No se editan migraciones ya aplicadas. - Antes de crear las tablas, muéstrame el esquema completo para aprobarlo. - Dime exactamente qué comandos vas a ejecutar y cuáles tengo que correr yo. ## Credenciales Te voy a pasar en el siguiente mensaje: - Supabase: URL del proyecto, anon key, service role key y el project ref para enlazar la CLI. - Zernio: API key. Conéctate por API directa, no por MCP. ## Convenciones - Toda la interfaz en [idioma]. - Móvil primero: el equipo trabaja desde el celular. - RLS activo en todas las tablas: nadie ve los datos de otro salvo que su rol lo permita. - La service role key se usa solo en el servidor, nunca en el cliente. - Variables sensibles en variables de entorno, jamás en el código. - Nombres de tablas y columnas en inglés, en snake_case. - Los webhooks de Zernio se reciben en rutas del proyecto y se validan antes de procesar el mensaje. ``` ## Bloque 4 · Qué quiero que me devuelvas ``` Devuélveme, en este orden: 1. Las preguntas que necesites para cerrar el brief (máximo 5). 2. El modelo de datos: tablas, columnas clave y relaciones, en una lista. 3. El plan por fases. Para cada fase: - Qué construye - Qué voy a poder probar yo al terminarla - Qué credenciales o decisiones mías necesitas antes de empezarla 4. Los riesgos o supuestos que estás tomando. Nada de código todavía. ``` --- ## Bloque 5 · Fases sugeridas ``` Salvo que propongas algo mejor, quiero avanzar en este orden: Fase 1 — Base del proyecto, login y roles. Fase 2 — Migraciones con la CLI de Supabase: tablas, relaciones y políticas RLS. Fase 3 — Bandeja de conversaciones y ficha de contacto. Fase 4 — Pipeline y asignación de clientes al equipo. Fase 5 — Conexión de canales con Zernio (webhooks y enlace de conexión). Fase 6 — Agente de IA con sus herramientas y el botón para apagarlo. Fase 7 — Dashboard y reportes. Fase 8 — PWA, notificaciones push y deploy en Vercel. ``` --- ## Prompts de seguimiento Úsalos uno por uno, cuando la fase anterior ya esté probada. **Empezar una fase** ``` Avancemos con la Fase [N]. Antes de escribir código, dime en 3 líneas qué vas a hacer y qué archivos vas a tocar. ``` **Cerrar una fase** ``` Dame los pasos exactos para probar la Fase [N] en mi navegador. Si hay algo que dejaste a medias o simulado con datos falsos, dímelo ahora. ``` **Cuando algo falla** ``` Esto es lo que pasa: [describe el error y qué estabas haciendo]. Este es el mensaje exacto: [pega el error]. No cambies nada todavía: dime primero cuál crees que es la causa y qué vas a revisar. ``` **Cuando se desordena el código** ``` Revisa [archivo o módulo] y dime si hay lógica duplicada, componentes que hacen lo mismo o archivos que quedaron sin uso. Propónme la limpieza antes de hacerla. ``` **Antes del deploy** ``` Revisa que no haya credenciales en el código, que la service role key solo se use en el servidor y que las políticas de acceso estén activas en todas las tablas. Dame el listado de lo que encontraste. ``` **Para el diseño, antes de construir** ``` Te paso una captura de referencia. Antes de escribir código, descríbeme qué ves en ella: estructura, jerarquía, paleta y densidad. Después propónme cómo la adaptarías a este CRM, sin copiarla literal. ``` **Para revisar el diseño ya construido** ``` Abre [pantalla] y revísala como si fueras el usuario que la va a usar 8 horas al día. Dime qué está de más, qué cuesta encontrar y qué se rompe en pantalla de celular. Propón los cambios antes de aplicarlos. ``` **Para mantener la consistencia** ``` Antes de crear pantallas nuevas, define un set de componentes base (botones, tarjetas, tablas, formularios, estados vacíos) y reutilízalos siempre. Si necesitas uno nuevo, dímelo en vez de improvisarlo en la pantalla. ``` **Para adaptarlo a otro negocio después** ``` Quiero reutilizar este CRM para [nuevo rubro]. Dime qué partes son genéricas, qué está atado al negocio anterior y qué habría que cambiar, antes de tocar nada. ``` --- ## Antes de pegar, revisa - [ ] Los módulos que NO van están escritos. Es lo que evita que el CRM se infle. - [ ] Tienes a mano la captura de referencia del diseño. - [ ] Las etapas del pipeline son las reales del negocio, no las de un ejemplo. - [ ] Cada KPI se puede calcular con datos que el CRM va a tener. - [ ] Las herramientas del agente están descritas como acciones concretas. - [ ] Definiste si el deploy va en Vercel o en un VPS. - [ ] Tienes a mano las credenciales de Supabase (incluido el project ref) y la API key de Zernio. - [ ] Tienes la CLI de Supabase instalada y el proyecto enlazado.