Vibe-coding-promptar för CRUD-app: komplett fullstack copy-paste-set

Vad detta promptset bygger (på vanligt språk)

Detta promptset är utformat för att generera en komplett, fungerande CRUD-app: skärmarna användarna ser, API:t som hanterar förfrågningarna och PostgreSQL-databasen som lagrar datan. Det inkluderar också inloggning och rollbaserad åtkomst, så olika användare kan se och göra olika saker.

CRUD är bara fyra vardagliga åtgärder din app behöver:

• Create: lägga till en ny post (som en kund eller uppgift)
• Read: visa en lista och öppna en enskild post
• Update: redigera en befintlig post
• Delete: ta bort en post (ofta med en bekräftelsesteg)

På frontend bör du få ett förutsägbart set av skärmar: en list-sida, en detaljsida, ett formulär för att skapa, ett för att redigera, plus en inloggningssida och grundläggande navigation. På backend får du endpoints som matchar de skärmarna (lista, hämta efter id, skapa, uppdatera, ta bort), backade av en Postgres-tabell och enkla valideringar.

Promptkvalitet spelar större roll än modellval. Modellen kan bara följa det du specificerar. Om din prompt är vag får du felmatchade fältnamn, saknade rutter, ofullständig auth eller en UI som inte stämmer överens med API:t. En tajt prompt fungerar som ett kontrakt: UI, API och databas använder samma namn och regler.

Innan du börjar, bestäm några detaljer så bygget håller sig konsekvent:

• Din huvudentitet och 6 till 12 fält (namn, typer, obligatoriskt vs valfritt)
• Roller (till exempel: admin, manager, viewer) och vad varje roll kan göra
• Grundläggande regler (vem kan redigera, soft delete vs hard delete, obligatoriska fält)
• De “happy path”-skärmar du behöver dag ett
• Eventuella begränsningar (unika fält, datumintervall, statusvärden)

Om du använder Koder.ai kan detta vara en konversation som producerar en React-UI, ett Go-API och ett PostgreSQL-schema som passar ihop utan manuell limning.

Förberedande arbetsblad: de få detaljer du behöver innan du promptar

Ett bra CRUD-bygge börjar med ett litet antal beslut. Skriv ner dem först så förblir dina prompts tydliga, dina skärmar ser rätt ut och ditt API matchar databasen.

Börja med en kärn-entitet. Detta är “saken” din app hanterar dagligen (Item, Customer, Appointment). Lägg till en andra entitet endast om den verkligen behövs dag ett (t.ex. Item behöver Category). Om du börjar med tre eller fyra kommer du spendera mest tid på att reda ut relationer istället för att få en fungerande app.

Skriv dina entitetsfält med typ och ett exempel. Exemplet är viktigt eftersom det styr etiketter, formatering och validering.

• Field: type - example (anteckningar)
• name: text - "Paper towels" (obligatoriskt, 2–80 tecken)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (valfritt)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

Nästa steg, lista roller och behörigheter i klartext. Håll det specifikt. För många appar räcker 2–3 roller:

• Admin: hantera användare, fullständigt CRUD på alla poster
• Manager: CRUD på poster, kan inte hantera användare
• Viewer: endast läsbehörighet

