Prompts Vibe para app CRUD: conjunto completo para copiar y pegar

Qué construye este conjunto de prompts (en lenguaje simple)

Este conjunto de prompts está diseñado para generar una app CRUD completa y funcional: las pantallas que usa la gente, la API que maneja las peticiones y la base de datos PostgreSQL que almacena los datos. También incluye login y acceso basado en roles, para que distintos usuarios puedan ver y hacer cosas diferentes.

CRUD son solo cuatro acciones cotidianas que tu app necesita:

• Create: agregar un registro nuevo (como un cliente o tarea)
• Read: ver una lista y abrir un único elemento
• Update: editar un elemento existente
• Delete: eliminar un elemento (a menudo con un paso de confirmación)

En el front-end, deberías acabar con un conjunto predecible de pantallas: una página de lista, una página de detalle, un formulario de creación, un formulario de edición, además de una página de login y navegación básica. En el back-end, tendrás endpoints que coinciden con esas pantallas (list, get by id, create, update, delete), respaldados por una tabla Postgres y validaciones simples.

La calidad del prompt importa más que la elección del modelo. El modelo solo puede seguir lo que especifiques. Si tu prompt es vago, obtendrás nombres de campos que no coinciden, rutas faltantes, auth incompleta o una UI que no encaja con la API. Un prompt ajustado actúa como un contrato: UI, API y base de datos acuerdan los mismos nombres y reglas.

Antes de empezar, decide algunos detalles para que la construcción sea consistente:

• Tu entidad principal y 6 a 12 campos (nombres, tipos, requerido vs opcional)
• Roles (por ejemplo: admin, manager, viewer) y qué puede hacer cada rol
• Reglas básicas (quién puede editar, borrado suave vs borrado hard, campos obligatorios)
• Las pantallas del “camino feliz” que necesitas el primer día
• Cualquier restricción (campos únicos, rangos de fecha, valores de estado)

Si usas Koder.ai, esto puede ser una sola conversación que produce una UI en React, una API en Go y un esquema PostgreSQL que encajen sin pegamentos manuales.

Hoja de preparación: los pocos detalles que necesitas antes de pedir

Un buen build CRUD comienza con un pequeño conjunto de decisiones. Escríbelas primero y tus prompts se mantienen claros, tus pantallas se ven bien y tu API coincide con la base de datos.

Empieza con una entidad central. Esto es la “cosa” que tu app gestiona a diario (Item, Customer, Appointment). Añade una segunda entidad solo si realmente es necesaria el primer día (por ejemplo, Item necesita Category). Si empiezas con tres o cuatro, pasarás la mayor parte del tiempo desenredando relaciones en lugar de obtener una app funcional.

Escribe los campos de tu entidad con un tipo y un ejemplo. El ejemplo importa porque guía etiquetas, formato y validación.

• Field: type - example (notas)
• name: text - "Paper towels" (requerido, 2-80 chars)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (opcional)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

A continuación, lista roles y permisos en lenguaje simple. Manténlo específico. Para muchas apps, 2 a 3 roles son suficientes:

• Admin: gestionar usuarios, CRUD completo en todos los registros
• Manager: CRUD en registros, no puede gestionar usuarios
• Viewer: solo lectura

Finalmente, crea de 5 a 10 registros de ejemplo. Estos impulsan etiquetas realistas en la UI, opciones de dropdown y valores por defecto sensatos. Ejemplo (inventario): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Si construyes en Koder.ai, pega esta hoja en tu primer prompt para que la plataforma pueda mantener la app consistente entre pantallas, auth y la API respaldada por PostgreSQL.

Prompt base: fija las reglas para toda la construcción

Empieza con un prompt de “reglas del camino”. Mantiene la construcción consistente entre pantallas, API y base de datos, y reduce el ida y vuelta cuando añades funciones después.

