Prompt Vibe untuk aplikasi CRUD: paket salin-tempel full-stack

Apa yang dibangun oleh set prompt ini (bahasa sederhana)

Set prompt ini dirancang untuk menghasilkan aplikasi CRUD lengkap yang bekerja: layar yang dipakai orang, API yang menangani permintaan, dan database PostgreSQL yang menyimpan datanya. Ini juga termasuk login dan akses berbasis peran, sehingga pengguna berbeda bisa melihat dan melakukan hal berbeda.

CRUD hanyalah empat aksi sehari-hari yang dibutuhkan aplikasi Anda:

• Create: menambah record baru (mis. customer atau tugas)
• Read: melihat daftar dan membuka satu item
• Update: mengubah item yang ada
• Delete: menghapus item (sering dengan langkah konfirmasi)

Di front end, Anda seharusnya mendapat set layar yang dapat diprediksi: halaman daftar, halaman detail, form buat, form edit, plus halaman login dan navigasi dasar. Di back end, Anda akan punya endpoint yang cocok dengan layar tersebut (list, get by id, create, update, delete), didukung oleh tabel Postgres dan validasi sederhana.

Kualitas prompt lebih penting daripada pilihan model. Model hanya bisa mengikuti apa yang Anda spesifikasikan. Jika prompt Anda kabur, Anda akan mendapatkan nama field yang tidak cocok, route yang hilang, auth yang tidak lengkap, atau UI yang tidak selaras dengan API. Prompt yang ketat bertindak seperti kontrak: UI, API, dan database semua setuju pada nama dan aturan yang sama.

Sebelum mulai, tentukan beberapa detail agar build tetap konsisten:

• Entitas utama dan 6 sampai 12 field (nama, tipe, wajib vs opsional)
• Peran (misal: admin, manager, viewer) dan apa yang bisa dilakukan tiap peran
• Aturan dasar (siapa yang bisa mengedit, soft delete vs hard delete, field wajib)
• "Happy path" layar yang Anda butuhkan di hari pertama
• Batasan apa pun (field unik, rentang tanggal, nilai status)

Jika Anda menggunakan Koder.ai, ini bisa menjadi satu percakapan yang menghasilkan UI React, API Go, dan skema PostgreSQL yang cocok bersama tanpa perlu glue manual.

Lembar kerja persiapan: beberapa detail yang Anda butuhkan sebelum mem-prompt

Build CRUD yang baik dimulai dengan serangkaian keputusan kecil. Tulis dulu dan prompt Anda akan lebih jelas, layar terlihat benar, dan API cocok dengan database.

Mulai dengan satu entitas inti. Ini adalah “benda” yang dikelola aplikasi Anda setiap hari (Item, Customer, Appointment). Tambah entitas kedua hanya jika benar-benar diperlukan di hari pertama (mis. Item butuh Category). Jika Anda mulai dengan tiga atau empat, Anda akan menghabiskan sebagian besar waktu merapikan relasi daripada mendapatkan aplikasi yang berfungsi.

Tulis field entitas Anda dengan tipe dan contoh. Contoh itu penting karena memandu label, format, dan validasi.

• Field: tipe - contoh (catatan)
• name: text - "Paper towels" (wajib, 2-80 chars)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (opsional)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

Selanjutnya, daftarkan peran dan izin dalam bahasa biasa. Jaga agar spesifik. Untuk banyak aplikasi, 2–3 peran sudah cukup:

• Admin: manage users, full CRUD pada semua record
• Manager: CRUD pada record, tidak bisa manage users
• Viewer: hanya baca