Slutligen, skapa 5–10 exempelposter. Dessa driver realistiska UI-etiketter, dropdown-alternativ och rimliga standardvärden. Exempel (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Om du bygger i Koder.ai, klistra in detta arbetsblad i din första prompt så plattformen kan hålla appen konsekvent över skärmar, auth och det PostgreSQL-backade API:t.

Bas-prompt: sätt reglerna för hela bygget

Börja med en ”rules of the road”-prompt. Den håller bygget konsekvent över skärmar, API och databas och minskar fram och tillbaka när du lägger till funktioner senare.

Be om en kort plan innan någon kod. Du vill att modellen namnger skärmar och rutter, tabeller och API-endpoints. Kräv också att den anger antaganden i förväg (som vilka roller som finns) och behåll dessa antaganden oförändrade om du inte godkänner en ändring.

Här är en copy-paste bas-prompt:

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.

Ett konkret exempel: om planen väljer role: admin|member ska den inte senare uppfinna manager för att lösa ett UI-edgecase. Denna prompt tvingar den att pausa och få din godkännande istället för att drifta.

Copy-paste-prompts: skärmar och navigation

Bra skärmar kommer från en klar sidkarta först. Använd prompts nedan innan du ber om databas eller API-kod. Detta håller rutter och UI-namn stabila senare, där många byggen går fel.

Prompt 1: sidlista och användarflöden

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.

Efter att den svarat, lås namnen. Om du ändrar rutt-namn senare kommer API och tester att drifta.

Prompt 2: navigation och formulär som beter sig väl

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.

Om UI:t blir för komplext, be den hålla endast en layout, en tabellstil och ett formulärmönster över alla sidor.

Copy-paste-prompts: autentisering och roller

Om du vill ha förutsägbara resultat, var explicit om hur användare loggar in, hur länge sessions varar och vad varje roll kan göra. Dessa prompts antar en enkel email + password-inloggning och en session-baserad approach (lätt att testa över skärmar och API:er).

Klistra in detta först för att generera inloggning, logout och session-hantering:

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.

Lägg nu till roller och skyddsregler. Håll behörigheterna små och enkla att testa:

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.

Snabba manuella kontroller som fångar de flesta misstag:

• Logga in som varje roll och bekräfta vad du kan och inte kan se.
• Försök göra en begränsad åtgärd ändå (som delete) och bekräfta att du får 403.
• Bekräfta att logout rensar sessionen och att appen återgår till Login-skärmen.

Om du bygger i Koder.ai, håll auth- och RBAC-ändringar i en snapshot så du enkelt kan återgå om behörigheterna trasslar till sig.

Copy-paste-prompts: PostgreSQL-schema och datamodell

En bra schema-prompt gör två jobb: tvingar tydliga tabellrelationer (så skärmar och API förblir konsekventa), och förhindrar “nästan rätt” databaser (saknade index, tidsstämplar eller rollmapping).

Innan du klistrar in, bestäm dessa två växlar (en rad vardera):

• Primary keys: uuid eller bigserial
• Soft delete: yes (använd deleted_at) eller no (hard delete)

Klistra in denna första prompt för att låsa datamodellen:

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.

Sedan klistra in denna prompt för att generera migrationer eller setups som matchar projektet:

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

Om något är oklart, lägg till en rad: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Copy-paste-prompts: Go CRUD API (Postgres-backed)

Om dina backend-outputs ofta är halvfärdiga, tvingar denna prompt fram basen: tydliga rutter, validering, paginering och rollkontroller i varje handler.

Kopiera denna som den är och ersätt sedan platshållarna (RESOURCE, FIELDS, ROLES) med dina appdetaljer.

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

Efter generation, gör en snabb genomgång för konsistens: statuskoder matchar felkroppen, list-endpointen returnerar stabil ordning, och varje handler kontrollerar både roll och tenant-ägarskap innan den rör databasen.

Om du använder Koder.ai, påpeka också att backend måste förbli Go och databasen PostgreSQL så exporterad kod matchar den förväntade stacken.

Steg-för-steg: generera, kör och verifiera

Generera allt (UI, API, databas), byt sedan till strikt verifieringsläge. Målet är inte att beundra skärmarna. Det är att bevisa att hela loopen fungerar: UI - auth - roller - Postgres - API - UI.

En enkel verifieringskörning

1. Kör appen och ladda startsidan. Bekräfta att navigation fungerar och att du inte ser placeholder-data. Om sidan är tom, notera det första synliga felmeddelandet (UI-toast, konsol eller serverlogg).

2. Skapa ett testkonto per roll (Admin, Manager, Viewer). Logga in och ut med varje användare. Bekräfta att appen visar rollen någonstans synligt (profilmeny, inställningar eller en liten badge).

3. Välj en CRUD-sida och gör en full cykel: skapa en post, uppdatera sidan, redigera och ta bort den. Nyckelkontrollen är persistens: efter refresh ska posten reflektera vad som finns i Postgres, inte bara i minnet.

4. Försök med förbjudna åtgärder med avsikt. Logga in som lägsta roll och försök komma åt en admin-only-sida, kalla en begränsad åtgärd (som delete), eller redigera en post du inte borde. Du vill ha tydliga resultat: antingen en blockerad UI med meddelande eller ett 403-liknande fel utan databasändring.

5. Testa grundläggande edgecases: tomma listor, mycket långa namn, saknade obligatoriska fält och ogiltiga format (email, datum). Bekräfta att appen visar hjälpsam validering och inte kraschar.

Om du använder Koder.ai, ta en snapshot direkt efter den första lyckade end-to-end CRUD-testen. Det ger en säker rollback-punkt innan du börjar lägga till extrafunktioner.

Vanliga prompt-fel och hur man fixar dem

De flesta “trasiga” byggen är inte verkligen trasiga. De saknar en constraint som håller UI, API och databas i takt.

1) Du bad om för mycket på en gång

