40 Best Replit Agent Prompts (2026)

Build a team task-manager web app.
Who it's for: small teams that need to track work across projects.
Core flows: sign up and log in → create a project → add tasks to a project → assign a task to a teammate and set status/due date → view a board grouped by status.
Data model: Users, Projects(name, owner), Tasks(title, description, status[Todo/Doing/Done], due_date, assignee, project_id), Memberships(user_id, project_id, role).
Stack: you choose the stack; use Replit Auth for login and Postgres for data.
Design: clean and modern, mobile-responsive, primary color [#4f46e5], light and dark mode.
Scope for this pass: auth, projects, tasks, assignment, and a Kanban-style board. Out of scope: billing, notifications, file attachments — do not build these yet.
Run in Plan Mode first, propose a plan, and wait for my approval. After building, test the full flow in the browser yourself.

Build a lightweight CRM web app for a solo founder tracking sales.
Core flows: log in → add a contact → log an interaction (call/email/meeting) against a contact → move a contact through pipeline stages → see a dashboard of deals by stage.
Data model: Users, Contacts(name, company, email, phone, stage[Lead/Contacted/Qualified/Won/Lost], owner), Interactions(contact_id, type, note, date), Deals(contact_id, value, stage, close_date).
Stack: Replit Auth for login, Postgres for storage.
Design: clean, table-and-detail layout, mobile-friendly, primary color [#0f766e].
Scope this pass: contacts, interactions, pipeline stages, and a simple deals-by-stage dashboard. Out of scope: email sending, imports, and multi-user teams — leave these for later.
Use Plan Mode, then build, then test adding a contact and moving it through stages.

Build an appointment-booking web app for a [service business, e.g. a barber shop].
Who it's for: a customer booking a slot and an owner managing availability.
Core flows: owner logs in and sets available time slots → a public booking page lists open slots → a customer picks a slot and enters name/email → the slot is reserved and shows a confirmation → owner sees today's bookings.
Data model: Users(owner), Services(name, duration, price), Slots(service_id, start_time, is_booked), Bookings(slot_id, customer_name, customer_email, status).
Stack: Replit Auth for the owner, Postgres for data; the customer booking page is public (no login).
Design: clean, calendar-style slot picker, mobile-first, primary color [#2563eb].
Scope this pass: availability, public booking, confirmation, and an owner day view. Out of scope: payments and reminders — do not add them yet.
Run in Plan Mode and confirm the plan before building.

Build a minimal two-sided marketplace for [category, e.g. freelance tutoring].
Core flows: sign up as a buyer or a seller → sellers create listings → buyers browse and search listings → a buyer opens a listing and sends an inquiry message → both sides see their inquiries.
Data model: Users(role[buyer/seller]), Listings(seller_id, title, description, price, category, status), Inquiries(listing_id, buyer_id, message, created_at).
Stack: Replit Auth with a role field, Postgres for data.
Design: card grid for listings, clean and trustworthy, mobile-responsive, primary color [#7c3aed].
Scope this pass: roles, listings CRUD, browse/search, and inquiry messaging. Out of scope: payments, reviews, and real-time chat — leave for later passes.
Use Plan Mode first. After building, test the seller-creates-listing and buyer-inquires flows in the browser.

Build a SaaS starter web app with a free tier and one paid plan.
Who it's for: an indie maker who wants auth plus subscription billing wired up.
Core flows: sign up and log in → land on a dashboard showing plan status → click Upgrade → complete Stripe Checkout in test mode → return to the dashboard now showing the paid plan → a Stripe webhook keeps plan status in sync.
Data model: Users(plan[free/pro], stripe_customer_id, subscription_status), and one example feature table [Notes(user_id, text)] gated so free users get [5] and pro is unlimited.
Stack: Replit Auth, Postgres, and the Stripe integration; put the Stripe secret key and webhook secret in Secrets.
Design: clean dashboard, clear upgrade CTA, mobile-responsive.
Scope this pass: auth, Stripe Checkout (test mode), webhook-driven plan sync, and the free-vs-pro gate. Out of scope: multiple plans, annual billing, proration.
Done looks like: I can upgrade with a Stripe test card and see my plan flip to pro. Run in Plan Mode first.

Build an internal admin dashboard to manage [entity, e.g. products].
Who it's for: an ops admin who needs to create, edit, and delete records.
Core flows: log in → see a searchable, paginated table of [products] → create a new record via a form → edit or delete an existing record → filter by [status/category].
Data model: Users(role[admin]), Products(name, sku, price, stock, category, status, updated_at).
Stack: Replit Auth restricted to admins, Postgres for data.
Design: dense, functional table UI, clear forms, mobile-usable, primary color [#111827].
Scope this pass: auth-gated CRUD, search, filter, pagination. Out of scope: bulk actions and audit logs.
Run in Plan Mode, then build, then test creating, editing, filtering, and deleting a record.

Build an internal KPI dashboard for [team, e.g. the sales team].
Core flows: log in → see top-line KPI cards ([revenue], [new customers], [churn]) → view charts of each metric over the last [12] weeks → filter by [region and date range].
Data model: read from a Postgres table [metrics(date, region, revenue, new_customers, churned)]; seed it with realistic sample rows so the charts render.
Stack: Replit Auth for access, Postgres for data.
Design: clean dashboard, KPI cards on top, responsive charts below, one-line insight under each chart, primary color [#0369a1].
Scope this pass: KPI cards, time-series charts, and filters, all read-only. Out of scope: data entry and exports.
Define each metric's formula in a small Definitions section on the page. Run in Plan Mode first.

Build an internal tool to import and clean CSV files.
Core flows: log in → upload a CSV → preview the parsed rows and detected columns → map columns to fields [Name, Email, Company] → the tool validates rows (flagging bad emails and missing required fields) → import valid rows into the database and show a summary of imported vs skipped.
Data model: Users, Contacts(name, email, company, source_file, imported_at), ImportLogs(file_name, rows_total, rows_imported, rows_skipped, created_at).
Stack: Replit Auth, Postgres.
Design: stepper UI (upload → map → validate → import), clear error highlighting.
Scope this pass: upload, column mapping, validation, import, and an import log. Out of scope: scheduled imports and de-duplication across files.
Handle malformed CSVs gracefully with a friendly error rather than crashing. Run in Plan Mode first.

Build an internal approval-workflow tool for [request type, e.g. expense requests].
Core flows: an employee logs in and submits a request with details and amount → the request appears in a manager's queue as Pending → the manager approves or rejects with a comment → the employee sees the updated status and comment.
Data model: Users(role[employee/manager]), Requests(submitter_id, title, amount, description, status[Pending/Approved/Rejected], decided_by, decision_comment, created_at).
Stack: Replit Auth with roles, Postgres.
Design: two clear views — a submit form for employees and a review queue for managers — mobile-usable.
Scope this pass: submit, manager queue, approve/reject with comment, status visible to submitter. Out of scope: multi-step approvals and email alerts.
Enforce that only managers can approve. Run in Plan Mode and confirm the role rules before building.

Build an internal inventory-management tool for a small [warehouse/store].
Core flows: log in → view items with current stock → add or edit an item → record a stock movement (in/out with quantity and reason) → see low-stock items highlighted below a reorder threshold.
Data model: Users, Items(sku, name, unit, quantity_on_hand, reorder_level, location), Movements(item_id, change, reason, created_at, user_id).
Stack: Replit Auth, Postgres.
Design: clear table with a low-stock badge, quick stock-adjust modal, mobile-usable.
Scope this pass: items CRUD, stock movements that update on-hand counts, and low-stock highlighting. Out of scope: purchase orders and suppliers.
Make quantity_on_hand always recompute from movements so it can't drift. Run in Plan Mode first.

Build an internal support-ticket viewer.
Core flows: an agent logs in → sees a list of tickets filterable by status and priority → opens a ticket to read the message thread → replies and changes status/priority → the ticket list updates.
Data model: Users(role[agent]), Tickets(subject, requester_email, status[Open/Pending/Closed], priority[Low/Med/High], assignee, created_at), Messages(ticket_id, author, body, created_at).
Stack: Replit Auth for agents, Postgres.
Design: two-pane layout (list + detail), status/priority badges, mobile-collapsible.
Scope this pass: ticket list, filters, thread view, reply, and status/priority changes. Out of scope: inbound email ingestion and SLA timers.
Seed a few sample tickets so the UI is populated. Run in Plan Mode first.

Build a REST API for a [tasks] resource.
Endpoints: GET /tasks (list, with ?status= filter), GET /tasks/:id, POST /tasks, PATCH /tasks/:id, DELETE /tasks/:id.
Data model: Task(id, title, description, status[open/done], due_date, created_at) stored in Postgres.
Behavior: validate request bodies and return clear 400 errors on bad input, 404 when a task isn't found, and JSON responses throughout.
Stack: you choose the language/framework; use Postgres for storage.
Scope this pass: the five endpoints, validation, and correct status codes. Out of scope: auth, pagination, rate limiting.
Include a short README documenting each endpoint with an example request and response. After building, test each endpoint yourself and confirm the status codes. Run in Plan Mode first.

Build a JSON API secured with API keys.
Behavior: every request must send an Authorization: Bearer [api_key] header; reject missing or invalid keys with 401. Provide an endpoint to create a key for a user and store only a hash of the key.
Endpoints: POST /keys (issue a key, shown once), and a protected GET /me returning the caller's account plus GET/POST /items for a simple [items] resource scoped to the key's owner.
Data model: ApiKeys(id, user_id, key_hash, created_at, last_used_at), Items(owner_id, name, value).
Stack: Postgres for storage; never log full API keys.
Scope this pass: key issuance, hashed storage, bearer auth middleware, and owner-scoped items. Out of scope: scopes/permissions and key rotation UI.
Test with a valid and an invalid key and confirm 200 vs 401. Run in Plan Mode first.

Build a webhook-receiver service for [provider, e.g. Stripe or GitHub].
Behavior: expose POST /webhooks/[provider] that verifies the signature using a signing secret from Secrets, responds 200 quickly, and records each event. On an unverified signature, return 400 and do not process.
Data model: WebhookEvents(id, provider, event_type, payload_json, signature_valid, received_at, processed).
Stack: Postgres for the event log; put the signing secret in Secrets.
Scope this pass: the endpoint, signature verification, event logging, and idempotent handling (ignore duplicate event ids). Out of scope: acting on specific event types beyond logging.
Add a simple GET /webhooks/recent (protected) to view the last [50] events for debugging. Test with a signed and an unsigned request. Run in Plan Mode first.

Build an API that accepts file uploads and processes them.
Endpoints: POST /upload (accepts a [CSV/image] file, max [10]MB), GET /files (list uploads), GET /files/:id (status + result).
Behavior: validate file type and size, store the file, process it asynchronously ([parse the CSV into rows] / [generate a thumbnail]), and update the record's status from pending → done → or failed with an error message.
Data model: Files(id, filename, size, mime_type, status, result_json, error, created_at).
Stack: Postgres for metadata; you choose file storage.
Scope this pass: upload validation, storage, async processing, and status polling. Out of scope: auth and virus scanning.
Reject oversized or wrong-type files with a clear 400. Test the happy path and a rejected file. Run in Plan Mode first.

Build a single flexible query endpoint for a small [blog] dataset.
Behavior: expose POST /query that accepts a JSON body specifying which resource and fields to return and simple filters, e.g. { "resource": "posts", "fields": ["title","author"], "where": { "published": true } }. Return only the requested fields.
Data model: Authors(name, email), Posts(title, body, author_id, published, created_at), with a couple of seeded rows.
Stack: Postgres for storage.
Scope this pass: the /query endpoint for posts and authors, field selection, and equality filters. Out of scope: nested joins, mutations, and full GraphQL spec compliance.
Validate the requested resource and fields and return a 400 for unknown ones. Include a README with example queries. Run in Plan Mode first.

Add Stripe one-time checkout to my app.
Flow: a Buy button creates a Stripe Checkout session for a [$29] product → the user pays with a test card → Stripe redirects back to a success page → a Stripe webhook marks the order as paid.
Data model: Orders(id, user_id, amount, status[created/paid], stripe_session_id, created_at).
Stack: use the Stripe integration; store STRIPE_SECRET_KEY and the webhook signing secret in Secrets. Run in Stripe test mode.
Scope this pass: checkout session, success/cancel pages, webhook that flips order status to paid, and idempotent webhook handling. Out of scope: refunds and subscriptions.
Done looks like: I click Buy, pay with test card 4242 4242 4242 4242, and the order shows paid. Test this flow yourself. Run in Plan Mode first.

Add Slack notifications to my app.
Flow: whenever a [new signup] happens, post a message to a Slack channel via an incoming webhook, formatted as "New signup: [name] ([email])".
Stack: use the Slack integration or an incoming webhook URL stored in Secrets as SLACK_WEBHOOK_URL. Never hardcode the URL.
Scope this pass: send a formatted message on the [signup] event, with retry once on failure and a log entry recording success/failure. Out of scope: slash commands and interactive buttons.
Done looks like: creating a test [signup] posts a message to the channel. Add a temporary "Send test notification" button so I can verify, then we can remove it. Run in Plan Mode first.

Sync new records from my app to a Google Sheet.
Flow: when a new [order] is created, append a row to a Google Sheet with columns [Date, Customer, Amount, Status].
Stack: use the Google Sheets integration; store credentials/keys in Secrets; I'll provide the target spreadsheet ID.
Scope this pass: append-on-create, matching the column order exactly, with a log of each append (success/failure). Out of scope: two-way sync and updating existing rows.
Handle a failed append gracefully (log it, don't crash the app) and never write partial rows. Done looks like: creating a test order adds one correctly formatted row. Run in Plan Mode first.

Add SMS reminders via Twilio to my [appointments] app.
Flow: [24] hours before an appointment, send the customer an SMS: "Reminder: your appointment with [business] is on [date] at [time]."
Stack: use the Twilio integration; store TWILIO_ACCOUNT_SID, TWILIO_AUTH_TOKEN, and the from-number in Secrets.
Scheduling: run this as a Scheduled deployment that checks hourly for appointments in the next 24h that haven't been reminded yet.
Data model: add reminded_at to Appointments so each reminder is sent once.
Scope this pass: the scheduled check and single SMS send per appointment. Out of scope: two-way replies and rescheduling.
Done looks like: an appointment due tomorrow triggers exactly one SMS. Test with my own number first. Run in Plan Mode first.

Add transactional email via SendGrid.
Flow: send a welcome email on signup and a receipt email after a successful [order], each from a simple HTML template with a plaintext fallback.
Stack: use the SendGrid integration; store SENDGRID_API_KEY and the from-address in Secrets.
Data model: EmailLog(id, to, template, status, error, sent_at) so I can see what was sent.
Scope this pass: the two emails, templating with [name/order details], and the send log with error capture. Out of scope: marketing emails and unsubscribe management.
Handle send failures without breaking the signup/order flow. Done looks like: a test signup and a test order each produce a logged, delivered email. Test with my address. Run in Plan Mode first.

Add an AI [summarize] feature to my app.
Flow: on a [note/document], a "Summarize" button sends the text to an LLM and shows a 3-bullet summary, with a loading state and graceful error handling.
Stack: use an LLM integration; store the API key in Secrets as [PROVIDER]_API_KEY. Never expose the key to the client — call the model from the server.
Data model: cache the summary on the record (summary_text, summarized_at) so we don't re-call the model unnecessarily.
Scope this pass: the summarize endpoint, server-side call, caching, loading and error states. Out of scope: streaming and multi-language.
Guard against very long inputs (truncate with a note) and empty inputs (disable the button). Done looks like: clicking Summarize returns 3 bullets. Run in Plan Mode first.

Build a scheduled job that emails me a daily summary.
Flow: every day at [8am UTC], query the database for [yesterday's new signups, orders, and revenue], format a short HTML summary, and email it to [my address] via SendGrid.
Stack: deploy this as a Scheduled deployment (cron) running daily at [8am UTC]; store the email API key in Secrets.
Data model: reads existing tables; write a JobRun(id, ran_at, status, summary) row each run for observability.
Scope this pass: the scheduled query, the formatted email, and the job-run log. Out of scope: configurable schedules and multiple recipients.
Handle an empty day gracefully ("no activity yesterday"). Done looks like: a manual test run sends me one correctly formatted email. Run in Plan Mode first, and confirm it's a Scheduled deployment.

Build a browser quiz game on [topic].
Core flows: start screen → answer [10] multiple-choice questions one at a time with immediate right/wrong feedback → see a final score and a "Play again" button.
Data: a set of [10] questions, each with a prompt, 4 options, and the correct index — seed real questions about [topic].
Design: clean, colorful, big tappable answer buttons, mobile-first, a progress indicator, and a subtle correct/incorrect animation.
Stack: keep it client-side; no login or database needed.
Scope this pass: the quiz loop, scoring, and replay. Out of scope: leaderboards, timers, and categories.
After building, play through it once yourself in the browser and confirm scoring is correct. Run in Plan Mode if you'd like, but this is small enough to build directly.

Build a simple 2D browser arcade game: [a paddle-and-ball breakout clone].
Mechanics: the player moves a paddle with the arrow keys or mouse; a ball bounces and breaks a grid of bricks; clearing all bricks wins; missing the ball loses a life; 3 lives total.
UI: a score counter, lives display, start and game-over screens, and a restart button.
Design: crisp canvas rendering, smooth 60fps movement, responsive to the window, keyboard and touch controls.
Stack: pure client-side (HTML canvas + JS); no backend.
Scope this pass: core gameplay, scoring, lives, win/lose, and restart. Out of scope: levels, power-ups, and sound.
Play-test it yourself: confirm the ball bounces correctly, bricks break, and losing all lives ends the game.

Build an interactive ROI calculator web page for [product].
Behavior: the user enters [team size], [hours saved per person per week], and [hourly cost]; the page live-updates to show weekly, monthly, and annual savings, plus a simple bar chart.
Design: clean single page, big clear inputs, results card, mobile-responsive, and the formula shown on the page.
Stack: client-side only; no login or database.
Scope this pass: inputs, live calculation, results, chart, and input validation (handle empty/invalid values gracefully). Out of scope: saving results and lead capture.
Leave a clearly marked spot for me to add branding. Build it directly, then confirm the math with a sample: [10 people, 3 hours, $40].

Build a real-time multiplayer lobby prototype.
Core flows: a user enters a name and creates a room (gets a shareable room code) or joins with a code → everyone in the room sees the live list of players update in real time → the host can start the game, which flips all players to a shared "game started" screen.
Stack: use websockets for real-time updates; keep room state on the server; Postgres optional for persistence.
Design: simple, clear room code display, live player list, host controls, mobile-usable.
Scope this pass: create/join room, live player list, and a synchronized start. Out of scope: the actual game and reconnection handling.
This is non-trivial — run in Plan Mode first, approve the plan, then build. Test by opening two browser tabs and confirming both see each other.

Build a responsive one-page landing site for [product].
Sections: hero (headline + subhead + primary CTA button), a 3-feature row with icons, a social-proof strip, a short 5-question FAQ (accordion), and a footer with an email signup form.
Copy: [paste your copy, or say "write it from this description: ..."].
Design: clean and modern, brand color [#hex], sans-serif, generous spacing, fast-loading (no heavy libraries), mobile-first.
Stack: static front end; the signup form posts to [FORM ENDPOINT] — leave a clearly marked placeholder.
Scope this pass: all sections, responsive layout, and the CTA above the fold. Out of scope: a real backend for the form and analytics.
Deploy it as a Static deployment. Build directly, then check it on mobile and desktop widths.

Build a waitlist landing page for [upcoming product].
Core flows: a visitor reads the pitch → enters their email → the email is saved and they see a "you're on the list" confirmation with their position number.
Data model: Waitlist(id, email, created_at) with a unique constraint on email so duplicates aren't added twice.
Stack: small backend + Postgres to store emails; Replit Auth-gated admin page to view/export the list.
Design: focused single page, strong headline, one input, mobile-first, brand color [#hex].
Scope this pass: the pitch, email capture with de-dupe, confirmation with position, and an admin view. Out of scope: referral mechanics and email sending.
Validate the email and show a friendly error on bad input. Deploy as an Autoscale deployment. Run in Plan Mode first.

Build a personal portfolio website for a [role, e.g. product designer].
Sections: hero with name and one-line pitch, About, a Projects grid (each with image, title, description, and link), Skills, and a contact section with links [email, LinkedIn, GitHub].
Content: [paste your details, or leave placeholders I can edit].
Design: minimal, elegant, fast, dark-mode toggle, responsive, and accessible (good contrast, alt text).
Stack: static front end; no backend needed.
Scope this pass: all sections, projects grid, dark mode, responsiveness. Out of scope: a blog and a CMS.
Deploy as a Static deployment. Build directly, then check tab order and mobile layout.

Build a simple blog with a lightweight CMS.
Core flows: public visitors read a post list and individual posts (clean typography, reading time) → an authenticated admin logs in to create, edit, publish/unpublish, and delete posts using a markdown editor with live preview.
Data model: Users(role[admin]), Posts(title, slug, body_markdown, excerpt, status[draft/published], published_at, created_at).
Stack: Replit Auth for the admin, Postgres for posts; render markdown to HTML safely (sanitize).
Design: clean reading experience, responsive, primary color [#hex].
Scope this pass: public list/detail, admin CRUD, draft vs published, and slugs. Out of scope: comments, tags, and image uploads.
Sanitize markdown to prevent XSS. Run in Plan Mode first, then build and test publishing a post.

I'm getting this error: [paste the exact error text and stack trace].
It happens when I [action, e.g. submit the signup form].
Expected: [the form saves and I see a success message]. Actual: [the page crashes / shows a 500].
Before changing anything, find the root cause and tell me what's wrong and why. Then make the smallest fix that addresses the root cause — do not refactor unrelated code.
After fixing, test the [signup] flow in the browser and confirm the expected behavior. If your fix touches shared logic, add a short test so this can't regress.

The [checkout] flow is broken. Steps to reproduce: [1) add an item, 2) click checkout, 3) enter card].
Expected: [I reach a success page and the order is saved]. Actual: [it hangs on the payment step / no order is created].
Reproduce it yourself in the browser first to confirm you see the same thing. Then find the root cause, explain it in one paragraph, and fix only what's needed for this flow.
Keep the change scoped to [checkout]; don't touch [the dashboard]. After the fix, run through the full flow again and confirm each step works.

We've been going back and forth on [issue] and each change is making things worse. Stop.
First, let's roll back: open History and restore the last checkpoint where [feature] worked ([describe or name the checkpoint]).
From that known-good state, do NOT start editing. In Plan Mode, investigate the single, specific problem — [describe the one symptom] — and propose the smallest possible plan to fix just that. List what you'll change and what you'll leave alone.
Wait for my approval before editing. We fix one thing, test it, then stop.

Refactor [file/path] — it's too large and hard to maintain.
Goal: split it into focused modules by responsibility [e.g. routes, data access, validation], with no change in behavior.
This is a risky refactor, so use Plan Mode: propose the new file structure and what moves where, and wait for my approval before touching code.
Rules: keep the public interface and all existing behavior identical; move code, don't rewrite logic; make small, reviewable steps. After each step, confirm the app still runs and the [key flows] still work.
If anything breaks, we roll back to the checkpoint before the refactor.

Add automated tests for [module/feature, e.g. the orders API].
Cover: the happy path plus the important edge cases — [invalid input, missing record, unauthorized access].
Use the standard testing framework for this stack and set up a single command to run all tests.
Scope this pass: tests for [orders] only, and any tiny code changes strictly needed to make the code testable. Out of scope: rewriting the feature.
After adding them, run the suite and show me the results. If a test reveals a real bug, tell me before fixing it so we decide together. Run in Plan Mode first if setup is non-trivial.

Deploy my web app so it has a live public URL.
This is a standard web app, so use an Autoscale deployment.
Before deploying: confirm all required secrets are set in Secrets (list what the app needs), make sure the app builds and starts cleanly, and check there are no hardcoded localhost URLs or dev-only settings.
Then deploy and give me the public URL. After it's live, open it in the browser and test the [main flow] end to end on the deployed version, not just the dev preview.
If deployment fails, show me the error, find the root cause, and fix it — don't retry blindly.

Add login to my app using Replit Auth.
Flow: an unauthenticated visitor sees a public [landing] page with a Log in button → after logging in with Replit Auth they reach the [dashboard] → a Log out button returns them to the landing page.
Rules: protect all [dashboard and API] routes so only logged-in users can access them; associate existing and new data with the logged-in user's id; unauthenticated requests to protected routes return a redirect or 401.
Scope this pass: Replit Auth wiring, route protection, and per-user data ownership. Out of scope: roles and social profiles.
After building, test: logged-out access to [dashboard] is blocked, and logging in shows only my own data. Run in Plan Mode first.

Design and set up the database schema for [app description] on Postgres.
Entities and key fields: [Users(email, name); Projects(name, owner_id); Tasks(title, status, due_date, project_id, assignee_id)] — infer sensible types, add primary keys, foreign keys, and indexes on fields I'll query/filter often ([status, project_id]).
Rules: use a migration so the schema is version-controlled and repeatable; add created_at/updated_at to each table; enforce referential integrity with foreign keys; seed a few realistic sample rows for local testing.
Scope this pass: schema, migration, indexes, and seed data. Out of scope: application code beyond what's needed to run the migration.
Explain the schema decisions briefly, then run the migration and confirm the tables exist. Run in Plan Mode first.

Add role-based access control to my app.
Roles: [admin, member, viewer]. Permissions: admins can [manage users and all records]; members can [create and edit their own records]; viewers can [read only].
Rules: store a role on each user (default [member]); enforce permissions on the server for every protected action, not just by hiding UI; return 403 when a user lacks permission; show/hide UI controls to match the role.
Data: add a role field to Users and a way for an admin to change another user's role.
Scope this pass: the three roles, server-side enforcement, an admin role-management screen, and matching UI. Out of scope: custom per-record sharing.
Test each role: confirm a viewer gets 403 on a write. Run in Plan Mode first, and confirm the permission matrix before building.