Terakhir, buat 5–10 record sampel. Ini menghasilkan label UI yang realistis, opsi dropdown, dan default yang masuk akal. Contoh (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

Jika Anda membangun di Koder.ai, paste lembar kerja ini ke prompt pertama Anda sehingga platform bisa menjaga konsistensi aplikasi di layar, auth, dan API yang didukung PostgreSQL.

Prompt dasar: tetapkan aturan untuk seluruh build

Mulailah dengan satu prompt "aturan jalan". Ini menjaga build konsisten di layar, API, dan database, serta mengurangi bolak-balik saat Anda menambahkan fitur nanti.

Minta rencana singkat sebelum kode apa pun. Anda ingin model menamai layar dan rute, tabel, dan endpoint API. Juga minta model menyatakan asumsi di awal (mis. peran apa yang ada) dan mempertahankan asumsi tersebut kecuali Anda menyetujui perubahan.

Berikut prompt base yang bisa di-copy-paste:

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.

Contoh konkret: jika rencana memilih role: admin|member, itu tidak boleh kemudian mengarang manager untuk menyelesaikan kasus edge UI. Prompt ini memaksa model berhenti dan meminta persetujuan Anda alih-alih mengubah asumsi secara diam-diam.

Prompt copy-paste: layar dan navigasi

Layar yang baik berasal dari peta halaman yang jelas terlebih dulu. Gunakan prompt di bawah sebelum meminta kode database atau API. Ini menjaga rute dan nama UI stabil, yang sering menjadi sumber masalah.

Prompt 1: daftar halaman dan alur pengguna

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.

Setelah jawabannya kembali, kunci nama-nama tersebut. Jika Anda mengubah nama rute nanti, API dan test akan meleset.

Prompt 2: navigasi dan form yang berperilaku baik

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.

Jika UI terlalu kompleks, minta agar hanya satu layout, satu gaya tabel, dan satu pola form dipakai di seluruh halaman.

Prompt copy-paste: autentikasi dan peran

Untuk hasil yang dapat diprediksi, jelaskan secara eksplisit bagaimana pengguna login, berapa lama sesi bertahan, dan apa yang boleh dilakukan tiap peran. Prompt ini mengasumsikan login sederhana email + password dan pendekatan berbasis sesi (mudah diuji di seluruh layar dan API).

Tempelkan ini pertama untuk menghasilkan login, logout, dan penanganan sesi:

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.

Sekarang tambahkan peran dan aturan proteksi. Jaga izin kecil dan mudah diuji:

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.

Pemeriksaan manual cepat yang menangkap sebagian besar kesalahan:

• Login sebagai tiap peran dan konfirmasi apa yang bisa dan tidak bisa Anda lihat.
• Coba aksi terbatas (mis. delete) dan konfirmasi Anda mendapat 403.
• Konfirmasi logout menghapus sesi dan aplikasi kembali ke layar Login.

Jika Anda membangun di Koder.ai, jaga perubahan auth dan RBAC dalam satu snapshot sehingga Anda bisa rollback dengan bersih jika izin menjadi berantakan.

Prompt copy-paste: skema PostgreSQL dan model data

Prompt skema yang baik melakukan dua hal: memaksa relasi tabel yang jelas (supaya layar dan API tetap konsisten), dan mencegah database yang “hampir benar” (kekurangan index, timestamps, atau pemetaan peran).

Sebelum menempel, tentukan dua toggle ini (satu baris tiap toggle):

• Primary keys: uuid or bigserial
• Soft delete: yes (use deleted_at) or no (hard delete)

Tempelkan prompt ini dulu untuk mengunci model data:

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.

Lalu tempelkan prompt ini untuk menghasilkan migration atau langkah setup yang cocok dengan proyek:

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

Jika ada yang ambigu, tambahkan satu baris: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Prompt copy-paste: Go CRUD API (Postgres-backed)

Jika keluaran backend terus setengah selesai, prompt ini memaksa dasar-dasarnya: rute yang jelas, validasi, paginasi, dan pengecekan peran pada setiap handler.

Salin-tempel ini apa adanya, lalu ganti placeholder (RESOURCE, FIELDS, ROLES) dengan detail aplikasi Anda.

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

Setelah generasi, lakukan satu pengecekan cepat untuk konsistensi: kode status cocok dengan body error, endpoint list mengembalikan ordering stabil, dan tiap handler memeriksa peran serta kepemilikan tenant sebelum menyentuh database.

Jika Anda menggunakan Koder.ai, juga catat bahwa backend harus tetap di Go dan database tetap PostgreSQL agar kode yang diekspor cocok dengan stack yang diharapkan.

Langkah demi langkah: generate, jalankan, dan verifikasi

Hasilkan semuanya (UI, API, database), lalu beralih ke mode verifikasi ketat. Tujuannya bukan mengagumi layar—melainkan membuktikan loop penuh bekerja: UI - auth - roles - Postgres - API - UI.

Run verifikasi sederhana

1. Jalankan app dan buka layar home. Konfirmasi navigasi bekerja dan Anda tidak melihat data placeholder. Jika halaman kosong, catat pesan error pertama yang terlihat (toast UI, console, atau log server).

2. Buat satu akun test per peran (Admin, Manager, Viewer). Login dan logout dengan tiap user. Konfirmasi aplikasi menampilkan peran di tempat yang terlihat (menu profil, settings, atau badge kecil).

3. Pilih satu layar CRUD dan lakukan siklus penuh: buat record, refresh halaman, lalu edit dan delete. Cek utama adalah persistensi: setelah refresh, record harus mencerminkan apa yang ada di Postgres, bukan hanya di memori.

4. Coba aksi terlarang dengan sengaja. Login sebagai peran terendah dan coba akses layar admin, panggil aksi terbatas (mis. delete), dan edit record yang seharusnya tidak bisa Anda ubah. Anda ingin hasil yang jelas: UI diblokir dengan pesan, atau error 403 tanpa perubahan data.

5. Uji kasus tepi dasar: list kosong, nama sangat panjang, field wajib hilang, dan format invalid (email, tanggal). Konfirmasi aplikasi menampilkan validasi yang membantu dan tidak crash.

Jika Anda menggunakan Koder.ai, ambil snapshot segera setelah tes end-to-end CRUD pertama sukses. Ini memberi titik rollback aman sebelum menambah fitur.

Kegagalan prompt umum dan cara memperbaikinya

Kebanyakan build yang “rusak” sebenarnya bukan rusak. Mereka hanya kekurangan satu constraint yang menjaga UI, API, dan database konsisten.

1) Anda meminta terlalu banyak sekaligus