När du begär skärmar, auth, roller, schema och alla edgecases i ett svep blir appen ofta inkonsekvent (rutter matchar inte, modeller drifts, halvfärdiga sidor).

Fix: dela upp efter lager och tvinga verktyget att omformulera vad det kommer generera innan kod. I Koder.ai hjälper det också att hålla flera agenter synkade.

2) Roller är vaga, så kontroller saknas

Om du bara säger “admin och user” kan du få en rolletikett i UI men ingen riktig server-side authorization.

Fix: definiera behörigheter som åtgärder (create, read, update, delete) per resurs och kräv server-side upprätthållande på varje endpoint.

3) Saknade fälttyper orsakar UI- och DB-drift

Om du beskriver fält i löpande text (“price”, “date”, “status”) kan formulären renderas som textinputs medan Postgres förväntar sig tal, datum eller enums.

Fix: specificera fälttyper, nullbarhet, defaults och constraints, och kräv delade valideringsregler.

4) Inga loading- och error-states, så UI ser trasigt ut

Utan loading- och error-states ser ett misslyckat anrop ut som en frusen sida.

Fix: kräva loading-spinners, empty states och synliga felmeddelanden för varje sida.

5) Namn ändras mitt i bygget

Att byta namn från “Projects” till “Workspaces” halvvägs bryter ofta rutter, handlers och tabellnamn.

Fix: lås en ordlista tidigt. När du ändrar namn, begär en rename-plan (search, replace, migrate) istället för att låta modellen improvisera.

Använd denna reparationsprompt när något går fel:

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.

Om du fortsätter träffa inkonsekvenser saknas troligen en “single source of truth”-sats. Lägg till en mening: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Snabb checklista innan du säger att det är klart

Innan du lägger tid på polish, gör en snabb genomgång för att bekräfta att appen beter sig som en riktig produkt. Här misslyckas de flesta fullstack CRUD-appar: små mismatch mellan skärmar, regler och data.

• Skärmar matchar entitets-specen: varje skärm (lista, detaljer, skapa, redigera) använder de exakta entitetsnamnen och fältlistan du definierade.
• Roller är entydiga: skriv en enkel allow/deny-tabell per roll och bekräfta att UI och API upprätthåller samma regler.
• API-svar är konsekventa: välj ett mönster (statuskoder, felstruktur, pagineringsformat) och verifiera att varje endpoint följer det.
• Databasconstraints matchar formulärvalidering: om DB kräver unik email eller icke-null namn, validera innan submit och visa tydligt meddelande när API:t nekar.
• Create/edit/delete överlever refresh: skapa en post, refresh, bekräfta att den fortfarande finns; redigera, refresh, bekräfta; ta bort, refresh, bekräfta.

