০৬ ডিসে, ২০২৫·6 মিনিট
Vibe coding prompts for CRUD app: full stack copy-paste set
এই প্রম্পট সেট ব্যবহার করে CRUD স্ক্রিন, অথ, রোল, এবং একটি PostgreSQL ব্যাকড API জেনারেট করুন। কপি-পেস্ট প্রম্পট সেট এবং ট্রাবলশুটিং টিপস।
এই প্রম্পট সেট ব্যবহার করে CRUD স্ক্রিন, অথ, রোল, এবং একটি PostgreSQL ব্যাকড API জেনারেট করুন। কপি-পেস্ট প্রম্পট সেট এবং ট্রাবলশুটিং টিপস।
এই প্রম্পট সেট একটি সম্পূর্ণ, কাজ করা CRUD অ্যাপ তৈরি করার জন্য ডিজাইন করা—সেই স্ক্রিনগুলো যা ব্যবহারকারী দেখবে, অনুরোধগুলো হ্যান্ডেল করবে এমন API, এবং ডেটা স্টোর করার জন্য PostgreSQL ডাটাবেস। এতে লগইন এবং রোল-ভিত্তিক অ্যাক্সেসও আছে, যেন বিভিন্ন ব্যবহারকারী ভিন্ন জিনিস দেখতে ও করতে পারে।
CRUD হলো চারটি দৈনন্দিন অপারেশন যা আপনার অ্যাপে দরকার:
ফ্রন্টএন্ডে, আপনি একটি পূর্বানুমেয় স্ক্রিন সেট পাবেন: একটি তালিকা পেজ, একটি ডিটেইল পেজ, একটি ক্রিয়েট ফর্ম, একটি এডিট ফর্ম, প্লাস একটি লগইন পেজ এবং বেসিক নেভিগেশন। ব্যাকএন্ডে, আপনার সেই স্ক্রিনগুলোর সঙ্গে মিলযুক্ত এন্ডপয়েন্ট থাকবে (list, get by id, create, update, delete), একটি Postgres টেবিল এবং সহজ ভ্যালিডেশন সহ।
প্রম্পটের গুণমান মডেল পছন্দের চেয়েও বেশি গুরুত্বপূর্ণ। মডেল কেবল আপনিই যা নির্দিষ্ট করবেন তা অনুসরণ করতে পারে। যদি আপনার প্রম্পট অস্পষ্ট হয়, আপনি পাবেন মিল না খাওয়া ফিল্ড নাম, অনুপস্থিত রুট, অসম্পূর্ণ অথ, বা এমন UI যা API-র সাথে মেলে না। একটি ধারাবদ্ধ প্রম্পট একটি কনট্রাক্টের মতো কাজ করে: UI, API, এবং ডাটাবেস একই নাম ও নিয়ম মানে।
শুরু করার আগে, কয়েকটি বিস্তারিত ঠিক করে নিন যাতে বিল্ড ধারাবাহিক থাকে:
আপনি যদি Koder.ai ব্যবহার করেন, এটি একটি কথোপকথনেই React UI, Go API, এবং PostgreSQL স্কিমা উৎপাদন করতে পারে যা আলাদা গ্লু ছাড়াই একসাথে কাজ করবে।
একটি ভাল CRUD বিল্ড কয়েকটি সিদ্ধান্ত থেকে শুরু হয়। প্রথমে সেগুলো লিখে নিন এবং আপনার প্রম্পটগুলো স্পষ্ট থাকবে, স্ক্রিনগুলো সঠিক দেখাবে, এবং API ডাটাবেসের সাথে মিলবে।
একটি কোর এন্টিটি দিয়ে শুরু করুন। এটি সেই “বস্তু” যাকে আপনার অ্যাপ প্রতিদিন পরিচালনা করবে (Item, Customer, Appointment)। দ্বিতীয় এন্টিটি শুধুমাত্র তখনই যোগ করুন যখন এটি প্রথম দিনে সত্যিই প্রয়োজন। যদি আপনি তিন বা চারটি দিয়ে শুরু করেন, আপনি বেশিরভাগ সময় সম্পর্কগুলো আলামত করতে কাটাবেন পরিবর্তে একটি কাজ করা অ্যাপ পাওয়ার।
আপনার এন্টিটির ফিল্ডগুলো টাইপ ও উদাহরণসহ লিখুন। উদাহরণ গুরুত্বপূর্ণ কারণ তা লেবেল, ফরম্যাটিং, এবং ভ্যালিডেশন নির্দেশ করে।
পরবর্তী, রোল এবং পারমিশনগুলি সাধারণ ভাষায় তালিকা করুন। এটি নির্দিষ্ট রাখুন। অনেক অ্যাপের জন্য 2 থেকে 3টি রোল যথেষ্ট:
শেষে, 5 থেকে 10টি নমুনা রেকর্ড তৈরি করুন। এগুলো বাস্তবসম্মত UI লেবেল, ড্রপডাউন অপশন, এবং যুক্তিসঙ্গত ডিফল্ট চালিত করে। উদাহরণ (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.
আপনি যদি Koder.ai-তে বিল্ড করছেন, প্রথম প্রম্পটে এই ওয়ার্কশিট পেস্ট করুন যাতে প্ল্যাটফর্ম UI, API, এবং PostgreSQL-ব্যাকড অ্যাপ জুড়ে কনসিস্টেন্ট থাকতে পারে।
একটি “রুলস অফ দ্য রোড” প্রম্পট দিয়ে শুরু করুন। এটি UI, API, এবং ডাটাবেস জুড়ে বিল্ড কনসিস্টেন্ট রাখে, এবং পরে ফিচার যোগ করলে ব্যাক-এন্ড-ফ্রন্ট-ইউআই-এর মধ্যে কম ফিডব্যাক লাগে।
কোনও কোড লেখার আগে একটি সংক্ষিপ্ত পরিকল্পনা চাইুন। আপনি চান মডেল স্ক্রিন এবং রুট, টেবিল, এবং API এন্ডপয়েন্টের নাম বলুক। এছাড়া অনুমানগুলো upfront বলুক (যেমন কোন রোল আছে) এবং অনুমান পরিবর্তন করলে অনুমতি চাইতে বলুন।
Here is a copy-paste base 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.
একটি বাস্তব উদাহরণ: যদি পরিকল্পনায় role: admin|member বেছে নেয়, পরে মডেল manager বানিয়ে ঝুঁকে উঠবে না—এই প্রম্পট এটিকে থামিয়ে আপনার অনুমতি চাইতে বাধ্য করে।
ভাল স্ক্রিনগুলো একটি পরিষ্কার পেজ ম্যাপ থেকে আসে। ডাটাবেস বা API কোড চাইবার আগে নীচের প্রম্পটগুলো ব্যবহার করুন। এতে রুট এবং UI নাম পরে স্থির থাকে, যা বহু বিল্ডে সমস্যা করে।
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.
এর উত্তর পাওয়ার পর নামগুলো লক করে দিন। যদি পরে রুট নাম পরিবর্তন করেন, API এবং টেস্টগুলো ড্রিফট করবে।
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.
UI যদি খুব জটিল আসে, বলুন এটি কেবল একটি লেআউট, একটি টেবিল স্টাইল, এবং একটি ফর্ম প্যাটার্ন রাখুক সব পেজে।
আপনি যদি পূর্বাভাসযোগ্য ফলাফল চান, ব্যবহারকারীরা কিভাবে লগ ইন করে, সেশন কতক্ষণ থাকবে, এবং প্রতিটি রোল কী করতে পারে তা স্পষ্ট করুন। নিচের প্রম্পটগুলো ধরে নিচ্ছে সহজ ইমেইল + পাসওয়ার্ড লগইন এবং সেশন-ভিত্তিক পদ্ধতি।
প্রথমে লগইন, লগআউট, এবং সেশন হ্যান্ডলিং জেনারেট করতে নিচটি পেস্ট করুন:
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.
এখন রোল এবং প্রটেকশন নিয়ম যোগ করুন। পারমিশনগুলো ছোট এবং টেস্ট করা সহজ রাখুন:
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.
দ্রুত ম্যানুয়াল চেকস যা বেশিরভাগ ভুল ধরবে:
আপনি যদি Koder.ai ব্যবহার করেন, auth এবং RBAC পরিবর্তনগুলো একসাথে রাখুন যাতে প্রয়োজনে রোলব্যাক করা যায়।
ভাল স্কিমা প্রম্পট দুই কাজ করে: পরিষ্কার টেবিল সম্পর্ক জোর করে (তাতে স্ক্রিন ও API কনসিস্টেন্ট থাকে), এবং “প্রায় ঠিক” ডাটাবেস (অনুপস্থিত ইনডেক্স, টাইমস্ট্যাম্প, বা রোল ম্যাপিং) প্রতিরোধ করে।
পেস্ট করার আগে এই দুই টগল ঠিক করুন (এক লাইন প্রতিটির জন্য):
uuid or bigserialyes (use deleted_at) or no (hard delete)এই প্রম্পটটি প্রথমে পেস্ট করুন ডাটা মডেল লক করতে:
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.
এরপর এই প্রম্পটটি পেস্ট করে মাইগ্রেশন বা সেটআপ স্টেপ জেনারেট করুন:
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
যদি কিছু অস্পষ্ট থাকে, একটি লাইন যোগ করুন: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”
আপনার ব্যাকএন্ড আউটপুট যদি বারবার অর্ধ-সম্পূর্ণ আসে, এই প্রম্পট বেসিক জোর দেয়: স্পষ্ট রুটস, ভ্যালিডেশন, পেজিনেশন, এবং প্রতিটি হ্যান্ডারে রোল চেক।
নিচেরটা 그대로 কপি-পেস্ট করুন, তারপর প্লেসহোল্ডারগুলো (RESOURCE, FIELDS, ROLES) আপনার অ্যাপ অনুযায়ী বদলান।
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
জেনারেশনের পর একটি দ্রুত কনসিস্টেন্সি পাস করুন: স্ট্যাটাস কোডগুলো ত্রুটি বডির সাথে ম্যাচ করে, লিস্ট এন্ডপয়েন্ট নির্ভরযোগ্য অর্ডার দেয়, এবং প্রতিটি হ্যান্ডার রোল ও টেন্যান্সি মালিকানা উভয়ই চেক করে।
আপনি যদি Koder.ai ব্যবহার করেন, ব্যাকএন্ড অবশ্যই Go তেই থাকা এবং ডাটাবেস PostgreSQL তেই থাকার কথা বলুন যাতে এক্সপোর্ট করা কোড প্রত্যাশিত স্ট্যাকের সাথে মেলে।
সবকিছু (UI, API, ডাটাবেস) জেনারেট করে, পরে স্ট্রিক্ট ভেরিফাই মোডে যান। লক্ষ্যটি পুরো লুপ প্রুফ করা: UI - auth - roles - Postgres - API - UI।
অ্যাপ চালান এবং হোম স্ক্রীন লোড করুন। নেভিগেশন কাজ করে কি এবং প্লেসহোল্ডার ডেটা দেখা যায় না কি নিশ্চিত করুন। পেজ খালি হলে প্রথম দৃশ্যমান এরর মেসেজ নোট করুন (UI টোস্ট, কনসোল, বা সার্ভার লগ)।
প্রতিটি রোলে একটি টেস্ট অ্যাকাউন্ট তৈরি করুন (Admin, Manager, Viewer)। প্রতিটি ইউজারে লগ ইন ও লগ আউট করে দেখুন অ্যাপ প্রোফাইল বা ব্যাজে রোল দেখাচ্ছে কি না।
একটি CRUD স্ক্রিন বেছে নিন এবং পুরো সাইকেল করুন: একটি রেকর্ড তৈরি করুন, পেজ রিফ্রেশ করুন, তারপর এডিট এবং ডিলিট করুন। মূল চেক হলো পারসিস্টেন্স: রিফ্রেশ করার পরে রেকর্ড Postgres-এ থাকা তথ্য প্রতিফলিত করবে, কেবল মেমরির নয়।
ইচ্ছাকৃতভাবে ফোবিডেন অ্যাকশন চেষ্টা করুন। সর্বনিম্ন রোলে লগ ইন করে অ্যাডমিন-অনলি স্ক্রিনে যাওয়া বা ডিলিট করার মতো সীমাবদ্ধ অ্যাকশন করুন এবং পরিষ্কার ফলাফল চান: ব্লক করা UI বা 403-ধাঁচের এরর, ডেটা পরিবর্তন ছাড়াই।
সহজ এজ-কেসগুলো পরীক্ষা করুন: খালি তালিকা, অত্যন্ত দীর্ঘ নাম, অনুপস্থিত বাধ্যতামূলক ফিল্ড, এবং ভ্যালিডেশন-ভুল ফরম্যাট (ইমেইল, তারিখ)। অ্যাপ হেল্পফুল ভ্যালিডেশন দেখায় এবং ক্র্যাশ করে না তা নিশ্চিত করুন।
আপনি যদি Koder.ai ব্যবহার করেন, প্রথম সফল end-to-end CRUD টেস্টের পরে স্ন্যাপশট নিন—এটি পরিবর্তনগুলোর আগে নিরাপদ রোলব্যাক পয়েন্ট দেয়।
অনেক “ব্রোকেন” বিল্ড আসলে পুরোপুরি ব্রোকেন নয়। এগুলো একটি কনস্ট্রেইন্টের অভাবের কারণে UI, API, এবং ডাটাবেসের মধ্যে মিলনের অভাব দেখায়।
যখন আপনি একসাথে স্ক্রিন, auth, রোল, স্কিমা, এবং সব এজকেস চেয়েছেন, অ্যাপ প্রায়ই অসমঞ্জস্যপূর্ণ হয়ে যায় (রুট মেলে না, মডেল ভাসমান, অর্ধেক-পূর্ণ পেজ)।
Fix: লেয়ার বাই লেয়ার ভাগ করুন এবং টুলকে কোড লেখার আগে কি তৈরি করবে তা পুনরায় বলাবেন। Koder.ai-তে এটা একাধিক এজেন্টকে অ্যালাইন রাখতেও সাহায্য করে।
যদি আপনি কেবল “admin and user” বলেন, আপনি UI-তে একটি রোল লেবেল পেতে পারেন কিন্তু সার্ভার-সাইড অথরাইজেশন পাওয়া নাও যেতে পারে।
Fix: পারমিশনগুলোকে অ্যাকশনের (create, read, update, delete) সাথে সংজ্ঞায়িত করুন প্রতিটি রিসোর্সে, এবং প্রতিটি এন্ডপয়েন্টে সার্ভার-সাইড এনফোর্সমেন্ট চাইুন।
যদি আপনি শুধু ফিল্ডগুলো সাদামাটা ইংরেজিতে বর্ণনা করেন (“price”, “date”, “status”), ফর্মগুলো টেক্সট ইনপুট হিসেবে রেন্ডার হতে পারে যখন Postgres সংখ্যা, তারিখ বা enum আশা করে।
Fix: ফিল্ড টাইপ, nullability, ডিফল্ট, এবং কনস্ট্রেইন্ট স্পষ্ট করুন, এবং শেয়ার্ড ভ্যালিডেশন রুলস দাবি করুন।
লোডিং এবং এরর স্টেট না থাকলে ব্যর্থ অনুরোধ একটি ফ্রোজেন পেজের মতো দেখায়।
Fix: প্রতিটি পেজে লোডিং স্পিনার, খালি স্টেট, এবং দৃশ্যমান এরর মেসেজ চাওয়া।
মধ্যপথে “Projects” কে “Workspaces” এ নামকরণ করলে প্রায়ই রুট, হ্যান্ডলার, এবং টেবিল নাম ভাঙে।
Fix: একটি গ্লসারি প্রথমে লক করুন। যখন নাম বদলাবেন, একটি rename plan (search, replace, migrate) চাইুন করে দিন—মডেলকে ছাড়বেন না।
এই রিপেয়ার প্রম্পটটি ব্যবহার করুন যখন কিছু পথভ্রষ্ট হয়:
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.
আপনি যদি ধারাবাহিক অনবধান পেয়ে থাকেন, সম্ভবত আপনি একটি “single source of truth” বিবৃতি মিস করছেন। একটি লাইন যোগ করুন: “The Postgres schema is the source of truth; UI and API must match it exactly.”
পলিশ করার আগে দ্রুত একটি পাস করে নিশ্চিত করুন অ্যাপটি বাস্তব প্রোডাক্টের মতো আচরণ করে। বেশিাংশ ফুল-স্ট্যাক CRUD অ্যাপ এখানে ব্যর্থ হয়: স্ক্রীন, নিয়ম, এবং ডেটার মধ্যে ছোটো মিলের সমস্যাগুলো।
একটি স্পষ্ট টেস্ট: সর্বনিম্ন পারমিশন থাকা রোলে লগ ইন করে এমন একটি অ্যাকশন চেষ্টা করুন যা আপনি ব্লক করতে চান (যেমন delete)। যদি তা সফল হয়, প্রথমে API-তে পলিসি ঠিক করুন, তারপর UI-কে মিলিয়ে নিন।
একটি ছোট IT টিম কল্পনা করুন যারা স্টাফদের কাছে ল্যাপটপ, মনিটর, এবং অ্যাডাপ্টার ধার দেয়। তাদের দরকার সবকিছু দেখতে, কে কি নিয়েছে এবং কখন রিটার্ন করবে তা ট্র্যাক করার এক জায়গা। এটি ভাল টেস্ট কারণ এটি রোল, কয়েকটি স্ক্রিন, এবং একটি বাস্তব ডাটাবেস চাপায়।
নিচেরটাকে আপনার প্রিপ স্টেপের ইনপুট হিসেবে ব্যবহার করুন (প্রতি টুকরা কপি করে প্রয়োজনে নাম বদলান):
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)
এই ক্রমে আপনার প্রম্পট পেস্ট করুন যাতে অ্যাপ কনসিস্টেন্ট থাকে:
একটি ভাল আউটকাম দেখতে এমন হবে: staff “MBP-014” অনুরোধ করতে পারে, admin তা অ্যাপ্রুভ করে একটি ডিউ ডেট দিয়ে চেক-আউট রেকর্ড করে, এবং ইনভেন্টরি তালিকা এটি অনউপলব্ধ হিসেবে দেখায় এবং ধারকারী নাম দেখায়।
যদি বিল্ড প্রায় ঠিক কিন্তু নয়, এক সময়ে এক জিনিস ঠিক করুন: রোল পারমিশন সংকোচন (viewer কখনও edit বাটন দেখবে না), “only one active loan per item” নিয়মটি আবার বলুন, অথবা ফিল্ডগুলোর নাম এমনভাবে বদলাতে বলুন যাতে UI লেবেল ও ডাটাবেস কলাম একে অপরের সাথে মেলে।
বেসিক কাজ হলে, পরবর্তী পরিবর্তনগুলোকে ছোট রিলিজ হিসেবে বিবেচনা করুন। একটি ফিচার বেছে নিন, “done” মানে কী তা নির্ধারণ করুন, তারপর সেই অনুযায়ী প্রম্পট দিন।
অনেক অ্যাপের জন্য একটি যুক্তিসঙ্গত অর্ডার:
কোনো পরিবর্তন বিল্ড ভাঙলে সব কিছু একসাথে ঠিক করার চেষ্টা করবেন না। রোলব্যাক করুন, তারপর ছোট, স্পেসিফিক প্রম্পটে পরিবর্তনগুলো পুনরায় প্রয়োগ করুন। যদি আপনি Koder.ai ব্যবহার করেন, স্ন্যাপশট এবং রোলব্যাক বাস্তবে নিরাপত্তার সঞ্চয় হিসেবে কাজে লাগে, বিশেষ করে ডাটাবেস স্কিমা, অথ রুলস, বা শেয়ার্ড UI কম্পোনেন্ট স্পর্শ করলে।
Planning Mode-ও সাহায্য করে যখন একটি ফিচার একাধিক লেয়ার ছুঁয়ে যায়। আগে পরিকল্পনাটি পুনরায় বলাতে বলুন (স্ক্রিন, API এন্ডপয়েন্ট, ডাটাবেস পরিবর্তন, রোলস), তারপর সেই পরিকল্পনা অনুমোদন করুন কোড জেনারেট করার আগে। এটি সাধারণ mismatch প্রতিরোধ করে যেখানে UI ফিল্ড আশা করে যা API দেয় না, অথবা API কলাম লিখে যা ডাটাবেসে নেই।
আপনি যদি প্ল্যাটফর্মের বাইরে কাজ চালিয়ে যেতে চান, সোর্স কোড এক্সপোর্ট করুন এবং আপনার স্বাভাবিক ওয়ার্কফ্লোতে পরিবর্তন করুন। প্রম্পট সেটটিকে রিপো পাশে “build instructions” হিসেবে রাখুন যাতে পরে অ্যাপ পুনরায় তৈরি করা যায় বা নতুন কাউকে onboard করা সহজ হয়।
যদি আপনি Koder.ai-এ বিল্ড করছেন (koder.ai), এই প্রম্পট সেট React + Go + PostgreSQL ডিফল্টগুলোর সাথে ভাল মিলবে, এবং স্ন্যাপশট ব্যবহার করে নিরাপদে পুনরাবৃত্তি করা সহজ হবে যখন আপনি রিকোয়ারমেন্ট পরিশোধ করবেন।
শেষে, আপনার পরবর্তী প্রকল্পের জন্য একটি পুনরায় ব্যবহারযোগ্য টেমপ্লেট প্রম্পট সংরক্ষণ করুন। স্থায়ী অংশগুলো (স্ট্যাক, CRUD রুলস, অথ ও রোল কনভেনশন, Postgres প্যাটার্ন) অপরিবর্তিত রাখুন এবং কেবল ডোমেইন নামগুলি বদলান। সময়ের সাথে, আপনার প্রম্পটগুলো একবার-ব্যবহারযোগ্য পরীক্ষার পরিবর্তে একটি পুনরাবৃত্ত রেসিপি হয়ে ওঠে।
প্রথমে একটি মূল এন্টিটি এবং তার 6–12টি ফিল্ড (নাম, টাইপ, প্রয়োজনীয়/ঐচ্ছিক, উদাহরণ) দিয়ে শুরু করুন। তারপর পরিষ্কারভাবে রোল + পারমিশন লক করে নিন, এবং যে কোনো কোড লেখার আগে সংক্ষিপ্ত পরিকল্পনা চাইুন।
একটি ভাল ডিফল্ট অর্ডার:
কারণ এটি UI, API, এবং ডাটাবেসকে একটি একক চুক্তি হিসেবে বিবেচনা করতে বাধ্য করে। অস্পষ্ট প্রম্পটগুলো প্রায়ই বিচ্যুতি তৈরি করে:
একটি সুনির্দিষ্ট প্রম্পট নাম, নিয়ম এবং যাচাইকরণ সব স্তরে মিলিয়ে দেয়।
প্রতিদিন আপনি যেটা পরিচালনা করবেন সেই মূল এন্টিটি বেছে নিন (Customer, Task, Item)। প্রথম দিন শুধুমাত্র একটি এন্টিটি রাখুন, যদি দ্বিতীয়টি সত্যিই প্রয়োজন না হয়।
একটি ব্যবহারযোগ্য ডিফল্ট:
কারণ উদাহরণগুলো লেবেল, ফরম্যাটিং, এবং ভ্যালিডেশন নির্দেশ করে। যদি আপনি শুধু “date” বা “status” বলেন, প্রায়ই UI-তে টেক্সট ফিল্ড এবং DB-তে date/enum মিসম্যাচ হবে।
একটি ধারাবাহিক ফিল্ড ফরম্যাট ব্যবহার করুন:
field_name: type - example (rules)এটি React ফর্ম, Go ভ্যালিডেশন, এবং PostgreSQL কনস্ট্রেন্টকে একসাথে রাখে।
২–৩টি রোল রাখুন এবং CRUD ক্রিয়াগুলোর সাথে সেগুলোকে ম্যাপ করুন: list, view, create, update, delete।
একটি শক্ত ডিফল্ট:
পরে নিশ্চিত করুন UI এবং API উভয়েই এটি প্রয়োগ করছে।
দুইটি জায়গায় পরীক্ষা করুন:
401, অথ থাকা সত্ত্বেও অনুমতি নেই হলে 403 রিটার্ন করুনপ্র্যাকটিকাল নিয়ম: UI যদি কোনো অ্যাকশন ব্লক করে, তখনও API সরাসরি কল করলে তা প্রত্যাখ্যান করবে।
ডিফল্ট হিসেবে email + password এবং রিফ্রেশে সেশন বজায় রাখুন।
কমপক্ষে যা চাইবেন:
POST /auth/login, POST /auth/logout, GET /auth/meএকটি কনভেনশন বেছে নিন এবং সব জায়গায় প্রয়োগ করুন:
নাম পরিবর্তন করলে rename plan (search/replace + migrations) চাইুন।
সব লিস্ট এন্ডপয়েন্টে একই রেসপন্স আকৃতি চাইুন:
page, page_size, এবং ফিল্টারগুলোtotal, page, page_size, itemsএকটি অডিট প্রম্পট ব্যবহার করুন যা তুলনা করে:
তারপর একটি মিনিমাল প্যাচ প্ল্যান প্রয়োগ করুন।
ভাল নিয়ম: ফিচার যোগ করার সময় mismatch ঠিক করবেন না—শুধু নাম, রুট, ভ্যালিডেশন এবং পারমিশন সামঞ্জস্য করবেন।
লোকাল টেস্টিং-এ একটি ডিফল্ট admin ইউজার সীড করুন।
স্টেবল সোর্টিংও চাইুন (উদাহরণ: created_at তারপর id) যাতে pagination-এ আইটেম মিস বা ডুপ্লিকেট না হয়।