Pide un plan corto antes de cualquier código. Quieres que el modelo nombre pantallas y rutas, tablas y endpoints de API. También exige que explique las suposiciones desde el inicio (por ejemplo, qué roles existen) y que mantenga esas suposiciones sin cambios a menos que apruebes una modificación.

Aquí tienes un prompt base para copiar/pegar:

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

Un ejemplo concreto: si el plan elige role: admin|member, no debería luego inventar manager para resolver un caso borde de la UI. Este prompt obliga a pausar y pedir tu aprobación en lugar de desviarse.

Prompts para copiar/pegar: pantallas y navegación

Las buenas pantallas nacen de un mapa de páginas claro primero. Usa los prompts abajo antes de pedir código de base de datos o API. Esto mantiene las rutas y nombres de UI estables después, que es donde muchos builds se descarrilan.

Prompt 1: lista de páginas y flujos de usuario

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

Después de que responda, bloquea los nombres. Si cambias nombres de rutas más tarde, la API y las pruebas se desalinearán.

Prompt 2: navegación y formularios que funcionan bien

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

Si la UI que vuelve es demasiado compleja, pídele que mantenga solo un layout, un estilo de tabla y un patrón de formulario en todas las páginas.

Prompts para copiar/pegar: autenticación y roles

Si quieres resultados predecibles, sé explícito sobre cómo inician sesión los usuarios, cuánto duran las sesiones y qué puede hacer cada rol. Estos prompts asumen un login simple por email + password y un enfoque basado en sesión (fácil de probar en pantallas y APIs).

Pega esto primero para generar login, logout y manejo de sesión:

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

Ahora agrega roles y reglas de protección. Mantén los permisos pequeños y fáciles de probar:

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

Comprobaciones manuales rápidas que detectan la mayoría de errores:

• Inicia sesión como cada rol y confirma lo que puedes y no puedes ver.
• Intenta una acción restringida de todos modos (como delete) y confirma que obtienes 403.
• Confirma que logout borra la sesión y que la app vuelve a la pantalla de Login.

Si construyes en Koder.ai, mantén auth y cambios RBAC en un solo snapshot para poder revertir limpiamente si los permisos se enredan.

Prompts para copiar/pegar: esquema PostgreSQL y modelo de datos

Un buen prompt de esquema hace dos cosas: fuerza relaciones de tablas claras (para que UI y API sigan consistentes) y evita bases de datos “casi correctas” (sin índices, timestamps o mapeo de roles).

Antes de pegar, decide estos dos toggles (una línea cada uno):

• Primary keys: uuid o bigserial
• Soft delete: yes (usar deleted_at) o no (hard delete)

Pega este primer prompt para bloquear el modelo de datos:

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

Luego pega este prompt para generar migraciones o pasos de setup que coincidan con el proyecto:

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

Si algo queda ambiguo, añade una línea más: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Prompts para copiar/pegar: API CRUD en Go (con Postgres)

Si tus outputs de backend siguen llegando a medias, este prompt fuerza lo básico: rutas claras, validación, paginación y checks de roles en cada handler.

Copia/pega esto tal cual, luego reemplaza los placeholders (RESOURCE, FIELDS, ROLES) con los detalles de tu app.

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

Tras la generación, haz una pasada rápida por consistencia: los códigos de estado coinciden con el cuerpo de error, el endpoint de lista devuelve un orden estable y cada handler verifica tanto rol como pertenencia al tenant antes de tocar la BD.

Si usas Koder.ai, además indica que el backend debe seguir en Go y la BD en PostgreSQL para que el código exportado coincida con el stack esperado.

Paso a paso: generar, ejecutar y verificar

Genera todo (UI, API, base de datos) y luego cambia a modo verificación estricto. El objetivo no es admirar pantallas, sino probar que el ciclo completo funciona: UI - auth - roles - Postgres - API - UI.

Una verificación simple

1. Ejecuta la app y carga la pantalla de inicio. Confirma que la navegación funciona y que no ves datos de placeholder. Si la página está en blanco, anota el primer mensaje de error visible (toast UI, consola o log del servidor).