Ett konkret test: logga in som lägsta behörighetsroll och försök en åtgärd du förväntar dig vara blockerad (som delete). Om den lyckas, fixa policyn på ett ställe (API:t) först, sedan justera UI:t så det matchar.

Realistiskt exempel: en enkel inventarielista

Föreställ dig ett litet IT-team som lånar ut laptops, skärmar och adaptrar till personalen. De behöver en plats för att se vad som finns, vem som har vad och när det ska lämnas tillbaka. Detta är ett bra testfall eftersom det tvingar fram roller, ett par skärmar och en riktig databas.

Ifyllt arbetsblad

Använd detta som exakt input för din prep-step (kopiera som det är, ändra sedan namn vid behov):

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)

Klistringsordning

Klistra in dina prompts i denna ordning så appen förblir konsekvent:

1. Bas-prompt (globala regler, stack, namngivning, felhantering)
2. Skärmar och navigation (Inventory, Requests, Loans, Admin queue)
3. Autentisering och roller (admin, staff, viewer-behörigheter)
4. PostgreSQL-schema och seed-data (items, loans, requests, users)
5. Go CRUD API (endpoints och validering som matchar reglerna)

Ett bra utfall ser ut så här: staff kan begära “MBP-014”, admin kan godkänna det med ett förfallodatum, och inventarielistan visar det som otillgängligt med låntagarnamn.

Om bygget är nära men inte rätt, justera en sak i taget: skärp rollbehörigheter (viewer ska aldrig se edit-knappar), återge regeln “endast en aktiv lån per item”, eller be om att fältnamn ändras så UI-etiketter och DB-kolumner matchar exakt.

Nästa steg: utöka säkert och återanvänd promptset

När grunderna fungerar, behandla nästa ändringar som små releaser. Välj en funktion, definiera vad “klart” betyder, be om den.

En förnuftig ordning för många appar:

• Audit log: spela in vem som ändrade vad och när (create, update, delete) och visa det på en admin-only sida.
• Filuppladdningar: bifoga ett dokument eller bild till en post, lagra metadata i Postgres och håll åtkomst bakom auth.
• Enkla notiser: visa in-app-alerts (t.ex. “low stock” eller “new comment”), med en “mark as read”-åtgärd.

När en ändring bryter bygget, försök inte fixa allt samtidigt. Roll back, och applicera ändringen igen med en mindre, mer specifik prompt. Om du använder Koder.ai är snapshots och rollback ett praktiskt skyddsnät, särskilt innan ändringar som rör DB-schema, auth-regler eller delade UI-komponenter.

Planning Mode hjälper också när en funktion spänner över flera lager. Be den om att omformulera planen först (skärmar, API-endpoints, databasändringar, roller), och godkänn planen innan kodgenerering. Detta förhindrar vanliga mismatch där UI förväntar sig fält som API inte returnerar, eller API skriver till kolumner som inte finns.

Om du vill fortsätta utanför plattformen, exportera källkoden och gör ändringar i din vanliga workflow. Behåll promptset nära repot som “bygginstruktioner” så du kan återskapa appen senare eller onboarda någon ny.

Om du bygger på Koder.ai (koder.ai), ligger detta promptset väl i linje med plattformens React + Go + PostgreSQL-standarder, och det är enkelt att iterera säkert med snapshots medan du förfinar krav.

Slutligen, spara en återanvändbar mall-prompt för ditt nästa projekt. Behåll de stabila delarna (stack, CRUD-regler, auth- och rollkonventioner, Postgres-mönster) och byt bara ut domänsubstantiven. Med tiden blir dina prompts ett upprepat recept istället för ett engångsexperiment.