Utilisez ces prompts Vibe Coding pour générer écrans, auth, rôles et une API Postgres pour une application CRUD. Jeux de prompts à copier-coller et conseils de dépannage.
Cet ensemble de prompts est conçu pour générer une application CRUD complète et fonctionnelle : les écrans que les gens utilisent, l'API qui traite les requêtes, et la base de données PostgreSQL qui stocke les données. Il inclut aussi l'authentification et l'accès basé sur les rôles, pour que différents utilisateurs voient et fassent des choses différentes.
CRUD, ce sont quatre actions quotidiennes dont votre application a besoin :
Sur le front end, vous devriez obtenir un ensemble d'écrans prévisibles : une page de liste, une page de détail, un formulaire de création, un formulaire d'édition, plus une page de connexion et une navigation de base. Sur le back end, vous aurez des endpoints qui correspondent à ces écrans (list, get by id, create, update, delete), soutenus par une table Postgres et des validations simples.
La qualité du prompt compte plus que le choix du modèle. Le modèle ne peut suivre que ce que vous spécifiez. Si votre prompt est vague, vous obtiendrez des noms de champs décalés, des routes manquantes, une auth incomplète, ou une UI qui ne correspond pas à l'API. Un prompt précis agit comme un contrat : UI, API et BDD utilisent les mêmes noms et règles.
Avant de commencer, décidez de quelques points pour que la construction reste cohérente :
Si vous utilisez Koder.ai, cette séquence peut être une seule conversation qui produit une UI React, une API Go et un schéma PostgreSQL qui s'imbriquent sans collage manuel.
Une bonne construction CRUD commence par un petit ensemble de décisions. Notez-les d'abord et vos prompts resteront clairs, vos écrans cohérents et votre API correspondante à la base.
Commencez par une entité centrale. C'est la « chose » que votre app gère quotidiennement (Item, Customer, Appointment). Ajoutez une seconde entité seulement si elle est vraiment nécessaire dès le départ (par exemple, Item a besoin de Category). Si vous commencez avec trois ou quatre, vous passerez la plupart du temps à démêler des relations au lieu d'obtenir une app fonctionnelle.
Écrivez les champs de votre entité avec un type et un exemple. L'exemple compte car il guide les libellés, le formatage et la validation.
Ensuite, listez les rôles et permissions en langage clair. Restez spécifique. Pour beaucoup d'apps, 2 à 3 rôles suffisent :
Enfin, créez 5 à 10 enregistrements d'exemple. Ils produisent des libellés UI réalistes, des options de dropdown et des valeurs par défaut sensées. Exemple (inventaire) : “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Si vous construisez sur Koder.ai, collez cette fiche dans votre premier prompt pour que la plateforme garde l'app cohérente entre écrans, auth et l'API PostgreSQL.
Commencez par un seul prompt « règles de conduite ». Il maintient la cohérence entre écrans, API et base de données, et réduit les allers-retours lorsque vous ajoutez des fonctionnalités plus tard.
Demandez un plan court avant tout code. Vous voulez que le modèle nomme les écrans et routes, les tables et les endpoints API. Exigez aussi qu'il indique les hypothèses dès le départ (par ex. quels rôles existent) et qu'il ne change pas ces hypothèses sans votre accord.
Voici un prompt de base à copier-coller :
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 exemple concret : si le plan choisit role: admin|member, il ne devrait pas ensuite inventer manager pour résoudre un cas d'UI. Ce prompt l'oblige à s'arrêter et demander votre approbation au lieu de dériver.
De bons écrans viennent d'abord d'une carte de pages claire. Utilisez les prompts ci-dessous avant de demander le code de la base de données ou de l'API. Cela stabilise les routes et noms d'UI, là où beaucoup de constructions déraillent.
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.
Après qu'il ait répondu, verrouillez les noms. Si vous changez les noms de route plus tard, l'API et les tests vont diverger.
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 l'UI est trop complexe, demandez-lui de garder un seul layout, un seul style de table et un seul pattern de formulaire pour toutes les pages.
Pour obtenir des résultats prévisibles, soyez explicite sur la façon dont les utilisateurs se connectent, la durée des sessions et ce que chaque rôle peut faire. Ces prompts supposent une connexion simple par email + mot de passe et une approche basée sur la session (facile à tester entre écrans et API).
Collez ceci d'abord pour générer login, logout et gestion de session :
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.
Ajoutez ensuite rôles et règles de protection. Gardez les permissions petites et faciles à tester :
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.
Vérifications manuelles rapides qui attrapent la plupart des erreurs :
Si vous utilisez Koder.ai, gardez auth et RBAC dans un seul snapshot pour pouvoir revenir en arrière proprement si les permissions se mélangent.
Un bon prompt de schéma fait deux choses : il force des relations de table claires (pour que l'UI et l'API restent compatibles), et il empêche une base “presque correcte” (index manquants, timestamps, mapping des rôles absent).
Avant de coller, décidez de ces deux bascules (une ligne chacune) :
uuid or bigserialyes (use deleted_at) or no (hard delete)Collez ce prompt d'abord pour verrouiller le modèle de données :
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.
Puis collez ce prompt pour générer les migrations ou étapes d'initialisation qui correspondent au projet :
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 quelque chose est ambigu, ajoutez une ligne : “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Si vos sorties backend reviennent incomplètes, ce prompt force les bases : routes claires, validation, pagination et vérification des rôles dans chaque handler.
Collez ceci tel quel, puis remplacez les placeholders (RESOURCE, FIELDS, ROLES) par vos détails d'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
Après génération, faites une passe rapide pour vérifier la cohérence : codes de statut et corps d'erreur correspondent, l'endpoint de liste renvoie un ordre stable, et chaque handler vérifie rôle et appartenance au tenant avant toute modification de la DB.
Si vous utilisez Koder.ai, signalez que le backend doit rester en Go et la base en PostgreSQL pour que le code exporté corresponde à la stack attendue.
Générez tout (UI, API, base), puis passez en mode vérification stricte. L'objectif n'est pas d'admirer les écrans mais de prouver que la boucle complète fonctionne : UI - auth - rôles - Postgres - API - UI.
Lancez l'app et chargez l'écran d'accueil. Confirmez que la navigation fonctionne et que vous ne voyez pas de données factices. Si la page est blanche, notez le premier message d'erreur visible (toast UI, console ou log serveur).
Créez un compte de test par rôle (Admin, Manager, Viewer). Connectez-vous et déconnectez-vous avec chaque utilisateur. Confirmez que l'app affiche le rôle quelque part (menu profil, paramètres, ou un petit badge).
Choisissez un écran CRUD et faites un cycle complet : créez un enregistrement, rafraîchissez la page, puis éditez et supprimez-le. La vérification clé est la persistance : après rafraîchissement, l'enregistrement doit refléter ce qui est en Postgres, pas seulement en mémoire.
Essayez des actions interdites volontairement. Connectez-vous avec le rôle le plus bas et tentez d'accéder à un écran admin, appelez une action restreinte (comme delete), ou éditez un enregistrement auquel vous ne devriez pas accéder. Vous voulez des résultats clairs : soit une UI bloquée avec un message, soit une erreur 403 sans modification de données.
Testez des cas limites : listes vides, noms très longs, champs requis manquants, formats invalides (email, dates). Confirmez que l'app affiche des validations utiles et ne plante pas.
Si vous utilisez Koder.ai, prenez un snapshot juste après le premier test CRUD de bout en bout réussi. Cela vous donne un point de retour sûr avant d'ajouter des extras.
La plupart des builds “cassés” ne sont pas vraiment cassés. Il manque juste une contrainte qui maintient UI, API et BDD alignés.
Quand vous demandez écrans, auth, rôles, schéma et tous les cas limites en une seule fois, l'app devient souvent incohérente (routes qui ne correspondent pas, modèles qui dérivent, pages à moitié finies).
Correction : scindez par couche et forcez l'outil à redire ce qu'il va générer avant d'écrire du code. Sur Koder.ai, cela aide aussi à maintenir plusieurs agents alignés.
Si vous dites seulement “admin et user”, vous pouvez obtenir un label de rôle dans l'UI mais pas d'autorisation réelle côté serveur.
Correction : définissez les permissions comme des actions (create, read, update, delete) par ressource, et exigez l'application côté serveur sur chaque endpoint.
Si vous décrivez des champs en langage libre (“price”, “date”, “status”), les formulaires peuvent rendre des inputs texte alors que Postgres attend des nombres, des dates ou des enums.
Correction : spécifiez types, nullabilité, valeurs par défaut et contraintes, et exigez des règles de validation partagées.
Sans états de chargement et d'erreur, une requête échouée ressemble à une page figée.
Correction : exigez des spinners de chargement, des états vides et des messages d'erreur visibles pour chaque écran.
Renommer “Projects” en “Workspaces” à mi-chemin casse souvent routes, handlers et noms de table.
Correction : verrouillez un glossary tôt. Quand vous renommez, demandez un plan de renommage (search/replace, migrate) plutôt que de laisser le modèle improviser.
Utilisez ce prompt de réparation quand quelque chose déraille :
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 les incohérences persistent, il vous manque probablement une « source unique de vérité ». Ajoutez une phrase : “The Postgres schema is the source of truth; UI and API must match it exactly.”
Avant de polir, vérifiez rapidement que l'app se comporte comme un produit réel. C'est là que la plupart des apps CRUD échouent : de petites incohérences entre écrans, règles et données.
Un test concret : connectez-vous avec le rôle le plus bas et tentez une action que vous pensez bloquée (par ex. supprimer). Si elle réussit, corrigez la politique à un endroit (l'API) d'abord, puis ajustez l'UI pour qu'elle corresponde.
Imaginez une petite équipe IT qui prête des laptops, écrans et adaptateurs au personnel. Elle a besoin d'un endroit pour voir ce qui est disponible, qui a quoi, et quand cela doit être rendu. C'est un bon cas de test car il force les rôles, quelques écrans et une vraie base.
Utilisez ceci comme entrée exacte pour votre étape de préparation (copiez tel quel, puis ajustez les noms) :
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)
Collez vos prompts dans cet ordre pour que l'app reste cohérente :
Un bon résultat ressemble à ceci : le staff peut demander “MBP-014”, l'admin l'approuve avec une date d'échéance, et la liste d'inventaire l'affiche comme indisponible avec le nom de l'emprunteur.
Si la construction est proche mais pas correcte, ajustez une chose à la fois : resserrez les permissions de rôle (un viewer ne doit jamais voir un bouton d'édition), réaffirmez la règle “une seule loan active par item”, ou demandez de renommer des champs pour que les libellés UI et les colonnes DB correspondent exactement.
Une fois les bases en place, traitez les prochains changements comme de petites releases. Choisissez une fonctionnalité, définissez ce que signifie “done”, puis prompt pour elle.
Un ordre sensé pour beaucoup d'apps :
Quand un changement casse la construction, ne tentez pas de tout réparer d'un coup. Revenez en arrière, puis ré-appliquez le changement dans un prompt plus petit et ciblé. Si vous utilisez Koder.ai, les snapshots et rollback sont un filet de sécurité pratique, surtout avant des changements qui touchent le schéma DB, les règles d'auth ou les composants partagés.
Le Planning Mode aide aussi quand une fonctionnalité traverse plusieurs couches. Demandez au modèle de redécrire le plan d'abord (écrans, endpoints API, changements DB, rôles), puis approuvez ce plan avant de générer du code. Cela évite le décalage courant où l'UI attend des champs que l'API ne retourne pas, ou l'API écrit dans des colonnes qui n'existent pas.
Si vous souhaitez continuer en dehors de la plateforme, exportez le code source et modifiez-le dans votre workflow habituel. Conservez l'ensemble de prompts à côté du repo comme “instructions de build” pour pouvoir recréer l'app plus tard ou faciliter l'onboarding.
Si vous construisez sur Koder.ai (koder.ai), cet ensemble de prompts s'aligne bien sur les defaults React + Go + PostgreSQL de la plateforme, et il est facile d'itérer en toute sécurité en utilisant des snapshots pendant que vous affinez les exigences.
Enfin, enregistrez un prompt modèle réutilisable pour votre prochain projet. Gardez les parties stables (stack, règles CRUD, conventions d'auth et rôles, patterns Postgres) et ne remplacez que les noms de domaine. Avec le temps, vos prompts deviennent une recette répétable plutôt qu'une expérience ponctuelle.
Commencez par l'entité principale et ses 6–12 champs (nom, type, requis/optionnel, exemples). Ensuite, verrouillez rôles + permissions en langage clair, et demandez un court plan avant tout code.
Un bon ordre par défaut :
Parce que cela oblige le modèle à traiter l'UI, l'API et la base de données comme un unique contrat. Des prompts vagues créent généralement des dérives :
Un prompt serré fait correspondre noms, règles et validations entre les couches.
Choisissez une entité centrale que vous gérerez quotidiennement (Customer, Task, Item). Limitez-vous à une seule entité au jour 1 sauf si une seconde est vraiment nécessaire.
Un choix pratique par défaut :
Les exemples guident les libellés, le formatage et la validation. Si vous dites seulement “date” ou “status”, vous obtiendrez souvent un champ texte dans l'UI alors que Postgres attend une date ou un enum.
Utilisez un format de ligne cohérent :
field_name: type - example (rules)Cela aide le formulaire React, la validation Go et les contraintes PostgreSQL à rester alignés.
Utilisez au maximum 2–3 rôles, mappés sur les verbes CRUD list, view, create, update, delete.
Un défaut solide :
Exigez ensuite l'application côté serveur et côté UI.
Implémentez et testez les deux :
401 si non authentifié, 403 si connecté mais non autoriséRègle pratique : si l'UI bloque une action, l'API doit tout de même la rejeter si elle est appelée directement.
Privilégiez email + mot de passe avec persistance de session au rafraîchissement.
Exigences minimales à demander :
POST /auth/login, POST /auth/logout, Choisissez une convention et appliquez-la partout :
Si vous renommez quelque chose, demandez un plan de renommage (search/replace + migrations) au lieu de laisser le modèle improviser.
Demandez au modèle de renvoyer la même forme pour chaque endpoint de liste :
page, page_size, plus vos filtrestotal, page, page_size, Utilisez un prompt d'audit qui compare :
Puis appliquez un plan de correctifs minimal.
Règle utile : n'ajoutez pas de fonctionnalités en même temps que vous corrigez des incohérences — alignez d'abord les noms, routes, validations et permissions.
GET /auth/meSeedez un administrateur par défaut pour les tests locaux.
itemsExigez aussi un tri stable (par ex. created_at puis id) pour que la pagination n'omette ou ne duplique pas d'éléments.