2. Crea una cuenta de prueba por rol (Admin, Manager, Viewer). Inicia sesión y cierra sesión con cada usuario. Confirma que la app muestra el rol en algún lugar visible (menú de perfil, ajustes o una pequeña insignia).

3. Elige una pantalla CRUD y realiza un ciclo completo: crea un registro, refresca la página, luego edítalo y elimínalo. La verificación clave es la persistencia: después del refresh, el registro debe reflejar lo que hay en Postgres, no solo en memoria.

4. Intenta acciones prohibidas a propósito. Inicia sesión con el rol más bajo e intenta acceder a una pantalla solo de admin, invocar una acción restringida (como delete) o editar un registro que no deberías. Quieres resultados claros: o bien UI bloqueada con mensaje, o bien un error 403 sin cambios de datos.

5. Prueba casos límite: listas vacías, nombres muy largos, campos obligatorios faltantes y formatos inválidos (email, fechas). Confirma que la app muestra validaciones útiles y no se cae.

Si usas Koder.ai, toma un snapshot justo después del primer test CRUD end-to-end exitoso. Te da un punto de rollback seguro antes de empezar a añadir extras.

Fallos comunes en prompts y cómo arreglarlos

La mayoría de builds “rotos” no están realmente rotos. Les falta una restricción que mantenga UI, API y BD sincronizados.

1) Pediste demasiado de una sola vez

Cuando pides pantallas, auth, roles, esquema y todos los casos borde de una vez, la app suele quedar inconsistente (rutas no coinciden, modelos cambian, páginas a medias).

Arreglo: divide por capa y obliga a la herramienta a re-ejecutar lo que va a generar antes de escribir código. En Koder.ai, esto también ayuda a alinear múltiples agentes.

2) Los roles son vagos, así que faltan checks

Si solo dices “admin y user”, puede que obtengas una etiqueta de rol en la UI pero ninguna autorización en el servidor.

Arreglo: define permisos como acciones (create, read, update, delete) por recurso y exige aplicación server-side en cada endpoint.

3) Tipos de campo faltantes causan deriva entre UI y BD

Si describes campos en inglés plano (“price”, “date”, “status”), los formularios pueden renderizar inputs de texto mientras Postgres espera números, fechas o enums.

Arreglo: especifica tipos de campo, nullabilidad, valores por defecto y restricciones, y exige reglas de validación compartidas.

4) Sin estados de carga ni error, la UI parece rota

Sin estados de carga y error, una petición fallida parece una página congelada.

Arreglo: pide spinners de carga, estados vacíos y mensajes de error visibles para cada pantalla.

5) Los nombres cambian a mitad del build

Renombrar “Projects” a “Workspaces” a mitad de camino suele romper rutas, handlers y nombres de tablas.

Arreglo: bloquea un glosario temprano. Cuando cambies nombres, solicita un plan de renombrado (search/replace, migrar) en vez de dejar que el modelo improvise.

Usa este prompt de reparación cuando algo se descarríe:

Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.

Si sigues encontrando inconsistencias, probablemente te falta una “fuente única de la verdad”. Añade una frase: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Lista rápida antes de dar por terminado

Antes de pulir, haz una pasada rápida para confirmar que la app se comporta como un producto real. Aquí fallan la mayoría de apps CRUD: pequeñas descoordinaciones entre pantallas, reglas y datos.

• Las pantallas coinciden con la especificación de la entidad: cada pantalla (list, details, create, edit) usa los mismos nombres de entidad y la lista de campos que definiste.
• Los roles son inequívocos: escribe una tabla simple allow/deny por rol y confirma que UI y API aplican las mismas reglas.
• Las respuestas de la API son consistentes: elige un patrón (códigos de estado, forma de error, forma de paginación) y verifica que todos los endpoints lo sigan.
• Las restricciones BD coinciden con la validación del formulario: si la BD requiere email único o nombre no nulo, valida antes de enviar y muestra mensajes claros cuando la API lo rechace.
• Create/edit/delete sobreviven a un refresh: crea un registro, refresca y confirma que sigue ahí; edita, refresca y confirma; elimina, refresca y confirma.

