Użyj promptów Vibe do aplikacji CRUD, aby wygenerować ekrany, uwierzytelnianie, role i API PostgreSQL. Zestawy promptów do kopiuj-wklej oraz wskazówki rozwiązywania problemów.
Ten zestaw promptów ma wygenerować kompletną, działającą aplikację CRUD: ekrany, których używają ludzie, API obsługujące żądania oraz bazę danych PostgreSQL przechowującą dane. Zawiera też logowanie i kontrolę dostępu opartą na rolach, dzięki czemu różni użytkownicy widzą i mogą robić różne rzeczy.
CRUD to cztery codzienne operacje, których aplikacja potrzebuje:
Na froncie powinieneś otrzymać przewidywalny zestaw ekranów: stronę listy, stronę szczegółów, formularz tworzenia, formularz edycji, stronę logowania i podstawową nawigację. Na backendzie będą endpointy odpowiadające tym ekranom (list, get by id, create, update, delete), wspierane przez tabelę Postgres i proste walidacje.
Jakość promptu ma większe znaczenie niż wybór modelu. Model może wykonać tylko to, co określisz. Jeśli prompt jest nieprecyzyjny, dostaniesz niespójne nazwy pól, brakujące trasy, niekompletne auth lub UI, który nie zgadza się z API. Dobry, ścisły prompt działa jak umowa: UI, API i baza zgadzają się co do tych samych nazw i reguł.
Zanim zaczniesz, zdecyduj kilka szczegółów, żeby budowa była spójna:
Jeśli korzystasz z Koder.ai, może to być jedna rozmowa, która wygeneruje UI w React, API w Go i schemat PostgreSQL pasujące do siebie bez ręcznego łączenia.
Dobra budowa CRUD zaczyna się od niewielkiej liczby decyzji. Zapisz je najpierw, a prompty pozostaną jasne, ekrany będą poprawne, a API będzie pasować do bazy danych.
Zacznij od jednej głównej encji. To jest „rzecz”, którą aplikacja zarządza na co dzień (Item, Customer, Appointment). Dodaj drugą encję tylko jeśli jest naprawdę potrzebna od dnia pierwszego (np. Item potrzebuje Category). Jeśli zaczniesz od trzech lub czterech, spędzisz większość czasu rozwiązując relacje zamiast uzyskać działającą aplikację.
Wypisz pola encji z typem i przykładem. Przykład ma znaczenie, bo kieruje etykietami, formatowaniem i walidacją.
Następnie wypisz role i uprawnienia prostym językiem. Bądź konkretny. W wielu aplikacjach 2–3 role wystarczą:
Na koniec stwórz 5–10 przykładowych rekordów. To napędza realistyczne etykiety UI, opcje w dropdownach i sensowne wartości domyślne. Przykład (inwentarz): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
Jeśli budujesz w Koder.ai, wklej ten arkusz do pierwszego promptu, żeby platforma mogła utrzymać spójność aplikacji między ekranami, auth i API opartym na PostgreSQL.
Zacznij od jednego promptu „reguł gry”. Utrzyma to spójność między ekranami, API i bazą danych oraz zredukuje iteracje, gdy będziesz dodawać funkcje później.
Poproś o krótki plan przed wygenerowaniem jakiegokolwiek kodu. Chcesz, żeby model wymienił ekrany i trasy, tabele oraz endpointy API. Wymagaj też, żeby od razu podał założenia (np. jakie role istnieją) i nie zmieniał tych założeń bez Twojej zgody.
Oto prompt do kopiuj‑wklej:
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.
Przykład konkretny: jeśli plan wybierze role: admin|member, nie powinien później wymyślać manager, żeby rozwiązać edge case UI. Ten prompt zmusza model do zatrzymania się i poproszenia o zatwierdzenie zamiast dryfować.
Dobre ekrany powstają na podstawie klarownej mapy stron. Użyj poniższych promptów zanim poprosisz o kod bazy danych lub API. To utrzyma spójność tras i nazw UI, gdzie wiele budów się rozpada.
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.
Po otrzymaniu odpowiedzi, zablokuj nazwy. Jeśli później zmienisz nazwy tras, API i testy się rozjadą.
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.
Jeśli UI będzie zbyt złożone, poproś, żeby zachować tylko jeden layout, jeden styl tabeli i jeden wzorzec formularza na wszystkie strony.
Jeśli chcesz przewidywalnych rezultatów, bądź precyzyjny w kwestii sposobu logowania, czasu trwania sesji i co każda rola może robić. Poniższe prompty zakładają proste logowanie email + hasło i podejście oparte na sesji (łatwe do testowania w UI i API).
Wklej ten pierwszy prompt, żeby wygenerować logowanie, wylogowanie i obsługę sesji:
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.
Teraz dodaj role i reguły ochrony. Utrzymuj uprawnienia małe i łatwe do przetestowania:
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.
Szybkie ręczne testy, które wykryją większość błędów:
Jeśli budujesz w Koder.ai, trzymaj zmiany auth i RBAC w jednym snapshotcie, żeby móc łatwo cofnąć zmiany, jeśli uprawnienia się poplączą.
Dobry prompt dla schematu robi dwie rzeczy: zmusza do jasnych relacji tabel (aby UI i API pozostały spójne) oraz zapobiega „prawie poprawnej” bazie (brak indeksów, timestampów lub mapowania ról).
Zanim wkleisz, zdecyduj dwie rzeczy (po jednej linii każda):
uuid or bigserialyes (użyj deleted_at) lub no (hard delete)Wklej ten prompt, żeby zablokować model danych:
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.
Następnie wklej ten prompt, aby wygenerować migracje lub kroki setupu, które pasują do projektu:
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
Jeśli coś jest niejasne, dodaj jedną linię: „Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
Jeśli backend ciągle wraca niekompletny, ten prompt wymusza podstawy: jasne trasy, walidację, paginację i sprawdzenia ról w każdym handlerze.
Skopiuj i wklej go takim, jaki jest, a potem zamień placeholdery (RESOURCE, FIELDS, ROLES) na szczegóły Twojej aplikacji.
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
Po wygenerowaniu, zrób szybką kontrolę spójności: kody statusu pasują do ciał błędów, endpoint listy zwraca stabilne sortowanie, i każdy handler sprawdza zarówno rolę, jak i przynależność tenant przed dostępem do bazy.
Jeśli korzystasz z Koder.ai, podkreśl też, że backend musi pozostać w Go, a baza w PostgreSQL, żeby eksportowany kod pasował do oczekiwanego stacku.
Wygeneruj wszystko (UI, API, baza), potem przejdź do trybu ścisłej weryfikacji. Celem nie jest podziwianie ekranów, ale udowodnienie, że pełna pętla działa: UI - auth - role - Postgres - API - UI.
Uruchom aplikację i załaduj ekran główny. Potwierdź, że nawigacja działa i nie widzisz danych placeholder. Jeśli strona jest pusta, zanotuj pierwszy widoczny błąd (toast UI, console lub log serwera).
Stwórz jedno testowe konto dla każdej roli (Admin, Manager, Viewer). Loguj się i wylogowuj każdą osobą. Potwierdź, że aplikacja pokazuje rolę w widocznym miejscu (menu profilu, ustawienia lub mały badge).
Wybierz jeden ekran CRUD i wykonaj pełny cykl: utwórz rekord, odśwież stronę, potem edytuj i usuń go. Kluczowa kontrola to trwałość: po odświeżeniu rekord powinien odzwierciedlać to, co jest w Postgres, a nie tylko w pamięci.
Celowo spróbuj wykonać zabronione akcje. Zaloguj się jako rola o najniższych uprawnieniach i spróbuj wejść na ekran tylko dla admina, wywołać akcję typu delete lub edytować rekord, którego nie powinieneś. Chcesz jasne rezultaty: blokujące UI z komunikatem lub błąd 403 bez zmiany danych.
Przetestuj podstawowe edge case’y: puste listy, bardzo długie nazwy, brak wymaganych pól i nieprawidłowe formaty (email, daty). Potwierdź, że aplikacja pokazuje pomocną walidację i nie pada.
Jeśli używasz Koder.ai, zrób snapshot tuż po pierwszym udanym, end‑to‑end teście CRUD. To daje punkt przywracania przed dodaniem dodatkowych funkcji.
Większość „zepsutych” buildów w rzeczywistości nie jest zepsuta. Brakuje tylko jednego ograniczenia, które utrzymuje UI, API i DB w zgodzie.
Kiedy prosisz o ekrany, auth, role, schemat i wszystkie edge case’y w jednym kawałku, aplikacja często staje się niespójna (trasy nie pasują, modele się rozjeżdżają, strony są niedokończone).
Naprawa: podziel zadania na warstwy i zmusz narzędzie, żeby przed generowaniem kodu powtórzyło, co zrobi. W Koder.ai pomaga to też zsynchronizować wielu agentów.
Jeśli napiszesz tylko „admin i user”, możesz dostać etykietę roli w UI, ale brak rzeczywistego autoryzowania po stronie serwera.
Naprawa: definiuj uprawnienia jako akcje (create, read, update, delete) dla każdego zasobu i wymagaj egzekwowania po stronie serwera na każdym endpointzie.
Jeśli opisujesz pola w prostym języku („price”, „date”, „status”), formularze mogą renderować pola tekstowe, podczas gdy Postgres oczekuje liczb, dat lub enumów.
Naprawa: określ typy pól, nullowalność, wartości domyślne i constraints oraz wymagaj współdzielonych reguł walidacji.
Bez stanów ładowania i komunikatów o błędach, nieudane zapytanie wygląda jak zawieszona strona.
Naprawa: wymagaj spinnerów, stanów pustej listy i widocznych błędów dla każdego ekranu.
Zmiana „Projects” na „Workspaces” w połowie procesu często psuje trasy, handlery i nazwy tabel.
Naprawa: zablokuj słownik terminów na początku. Kiedy zmieniasz nazwy, poproś o plan rename (search, replace, migrate) zamiast pozwolić modelowi improwizować.
Użyj tego promptu naprawczego, gdy coś pójdzie nie tak:
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.
Jeśli ciągle trafiasz na niespójności, prawdopodobnie brakuje Ci zdania „single source of truth”. Dodaj jedno zdanie: „The Postgres schema is the source of truth; UI and API must match it exactly.”
Zanim zaczniesz dopracowywać wygląd, zrób szybką kontrolę, czy aplikacja zachowuje się jak produkt. To właśnie tutaj większość pełnostackowych CRUD‑ów zawodzi: drobne rozbieżności między ekranami, regułami i danymi.
Konkretne testy: zaloguj się jako rola o najniższych uprawnieniach i spróbuj wykonać oczekiwaną zablokowaną akcję (np. delete). Jeśli się uda, napraw politykę w jednym miejscu (API) najpierw, potem dostosuj UI.
Wyobraź sobie mały zespół IT, który wypożycza laptopy, monitory i adaptery pracownikom. Potrzebują jednego miejsca, by zobaczyć, co jest dostępne, kto ma co i kiedy powinno zostać zwrócone. To dobry przypadek testowy, bo wymusza role, kilka ekranów i prawdziwą bazę danych.
Użyj tego jako dokładnego inputu na etap przygotowawczy (kopiuj tak, jak jest, potem dopasuj nazwy):
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)
Wklej prompty w tej kolejności, aby aplikacja pozostała spójna:
Dobry wynik wygląda tak: staff może zgłosić request na „MBP-014”, admin może go zatwierdzić z datą zwrotu, a lista inwentarza pokazuje go jako niedostępny wraz z nazwiskiem pożyczającego.
Jeśli build jest bliski, ale nie do końca, poprawiaj jedną rzecz naraz: zaostrz uprawnienia ról (viewer nigdy nie powinien widzieć przycisków edycji), ponownie określ regułę „maks. 1 aktywna pożyczka na przedmiot” albo poproś o przemianowanie pól tak, by etykiety UI i kolumny DB pasowały dokładnie.
Gdy podstawy działają, traktuj kolejne zmiany jak małe wydania. Wybierz jedną funkcję, zdefiniuj, co oznacza „gotowe”, a potem poproś o nią w promptcie.
W sensownej kolejności dla wielu aplikacji:
Gdy zmiana coś psuje, nie próbuj naprawiać wszystkiego naraz. Cofnij się, potem zastosuj zmianę w mniejszym, bardziej konkretnym promptcie. Jeśli używasz Koder.ai, snapshoty i rollback to praktyczne zabezpieczenie, szczególnie przed zmianami w schemacie DB, regułach auth lub współdzielonych komponentach UI.
Tryb planowania (Planning Mode) też pomaga, gdy funkcja dotyczy wielu warstw. Poproś najpierw o ponowne przedstawienie planu (ekrany, endpointy API, zmiany w bazie, role), a potem zatwierdź plan przed wygenerowaniem kodu. To zapobiega zwykłemu problemowi, że UI oczekuje pól, których API nie zwraca, albo API zapisuje do kolumn, których nie ma.
Jeśli chcesz kontynuować poza platformą, eksportuj źródła i wprowadź zmiany w swoim zwykłym workflow. Trzymaj zestaw promptów razem z repo jako „instrukcję budowy”, aby móc odtworzyć aplikację później lub wdrożyć nową osobę.
Jeśli budujesz na Koder.ai (koder.ai), ten zestaw promptów dobrze pasuje do domyślnych ustawień React + Go + PostgreSQL i łatwo iterować przy użyciu snapshotów podczas dopracowywania wymagań.
Na koniec zapisz sobie wielokrotnego użytku szablon promptu na następny projekt. Zachowaj stałe elementy (stack, zasady CRUD, konwencje auth i ról, wzorce Postgres) i zamieniaj tylko rzeczowniki domenowe. Z czasem Twoje prompty staną się powtarzalną receptą, a nie jednorazowym eksperymentem.
Zacznij od głównej encji i 6–12 pól (nazwa, typ, wymagane/opcjonalne, przykłady). Następnie zablokuj role + uprawnienia w prostym języku i poproś o krótki plan przed wygenerowaniem kodu.
Dobrym domyślnym porządkiem jest generowanie w tej kolejności:
Ponieważ zmusza model do traktowania UI, API i bazy danych jako jednego kontraktu. Nieprecyzyjne prompt-y zwykle powodują rozjazd:
Szczelny prompt sprawia, że nazwy, zasady i walidacje pasują do siebie w każdej warstwie.
Wybierz encję, którą będziesz obsługiwać codziennie (Customer, Task, Item). Ogranicz się do jednej encji na pierwszy dzień, chyba że druga jest naprawdę niezbędna dla workflow.
Praktyczny domyślny zestaw:
Przykłady kierują etykietami, formatowaniem i walidacją. Jeśli podasz tylko „date” lub „status”, często dostaniesz pole tekstowe w UI, podczas gdy Postgres oczekuje daty lub enumu.
Użyj spójnego formatu na linii pola:
field_name: type - example (rules)To pomaga dopasować formularz w React, walidację w Go i constraints w PostgreSQL.
Używaj maksymalnie 2–3 ról, przypisanych do czasowników CRUD: list, view, create, update, delete.
Solidny domyślny zestaw:
Następnie wymuś egzekwowanie zarówno w trasach UI, jak i w endpointach API.
Zaimplementuj i przetestuj obie warstwy:
401 gdy brak logowania, 403 gdy zalogowany, ale brak uprawnieńPraktyczna zasada: jeśli UI blokuje akcję, API i tak musi ją odrzucić, jeśli zostanie wywołane bez uprawnień.
Domyślnie: email + hasło z utrzymaniem sesji po odświeżeniu.
Minimum do poproszenia o implementację:
POST /auth/login, POST /auth/logout, GET /auth/meWybierz jedną konwencję i egzekwuj ją wszędzie:
Jeśli coś zmieniasz później, poproś o plan rename (search/replace + migracje), zamiast pozwolić modelowi improwizować.
Poproś model o ten sam kształt dla każdego endpointu listy:
page, page_size, plus filtrytotal, page, page_size, itemsUżyj promptu audytowego, który porówna:
Następnie zastosuj minimalny plan naprawczy.
Dobra zasada: nie dodawaj funkcji podczas naprawiania rozbieżności — jedynie wyrównuj nazwy, trasy, walidacje i uprawnienia.
Seeduj jednego admina do lokalnych testów.
Wymagaj też stabilnego sortowania (np. created_at potem id), aby paginacja nie pomijała ani nie duplikowała rekordów.