BoilerPrompt
Replit Agent

Replit Agent prompt to build a to-do app

A to-do app is the fastest way to see how Replit Agent handles a full CRUD loop: Postgres persistence, per-user sign-in, and a live webview to click through. This prompt pins down the data model and interactions up front, so you end up with a deployable per-user task list instead of a demo that forgets state on refresh.

Last updated

Prompt
Build a to-do app as a full-stack Repl: React frontend, Express backend, and the built-in Postgres database. Hold your questions until the first working version is in the webview.

Data model: a tasks table with id, title, notes, due_date, completed_at, position, and user_id. Wire sign-in through Replit Auth so each user only sees their own tasks.

Screens: a single main view with an always-focused quick-add input at the top, the task list below, and filter tabs for Today, Upcoming, and Done. Editing happens inline, no modal. Completed tasks drop to the bottom with strikethrough.

Behaviors: Enter adds a task, clicking the checkbox toggles completion, drag to reorder persists position to the database. Overdue tasks show the due date in red text.

Empty and error states: a first-run screen with one sample task and a hint pointing at the quick-add box. If a write fails, keep the optimistic update visible, show a retry toast, and reconcile on success.

Styling: neutral background, one accent color, generous line height, list rows tall enough for touch.

Done when: I can add, complete, reorder, and delete a task in the webview, refresh the page, and see identical state. Then create a checkpoint and suggest a deployment type.

Same task in other tools

Questions about this prompt

Will Replit Agent ask questions before building the to-do app?

It usually proposes a plan before writing code. This prompt tells it to hold questions until a working version is in the webview, so you review by clicking through instead of answering a quiz up front. If it still pauses at the plan stage, approve it and let the done-when list drive corrections.

How do I adapt this for shared or team lists?

Add a lists table plus a members join table, then scope task queries by list membership instead of user_id alone. Request that change after the single-user version passes, smaller diffs are easier to review and checkpoint.

Tasks vanish after a refresh, what went wrong?

That almost always means tasks lived in React state and the Postgres writes never got wired. Ask the agent to show the SQL or ORM calls behind add and toggle, then rerun the acceptance check: add a task, refresh, confirm it is still there.

Related prompts