Saat Anda meminta layar, auth, roles, skema, dan semua edge case sekaligus, aplikasi sering menjadi tidak konsisten (rute tidak cocok, model melenceng, halaman setengah jadi).

Perbaikan: pisahkan berdasarkan lapisan dan paksa tool untuk mengulang apa yang akan dihasilkannya sebelum menulis kode. Di Koder.ai, ini juga membantu menyelaraskan beberapa agen.

2) Peran kabur sehingga pengecekan hilang

Jika Anda hanya menulis “admin dan user”, Anda mungkin mendapat label peran di UI tapi tidak ada otorisasi sisi server.

Perbaikan: definisikan izin sebagai aksi (create, read, update, delete) per resource, dan minta penegakan di server-side pada setiap endpoint.

3) Tipe field hilang menyebabkan drift UI dan DB

Jika Anda menggambarkan field secara sederhana (“price”, “date”, “status”), form mungkin merender input teks sementara Postgres mengharapkan angka, tanggal, atau enum.

Perbaikan: spesifikasikan tipe field, nullability, default, dan constraints, serta minta aturan validasi yang dibagi bersama.

4) Tidak ada loading dan error state, jadi UI terlihat rusak

Tanpa loading dan error state, permintaan yang gagal terlihat seperti halaman membeku.

Perbaikan: minta spinner loading, empty state, dan pesan error yang terlihat untuk tiap layar.

5) Nama berubah di tengah build

Mengganti “Projects” menjadi “Workspaces” setengah jalan sering memecah rute, handler, dan nama tabel.

Perbaikan: kunci kamus istilah di awal. Saat mengubah nama, minta rencana rename (search, replace, migrate) daripada membiarkan model mengimprovisasi.

Gunakan prompt perbaikan ini saat sesuatu melenceng:

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.

Jika inkonsistensi terus muncul, Anda mungkin kekurangan pernyataan "single source of truth". Tambahkan satu kalimat: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Daftar periksa cepat sebelum menganggap selesai

Sebelum Anda menghabiskan waktu memoles, lakukan pengecekan cepat untuk memastikan aplikasi berperilaku seperti produk nyata. Di sinilah sebagian besar aplikasi CRUD gagal: mismatch kecil antara layar, aturan, dan data.

• Layar sesuai spes entitas: setiap layar (list, details, create, edit) memakai nama entitas dan daftar field yang tepat.
• Peran tidak ambigu: tulis tabel allow/deny per peran dan pastikan UI dan API menegakkan aturan yang sama.
• Response API konsisten: pilih satu pola (kode status, bentuk error, bentuk paginasi) dan verifikasi setiap endpoint mengikutinya.
• Constraint DB cocok validasi form: jika DB mengharuskan email unik atau name non-null, validasi sebelum submit dan tampilkan pesan jelas saat API menolak.
• Create/edit/delete bertahan setelah refresh: buat record, refresh, konfirmasi masih ada; edit, refresh, konfirmasi; delete, refresh, konfirmasi.