Una prueba concreta: inicia sesión con el rol con menos permisos e intenta una acción que esperas bloqueada (por ejemplo eliminar). Si tiene éxito, arregla la política en un lugar (la API) primero y luego ajusta la UI para que coincida.

Ejemplo realista: un inventario simple

Imagina un pequeño equipo de TI que presta laptops, monitores y adaptadores al personal. Necesitan un lugar para ver qué está disponible, quién tiene qué y cuándo debe devolverse. Es un buen caso de prueba porque fuerza roles, unas pocas pantallas y una base de datos real.

Hoja de preparación completada

Usa esto como entrada exacta para tu paso de prep (cópialo tal cual y ajusta nombres):

App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

Orden para pegar prompts

Pega tus prompts en este orden para que la app se mantenga consistente:

1. Prompt base (reglas globales, stack, nombres, manejo de errores)
2. Pantallas y navegación (Inventory, Requests, Loans, Admin queue)
3. Autenticación y roles (admin, staff, viewer permissions)
4. Esquema PostgreSQL y datos seed (items, loans, requests, users)
5. API CRUD en Go (endpoints y validación que coincidan con las reglas)

Un buen resultado se ve así: staff puede solicitar “MBP-014”, el admin lo aprueba con una fecha de retorno y la lista de inventario lo muestra como no disponible con el nombre del prestatario.

Si el build está cerca pero no correcto, ajusta una cosa a la vez: endurece permisos de roles (viewer nunca debería ver botones de edición), reafirma la regla “solo un préstamo activo por item”, o pide renombrar campos para que etiquetas UI y columnas BD coincidan exactamente.

Próximos pasos: extender con seguridad y reutilizar el set de prompts

Cuando lo básico funcione, trata los siguientes cambios como pequeñas releases. Elige una función, define qué significa “hecho” y luego pídela.

Un orden sensato para muchas apps:

• Audit log: registrar quién cambió qué y cuándo (create, update, delete), y mostrarlo en una pantalla solo para admins.
• Subida de archivos: adjuntar un documento o imagen a un registro, almacenar metadatos en Postgres y mantener acceso detrás de auth.
• Notificaciones simples: alertas in-app (por ejemplo “stock bajo” o “nuevo comentario”), con acción “marcar como leído”.

Cuando un cambio rompe el build, no intentes arreglar todo a la vez. Hace rollback y reaplica el cambio con un prompt más pequeño y específico. Si usas Koder.ai, los snapshots y rollback son una red de seguridad práctica, sobre todo antes de cambios que toquen el esquema BD, reglas de auth o componentes compartidos.

El modo Planning también ayuda cuando una característica abarca múltiples capas. Pídele que replantee el plan primero (pantallas, endpoints API, cambios en BD, roles), y aprueba ese plan antes de generar código. Esto evita el desajuste común donde la UI espera campos que la API no devuelve, o la API escribe en columnas que no existen.

Si quieres continuar fuera de la plataforma, exporta el código fuente y haz cambios en tu flujo habitual. Conserva el set de prompts junto al repo como “instrucciones de construcción” para recrear la app más tarde o para incorporar a alguien nuevo.

Si construyes en Koder.ai (koder.ai), este set de prompts encaja bien con los defaults React + Go + PostgreSQL de la plataforma y es fácil iterar con seguridad usando snapshots mientras afinás requisitos.

Finalmente, guarda un prompt plantilla reutilizable para tu próximo proyecto. Mantén las partes estables (stack, reglas CRUD, convenciones de auth y roles, patrones PostgreSQL) y cambia solo los sustantivos del dominio. Con el tiempo, tus prompts se convierten en una receta repetible en vez de un experimento puntual.