Usa i prompt Vibe per app CRUD per generare schermate, autenticazione, ruoli e un'API Postgres. Set di prompt da copiare e incollare più suggerimenti per la risoluzione dei problemi.
Questo set di prompt è pensato per generare un'app CRUD completa e funzionante: le schermate che gli utenti usano, l'API che gestisce le richieste e il database PostgreSQL che conserva i dati. Include anche login e controllo accessi basato sui ruoli, così utenti diversi possono vedere e fare cose diverse.
CRUD sono solo quattro azioni quotidiane che la tua app deve supportare:
Sul front end dovresti ottenere un set prevedibile di schermate: una pagina lista, una pagina dettaglio, un form di creazione, un form di modifica, più una pagina di login e una navigazione di base. Sul back end avrai endpoint che corrispondono a quelle schermate (list, get by id, create, update, delete), sostenuti da una tabella Postgres e semplici validazioni.
La qualità del prompt conta più della scelta del modello. Il modello può eseguire solo ciò che specifichi. Se il prompt è vago, otterrai nomi di campo discordanti, rotte mancanti, auth incompleta o una UI che non coincide con l'API. Un prompt preciso funziona come un contratto: UI, API e database concordano sugli stessi nomi e regole.
Prima di iniziare, decidi alcuni dettagli in modo che la build resti coerente:
Se usi Koder.ai, questa può essere una singola conversazione che produce una UI React, un'API Go e uno schema PostgreSQL che si incastrano senza colla manuale.
Una buona build CRUD inizia con un piccolo set di decisioni. Scrivile prima e i tuoi prompt resteranno chiari, le schermate corrette e l'API coinciderà con il database.
Parti da un'entità core. È la “cosa” che la tua app gestisce ogni giorno (Item, Customer, Appointment). Aggiungi una seconda entità solo se è veramente necessaria al giorno uno (per esempio Item ha bisogno di Category). Se inizi con tre o quattro, passerai la maggior parte del tempo a districare relazioni invece di ottenere un'app funzionante.
Scrivi i campi dell'entità con un tipo e un esempio. L'esempio conta perché guida etichette, formattazione e validazione.
Poi elenca i ruoli e i permessi in linguaggio semplice. Mantienilo specifico. Per molte app 2–3 ruoli sono sufficienti:
Infine, crea 5–10 record di esempio. Questi guidano etichette realistiche in UI, opzioni nei dropdown e valori di default sensati. Esempio (inventario): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Se stai costruendo in Koder.ai, incolla questa scheda nel tuo primo prompt così la piattaforma può mantenere l’app coerente tra schermate, auth e l'API con backing PostgreSQL.
Inizia con un prompt unico di “regole della strada”. Mantiene la build coerente tra schermate, API e database e riduce i continui aggiustamenti quando aggiungi funzionalità.
Chiedi un breve piano prima di qualsiasi codice. Vuoi che il modello nomini schermate e rotte, tabelle e endpoint. Richiedi inoltre che dichiari le assunzioni iniziali (per esempio quali ruoli esistono) e che non le cambi senza il tuo ok.
Ecco un prompt base da copiare e incollare:
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 esempio concreto: se il piano sceglie role: admin|member, non dovrebbe poi inventare manager per risolvere un caso limite. Questo prompt obbliga il modello a fermarsi e chiedere approvazione invece di deviare.
Buone schermate nascono da una mappa delle pagine chiara. Usa i prompt qui sotto prima di chiedere codice per database o API. Questo mantiene rotte e nomi UI stabili, dove molti progetti falliscono.
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.
Dopo la risposta, blocca i nomi. Se cambi i nomi delle rotte dopo, API e test andranno fuori sincronia.
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 la UI proposta è troppo complessa, chiedi di mantenere un solo layout, uno stile di tabella e un singolo pattern per i form su tutte le pagine.
Per risultati prevedibili, sii esplicito su come gli utenti fanno login, quanto durano le sessioni e cosa può fare ogni ruolo. Questi prompt assumono un login semplice via email + password e un approccio a sessione (facile da testare tra UI e API).
Incolla questo per generare login, logout e gestione della sessione:
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.
Ora aggiungi i ruoli e le regole di protezione. Mantieni i permessi piccoli e facili da testare:
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.
Controlli manuali rapidi che catturano la maggior parte degli errori:
Se costruisci in Koder.ai, tieni auth e RBAC in uno snapshot così puoi tornare indietro se i permessi si incasinano.
Un buon prompt per lo schema fa due cose: obbliga a definire relazioni chiare (così UI e API restano coerenti) e previene database "quasi corretti" (mancanza di indici, timestamp o mapping dei ruoli).
Prima di incollare, decidi queste due opzioni (una riga ciascuna):
uuid or bigserialyes (use deleted_at) or no (hard delete)Incolla per primo questo prompt per fissare il modello dei dati:
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.
Poi incolla questo prompt per generare migration o step di setup coerenti con il progetto:
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 qualcosa è ambiguo, aggiungi una riga: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Se i tuoi backend output continuano a tornare incompleti, questo prompt impone le basi: rotte chiare, validazione, paginazione e controlli di ruolo in ogni handler.
Copia e incolla così com'è, poi sostituisci i placeholder (RESOURCE, FIELDS, ROLES) con i dettagli della tua 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
Dopo la generazione, fai una rapida verifica di coerenza: i codici di stato devono corrispondere al body di errore, l'endpoint list ritorna un ordinamento stabile e ogni handler verifica sia ruolo sia appartenenza tenant prima di toccare il DB.
Se usi Koder.ai, segnala che il backend deve rimanere in Go e il database in PostgreSQL così il codice esportato corrisponde allo stack atteso.
Genera tutto (UI, API, database), poi passa in modalità verifica rigorosa. L'obiettivo non è ammirare le schermate: è dimostrare che il ciclo completo funziona: UI - auth - ruoli - Postgres - API - UI.
Esegui l'app e carica la home. Conferma che la navigazione funziona e che non vedi dati placeholder. Se la pagina è vuota, annota il primo messaggio d'errore visibile (toast UI, console o log server).
Crea un account di test per ogni ruolo (Admin, Manager, Viewer). Effettua login e logout con ciascun utente. Conferma che l'app mostra il ruolo in modo visibile (menu profilo, impostazioni o un piccolo badge).
Scegli una schermata CRUD e fai un ciclo completo: crea un record, ricarica la pagina, poi modifica ed elimina. Il controllo chiave è la persistenza: dopo il refresh il record deve riflettere ciò che è in Postgres, non solo in memoria.
Prova azioni proibite intenzionalmente. Fai login con il ruolo più basso e tenta di accedere a una schermata admin, esegui un'azione ristretta (es. delete) o modifica un record che non dovresti. Vuoi risultati chiari: o UI bloccata con messaggio, o errore in stile 403 senza modifica dei dati.
Testa casi limite: liste vuote, nomi molto lunghi, campi obbligatori mancanti e formati non validi (email, date). Conferma che l'app mostra validazioni utili e non va in crash.
Se usi Koder.ai, crea uno snapshot subito dopo il primo test end-to-end riuscito. Ti dà un punto di rollback sicuro prima di aggiungere extra.
La maggior parte delle build “rotte” non è veramente rotta. Manca un vincolo che mantiene UI, API e DB allineati.
Quando richiedi schermate, auth, ruoli, schema e ogni caso limite in un colpo solo, l'app spesso diventa incoerente (rotte non combaciano, modelli divergono, pagine incomplete).
Correzione: spezza per layer e forza lo strumento a ripetere cosa genererà prima di scrivere codice. In Koder.ai questo aiuta anche a tenere allineati più agent.
Se dici solo “admin e user”, potresti ottenere un'etichetta ruolo nella UI ma nessuna autorizzazione server-side.
Correzione: definisci permessi come azioni (create, read, update, delete) per risorsa e richiedi enforcement server-side su ogni endpoint.
Se descrivi campi in linguaggio naturale (“price”, “date”, “status”), i form possono rendere input testuali mentre Postgres si aspetta numeri, date o enum.
Correzione: specifica tipi campo, nullabilità, default e vincoli; richiedi regole di validazione condivise.
Senza loading e stati d'errore, una richiesta fallita sembra una pagina bloccata.
Correzione: richiedi spinner di caricamento, stati vuoti e messaggi d'errore visibili per ogni schermata.
Rinominare “Projects” in “Workspaces” a metà strada spesso rompe rotte, handler e nomi di tabelle.
Correzione: blocca un glossario all'inizio. Quando cambi nomi, richiedi un piano di rename (search/replace, migrate) invece di far improvvisare il modello.
Usa questo prompt di riparazione quando qualcosa va storto:
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 continui a incontrare incoerenze, probabilmente ti manca una frase "single source of truth". Aggiungi: “The Postgres schema is the source of truth; UI and API must match it exactly.”
Prima di rifinire, fai un giro veloce per confermare che l'app si comporta come un prodotto reale. Qui falliscono la maggior parte delle app full-stack CRUD: piccole discrepanze tra schermate, regole e dati.
Un test concreto: fai login con il ruolo con i permessi minimi e tenta un'azione che dovrebbe essere bloccata (es. delete). Se riesce, correggi la policy prima sul server (API) e poi allinea la UI.
Immagina un piccolo team IT che presta laptop, monitor e adattatori al personale. Hanno bisogno di un posto dove vedere cosa è disponibile, chi ha cosa e quando deve essere restituito. È un buon caso perché richiede ruoli, alcune schermate e un vero database.
Usa questo input esatto per il tuo passo di prep (copia così com'è e poi modifica i nomi):
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)
Incolla i prompt in questo ordine così l'app rimane coerente:
Un risultato buono assomiglia a questo: uno staff può richiedere “MBP-014”, l'admin lo approva con una data di scadenza e la lista inventario lo mostra come non disponibile con il nome del prenditore.
Se la build è quasi giusta ma non perfetta, modifica una cosa per volta: stringi i permessi (viewer non deve mai vedere i pulsanti di modifica), ribadisci la regola “solo un prestito attivo per item” o chiedi di rinominare campi così etichette UI e colonne DB coincidono.
Quando le basi funzionano, tratta i cambiamenti successivi come piccoli rilasci. Scegli una funzionalità, definisci cosa significa “done”, poi chiedi al modello di generarla.
Un ordine sensato per molte app:
Quando una modifica rompe la build, non cercare di aggiustare tutto insieme. Ripristina, poi riapplica la modifica con un prompt più piccolo e specifico. Se usi Koder.ai, snapshot e rollback sono una rete di sicurezza pratica, soprattutto prima di modifiche che toccano lo schema DB, le regole di auth o componenti UI condivisi.
Planning Mode aiuta quando una feature attraversa più livelli. Chiedi al modello di ripetere il piano prima (schermate, endpoint API, cambi schema, ruoli), poi approva il piano prima di generare il codice. Eviti così il mismatch comune in cui la UI si aspetta campi che l'API non ritorna, o l'API scrive in colonne che non esistono.
Se vuoi continuare fuori dalla piattaforma, esporta il codice sorgente e continua nel tuo workflow abituale. Tieni il set di prompt assieme al repo come “istruzioni di build” così puoi ricreare l'app o onboardare qualcuno in seguito.
Se stai costruendo su Koder.ai (koder.ai), questo set di prompt si allinea bene con i defaults React + Go + PostgreSQL della piattaforma ed è facile iterare in sicurezza usando snapshot mentre affini i requisiti.
Infine, salva un prompt template riutilizzabile per il prossimo progetto. Mantieni le parti stabili (stack, regole CRUD, convenzioni auth/ruoli, pattern PostgreSQL) e cambia solo i nomi di dominio. Col tempo i tuoi prompt diventano una ricetta ripetibile invece di un esperimento una tantum.
Inizia con l'entità principale e i suoi 6–12 campi (nome, tipo, obbligatorio/facoltativo, esempi). Poi blocca in modo chiaro ruoli + permessi, e chiedi sempre un breve piano prima di far scrivere codice.
Un buon ordine di default per generare è:
Perché costringe il modello a trattare UI, API e database come un unico contratto. Prompt vaghi tendono a creare scollamenti:
Un prompt preciso fa sì che nomi, regole e validazioni corrispondano tra i livelli.
Scegli un'entità centrale che gestirai ogni giorno (Customer, Task, Item). Mantienila a una entità nel giorno 1, aggiungi una seconda solo se è veramente necessaria per il flusso.
Un default pratico:
Perché gli esempi guidano etichette, formattazione e validazione. Se scrivi solo “date” o “status”, spesso ottieni input testuali nella UI mentre il DB si aspetta date o enum.
Usa un formato coerente per i campi:
field_name: type - example (rules)Questo aiuta il form React, la validazione in Go e i vincoli PostgreSQL a rimanere allineati.
Usa al massimo 2–3 ruoli, mappati sui verbi CRUD list, view, create, update, delete.
Un setup solido di default:
Richiedi poi che venga applicata la policy sia nelle rotte UI sia negli endpoint API.
Implementa e testa entrambi i livelli:
401 se non autenticato, 403 se autenticato ma non autorizzatoRegola pratica: se la UI blocca un'azione, l'API deve comunque rifiutarla se chiamata direttamente.
Default consigliato: email + password con persistenza della sessione al refresh.
Minimo da richiedere:
POST /auth/login, POST /auth/logout, GET /auth/meScegli e applica la stessa convenzione ovunque:
Se rinomini, richiedi un piano di rename (search/replace + migration) invece di lasciare che il modello improvvisi.
Chiedi sempre la stessa shape dalle endpoint list:
page, page_size, più i filtritotal, page, page_size, itemsUsa un prompt di audit che confronti:
Applica poi un piano di patch minimale.
Regola utile: non aggiungere funzionalità mentre allinei le incongruenze—allinea prima nomi, rotte, validazioni e permessi.
Seed: un utente admin per test locale.
Richiedi inoltre un ordinamento stabile (ad esempio created_at poi id) così la paginazione non salta o duplica elementi.