Tes konkret: login sebagai peran dengan permission terendah dan coba aksi yang Anda harapkan diblokir (mis. delete). Jika berhasil, perbaiki policy di satu tempat (API) terlebih dahulu, lalu sesuaikan UI.

Contoh realistis: pelacak inventori sederhana

Bayangkan tim IT kecil yang meminjamkan laptop, monitor, dan adaptor ke staf. Mereka butuh satu tempat untuk melihat ketersediaan, siapa memegang apa, dan kapan harus dikembalikan. Ini kasus uji yang baik karena memaksa peran, beberapa layar, dan database nyata.

Lembar kerja yang diisi

Gunakan ini sebagai input persiapan Anda (salin apa adanya, lalu sesuaikan nama):

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)

Urutan paste

Tempel prompt Anda dalam urutan ini agar aplikasi tetap konsisten:

1. Prompt base (aturan global, stack, penamaan, penanganan error)
2. Layar dan navigasi (Inventory, Requests, Loans, Admin queue)
3. Autentikasi dan peran (admin, staff, viewer permissions)
4. Skema PostgreSQL dan data seed (items, loans, requests, users)
5. Go CRUD API (endpoint dan validasi yang cocok dengan aturan)

Hasil yang baik terlihat seperti ini: staff dapat request “MBP-014”, admin bisa menyetujui dengan due date, dan daftar inventori menampilkan item tersebut sebagai tidak tersedia dengan nama peminjam.

Jika build hampir benar tapi tidak pas, ubah satu hal saja: perketat permission (viewer tidak boleh lihat tombol edit), ulangi aturan "hanya satu active loan per item", atau minta rename field sehingga label UI dan kolom DB cocok.

Langkah selanjutnya: perpanjang dengan aman dan gunakan ulang set prompt

Setelah dasar bekerja, perlakukan perubahan berikutnya seperti rilis kecil. Pilih satu fitur, tentukan apa arti “done”, lalu prompt untuk itu.

Urutan yang masuk akal untuk banyak aplikasi:

• Audit log: catat siapa mengubah apa dan kapan (create, update, delete), dan tampilkan di layar admin saja.
• File uploads: lampirkan dokumen atau gambar pada record, simpan metadata di Postgres, dan jaga akses di balik auth.
• Notifikasi sederhana: tampilkan alert di aplikasi (mis. “low stock” atau “komentar baru”), dengan aksi “mark as read”.

Saat perubahan merusak build, jangan mencoba memperbaiki semuanya sekaligus. Roll back, lalu terapkan perubahan dalam prompt yang lebih kecil dan spesifik. Jika Anda menggunakan Koder.ai, snapshot dan rollback adalah jaring pengaman praktis, terutama sebelum perubahan yang mempengaruhi skema DB, aturan auth, atau komponen UI bersama.

Mode Perencanaan juga membantu ketika fitur menyentuh banyak lapisan. Minta model menyatakan rencana dulu (layar, endpoint API, perubahan DB, peran), lalu setujui rencana itu sebelum menghasilkan kode. Ini mencegah mismatch umum di mana UI mengharapkan field yang tidak dikembalikan API, atau API menulis ke kolom yang tidak ada.

Jika Anda ingin melanjutkan di luar platform, ekspor source code dan lanjutkan di alur kerja biasa. Simpan set prompt bersama repo sebagai "instruksi build" sehingga Anda bisa mereplikasi aplikasi nanti atau mempercepat onboarding orang baru.

Jika Anda membangun di Koder.ai (koder.ai), set prompt ini selaras dengan default React + Go + PostgreSQL platform dan mudah diiterasi dengan snapshot sambil menyempurnakan kebutuhan.

Akhirnya, simpan template prompt yang dapat dipakai ulang untuk proyek berikutnya. Pertahankan bagian stabil (stack, aturan CRUD, konvensi auth dan peran, pola Postgres) dan ganti hanya noun domain. Seiring waktu, prompt Anda menjadi resep yang bisa diulang, bukan percobaan satu kali.