Use prompts Vibe para app CRUD para gerar telas, autenticação, permissões e uma API Postgres. Conjuntos prontos para copiar e colar, além de dicas de solução de problemas.
Este conjunto de prompts foi projetado para gerar um app CRUD completo e funcional: as telas que as pessoas usam, a API que lida com as requisições e o banco de dados PostgreSQL que armazena os dados. Inclui também login e controle por roles, para que usuários diferentes possam ver e fazer coisas distintas.
CRUD são apenas quatro ações do dia a dia que seu app precisa:
No front-end, você deve terminar com um conjunto previsível de telas: uma página de lista, uma página de detalhe, um formulário de criação, um formulário de edição, além de uma página de login e navegação básica. No back-end, você terá endpoints que correspondem a essas telas (list, get by id, create, update, delete), suportados por uma tabela Postgres e validações simples.
A qualidade do prompt importa mais do que a escolha do modelo. O modelo só pode seguir o que você especifica. Se seu prompt for vago, você terá nomes de campo desencontrados, rotas faltando, autenticação incompleta ou uma UI que não bate com a API. Um prompt bem fechado funciona como um contrato: UI, API e banco concordam nos mesmos nomes e regras.
Antes de começar, decida alguns detalhes para que a build permaneça consistente:
Se você estiver usando Koder.ai, isso pode ser uma única conversa que produz uma UI em React, uma API em Go e um esquema PostgreSQL que se encaixam sem cola manual.
Uma boa build CRUD começa com um pequeno conjunto de decisões. Escreva-as primeiro e seus prompts ficam claros, suas telas certas e sua API bate com o banco.
Comece com uma entidade central. Esta é a “coisa” que seu app gerencia todo dia (Item, Customer, Appointment). Acrescente uma segunda entidade só se for realmente necessária no dia um (por exemplo, Item precisa de Category). Se você começar com três ou quatro, passará a maior parte do tempo desembaraçando relacionamentos em vez de obter um app funcionando.
Escreva os campos da entidade com um tipo e um exemplo. O exemplo importa porque guia rótulos, formatação e validação.
Em seguida, liste roles e permissões em linguagem simples. Seja específico. Para muitos apps, 2 a 3 roles são suficientes:
Por fim, crie de 5 a 10 registros de exemplo. Eles orientam rótulos realistas na UI, opções de dropdown e padrões sensatos. Exemplo (inventário): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Se você estiver construindo no Koder.ai, cole esta folha na sua primeira prompt para que a plataforma mantenha o app consistente entre telas, auth e a API com suporte PostgreSQL.
Comece com uma prompt de “regras do caminho”. Ela mantém a build consistente entre telas, API e banco, e reduz idas e vindas quando você adicionar features depois.
Peça um plano curto antes de qualquer código. Você quer que o modelo nomeie telas e rotas, tabelas e endpoints da API. Exija também que declare suposições desde o início (como quais roles existem) e mantenha essas suposições inalteradas a menos que você aprove uma mudança.
Aqui está um prompt base pronto para copiar e colar:
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.
Um exemplo concreto: se o plano escolher role: admin|member, não deveria mais tarde inventar manager para resolver um caso da UI. Este prompt força o modelo a pausar e pedir sua aprovação em vez de derivar.
Boas telas vêm de um mapa de páginas claro primeiro. Use os prompts abaixo antes de pedir código do banco ou da API. Isso mantém rotas e nomes de UI estáveis depois, onde muitas builds saem do trilho.
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.
Depois que ele responder, trave os nomes. Se você mudar nomes de rota depois, a API e os testes vão divergir.
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.
Se a UI voltar muito complexa, peça para manter apenas um layout, um estilo de tabela e um padrão de formulário em todas as páginas.
Se você quer resultados previsíveis, seja explícito sobre como usuários entram, quanto tempo a sessão dura e o que cada role pode fazer. Estes prompts assumem um login simples por email + senha e uma abordagem baseada em sessão (fácil de testar entre telas e APIs).
Cole isto primeiro para gerar login, logout e tratamento de sessão:
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.
Agora adicione roles e regras de proteção. Mantenha permissões pequenas e fáceis de testar:
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.
Checagens manuais rápidas que pegam a maioria dos erros:
Se você estiver construindo no Koder.ai, mantenha mudanças de auth e RBAC em um snapshot para poder reverter facilmente se permissões se enrolarem.
Um bom prompt de esquema faz dois trabalhos: força relacionamentos claros (para que telas e API fiquem consistentes) e evita bancos “quase certos” (sem índices, timestamps ou mapeamento de roles).
Antes de colar, decida estes dois toggles (uma linha cada):
uuid ou bigserialyes (use deleted_at) ou no (hard delete)Cole este prompt primeiro para travar o modelo de dados:
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.
Depois cole este prompt para gerar migrations ou passos de setup que batam com o projeto:
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
Se algo estiver ambíguo, adicione mais uma linha: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Se seus outputs de backend continuam vindo pela metade, este prompt força o básico: rotas claras, validação, paginação e checagem de roles em todo handler.
Cole isto como está, então substitua os placeholders (RESOURCE, FIELDS, ROLES) pelos detalhes do seu 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
Depois da geração, faça uma passadinha rápida de consistência: códigos de status batem com o corpo de erro, o endpoint de listagem retorna ordenação estável, e cada handler checa tanto role quanto ownership do tenant antes de tocar no banco.
Se você estiver usando Koder.ai, destaque também que o backend deve continuar em Go e o banco em PostgreSQL para que o código exportado corresponda ao stack esperado.
Gere tudo (UI, API, banco), depois mude para modo de verificação estrita. O objetivo não é admirar telas. É provar que o loop completo funciona: UI - auth - roles - Postgres - API - UI.
Rode o app e carregue a tela inicial. Confirme que a navegação funciona e que você não vê dados de placeholder. Se a página estiver em branco, anote a primeira mensagem de erro visível (toast da UI, console ou log do servidor).
Crie uma conta de teste por role (Admin, Manager, Viewer). Faça login e logout com cada usuário. Confirme que o app mostra a role em algum lugar visível (menu de perfil, settings ou um pequeno badge).
Escolha uma tela CRUD e faça um ciclo completo: crie um registro, atualize a página, depois edite e delete. A checagem chave é persistência: depois do refresh, o registro deve refletir o que está no Postgres, não apenas na memória.
Tente ações proibidas de propósito. Faça login com a role mais baixa e tente acessar uma tela só para admins, chame uma ação restrita (como delete) e edite um registro que não deveria. Você quer resultados claros: ou a UI bloqueia com uma mensagem, ou a API retorna um erro 403 sem alteração de dados.
Teste casos de borda básicos: listas vazias, nomes muito longos, campos obrigatórios faltando e formatos inválidos (email, datas). Confirme que a app mostra validação útil e não trava.
Se você estiver usando Koder.ai, tire um snapshot logo depois do primeiro teste CRUD ponta-a-ponta bem-sucedido. Dá um ponto seguro de rollback antes de começar a adicionar extras.
A maioria das builds “quebradas” não está realmente quebrada. Falta uma constraint que mantenha UI, API e banco andando juntos.
Quando você solicita telas, auth, roles, schema e todos os edge cases de uma vez, o app frequentemente fica inconsistente (rotas não batem, modelos derivam, páginas pela metade).
Correção: divida por camada e force a ferramenta a reexplicar o que vai gerar antes de codificar. No Koder.ai, isso também ajuda a manter múltiplos agentes alinhados.
Se você apenas disser “admin e user”, pode aparecer um rótulo de role na UI mas sem autenticação no servidor.
Correção: defina permissões como ações (create, read, update, delete) por recurso, e exija aplicação server-side em cada endpoint.
Se você descrever campos em linguagem livre (“price”, “date”, “status”), formulários podem renderizar inputs de texto enquanto o Postgres espera números, datas ou enums.
Correção: especifique tipos de campo, nullability, defaults e constraints, e exija regras de validação compartilhadas.
Sem estados de loading e erro, uma requisição falhada parece uma página travada.
Correção: exija spinners de loading, estados vazios e mensagens de erro visíveis para cada tela.
Renomear “Projects” para “Workspaces” no meio frequentemente quebra rotas, handlers e nomes de tabela.
Correção: trave um glossário cedo. Quando mudar nomes, peça um plano de rename (search/replace, migração) em vez de deixar o modelo improvisar.
Use este prompt de reparo quando algo sair do trilho:
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.
Se você continuar enfrentando inconsistências, provavelmente está faltando uma “declaração de fonte única da verdade”. Adicione uma frase: “O esquema Postgres é a fonte da verdade; UI e API devem corresponder exatamente a ele.”
Antes de gastar tempo polindo, faça um rápido passe para confirmar que o app se comporta como um produto real. Aqui é onde a maioria dos apps CRUD full-stack falha: pequenas incompatibilidades entre telas, regras e dados.
Um teste concreto: faça login como a role de menor permissão e tente uma ação que espera bloquear (como delete). Se ela for bem-sucedida, corrija a política em um lugar (a API) primeiro, depois ajuste a UI para bater.
Imagine um pequeno time de TI que empresta laptops, monitores e adaptadores para a equipe. Eles precisam de um lugar para ver o que está disponível, quem tem o quê e quando deve devolver. É um bom caso de teste porque força roles, algumas telas e um banco real.
Use isto como entrada exata para seu passo de prep (copie como está, depois ajuste nomes):
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)
Cole seus prompts nesta ordem para manter o app consistente:
Um bom resultado parece com isto: um staff pode pedir “MBP-014”, o admin aprova com uma data de devolução, e a lista de inventário mostra o item indisponível com o nome do mutuário.
Se a build estiver quase, mas não correta, ajuste uma coisa por vez: endureça permissões (viewer nunca deveria ver botões de edição), reitere a regra “apenas um empréstimo ativo por item”, ou peça para renomear campos para que rótulos da UI e colunas do BD coincidam exatamente.
Uma vez que o básico funcione, trate mudanças seguintes como pequenas releases. Escolha uma feature, defina o que significa “done” e então prompt para ela.
Uma ordem sensata para muitos apps:
Quando uma mudança quebrar a build, não tente consertar tudo de uma vez. Faça rollback e reaplique a mudança em um prompt menor e mais específico. Se você usa Koder.ai, snapshots e rollback são uma rede de segurança prática, especialmente antes de mudanças que toquem esquema de DB, regras de auth ou componentes compartilhados de UI.
O Modo Planejamento também ajuda quando uma feature atravessa múltiplas camadas. Peça para que o modelo reescreva o plano primeiro (telas, endpoints API, mudanças de DB, roles), então aprove esse plano antes de gerar código. Isso previne a divergência comum em que a UI espera campos que a API não retorna, ou a API escreve em colunas que não existem.
Se quiser continuar fora da plataforma, exporte o código-fonte e faça mudanças no seu fluxo normal. Mantenha o conjunto de prompts junto ao repositório como “instruções de build” para poder recriar o app depois ou onboardar alguém novo.
Se você estiver construindo no Koder.ai (koder.ai), este conjunto de prompts se alinha bem aos defaults React + Go + PostgreSQL da plataforma, e é fácil iterar com segurança usando snapshots enquanto refina requisitos.
Finalmente, salve um prompt template reutilizável para o próximo projeto. Mantenha as partes estáveis (stack, regras CRUD, convenções de auth e roles, padrões Postgres) e troque só os substantivos do domínio. Com o tempo, seus prompts viram uma receita repetível em vez de um experimento único.
Comece com a entidade principal e seus 6–12 campos (nome, tipo, obrigatório/opcional, exemplos). Em seguida, trave roles + permissões em linguagem simples e peça um plano curto antes de qualquer código.\n\nUma ordem prática é gerar isto:
Porque força o modelo a tratar UI, API e banco de dados como um único contrato. Prompts vagos geralmente criam divergência:\n\n- A UI usa um nome de campo, a API espera outro\n- Rotas não batem com a navegação\n- Autenticação existe na UI, mas não é aplicada na API\n\nUm prompt bem fechado faz com que nomes, regras e validações coincidam entre as camadas.
Escolha uma entidade que você gerencia diariamente (Customer, Task, Item). Mantenha uma entidade no dia um, salvo se uma segunda for essencial para o fluxo.\n\nUma configuração prática padrão:
Porque exemplos guiam rótulos, formatação e validação. Se você só disser “date” ou “status”, frequentemente terá inputs de texto na UI enquanto o banco espera date/enum.\n\nUse um formato consistente por linha de campo:
Use no máximo 2–3 roles, mapeadas para os verbos CRUD list, view, create, update, delete.\n\nUm padrão sólido:
Implemente e teste ambos: \n\n- Proteção na UI: oculte itens de navegação e bloqueie rotas com uma página “Não permitido”\n- Proteção na API: retorne 401 quando não autenticado, 403 quando autenticado mas sem permissão\n\nRegra prática: se a UI bloqueia uma ação, a API ainda deve rejeitá-la se chamada diretamente.
Padronize para email + senha com persistência de sessão entre refreshs.\n\nRequisitos mínimos para pedir:
Escolha uma convenção e aplique em todo lugar:
Peça que todo endpoint de listagem use a mesma forma de resposta:
Use um prompt de auditoria que compare:\n\n- Rotas da UI vs caminhos da API\n- Campos de formulários vs JSON de requisição/resposta\n- Campos JSON vs colunas do BD\n- Regras de validação vs constraints do BD\n\nDepois aplique um plano mínimo de correção.\n\nUma boa regra: não adicione features enquanto corrige divergências — apenas alinhe nomes, rotas, validações e permissões.