How to Prompt Replit Agent for Full-Stack Apps (2026): PRD Formula + Examples

Replit Agent (flagship Agent 3, 2026) is an autonomous AI software engineer inside Replit. You describe an app in plain language and it plans, writes code across many files, provisions a database, wires up auth, tests itself in a real browser, and deploys to a live public URL — no local setup, no DevOps. Because you see a running app fast, the winning move is to treat the first generation as a draft and iterate.

The single biggest lever on quality is the prompt. A good Replit Agent prompt is a compact PRD (product requirements document), not a one-liner. This guide gives you the 7-part formula, the Plan → approve → Build workflow, checkpoint discipline, and nine copy-paste example prompts. For a broader library, see the 40 best Replit Agent prompts; for quick reference, the Replit Agent prompt cheat sheet.

The 7-part PRD prompt formula

Every strong build prompt names, briefly, these seven things. You don't need paragraphs — one line each is enough to steer an autonomous run.

1. What to build. A one-line app description. Example: "Build a team task manager web app."

2. Who it's for. The user and their job-to-be-done. Example: "For small remote teams who need to assign work and track status without email threads."

3. Core user flows. The main paths in plain language. Example: "Sign up → create a project → add tasks → assign a teammate → move tasks across a board → see a dashboard."

4. Data model. The main entities and key fields. Example: "Users; Projects(name, owner); Tasks(title, description, status, due date, assignee)."

5. Stack / integrations. Either "you choose the stack" or name it, and call the native primitives when relevant: Replit Auth (login with no config), Replit Database / Neon Postgres (managed Postgres), Secrets (API keys), Deployments (Autoscale, Reserved VM, Static, Scheduled), and Integrations (160+ via OpenInt — Stripe, Twilio, Slack, Google Sheets, SendGrid, OpenAI, and more). Example: "Use Replit Auth for login and Postgres for storage."

6. Design / style. The look and feel. Example: "Clean and modern, brand color #4F46E5, mobile-responsive, light and dark mode."

7. Scope guardrails. Must-haves for THIS pass plus explicit out-of-scope. Example: "This pass: auth, projects, tasks, board view. Out of scope: billing, notifications, mobile app — don't build those yet." This is what keeps an autonomous run from wandering into features you didn't ask for.

Plan Mode → approve the Task Plan → Build Mode

For anything non-trivial, run the prompt in Plan Mode first. Toggle Plan in the prompt composer and the Agent thinks before it builds: it proposes an approach, asks clarifying questions, and produces a Task Plan with "What and Why", "Done looks like", "Out of scope", and numbered build steps — and it waits for your approval before changing any files.

Read that plan. This is where you catch a wrong assumption for free, before a single line of code is written. Fix the scope, answer its questions, then click Start Building to enter Build Mode, where the Agent edits code, runs the app, and tests the flows itself. Skipping Plan Mode on a big build is the most common way to burn effort on the wrong app.

Checkpoint discipline & rollback

Replit Agent creates a checkpoint automatically after each significant change, so your project history is a chain of known-good states. When a prompt makes things worse, don't keep pushing — open History and choose Rollback here to restore the last good checkpoint, then re-scope your prompt.

Treat checkpoints like save points in a game: build one feature, confirm it works, and you have a clean state to return to. Rolling back and re-prompting is almost always faster (and cheaper) than trying to un-break a run that has gone sideways.

Iterate one feature at a time

Don't request every feature at once. Ship the core app, test it, then add the next feature in its own prompt. Small, scoped prompts are easier for the Agent to get right, easier for you to review, and cheaper to run. When you correct something, be specific — name the exact behavior you want and, where you can, attach a screenshot or the error text.

Because Agent 3 has a self-testing browser loop — it opens a real browser, uses the app, and fixes what's visibly broken — you get more from telling it the expected behavior ("after login the user should land on their dashboard") and asking it to test that flow itself.

Adding context: screenshots, errors, Canvas, sample data

The Agent accepts far more than text. Attach screenshots of a UI you want to match or a bug you're seeing, paste the exact error message when something fails, drop in sample data (a CSV) so it builds against realistic records, or use Canvas annotations to mark up the running app and point the Agent at the exact spot to change. A red arrow on a screenshot beats a paragraph describing where the button is.

Rule of thumb: whenever you'd struggle to describe something in words — a layout, an error, a data shape — show it instead. For small, contained edits, remember the Replit Assistant is the lighter tool; use the Agent when the change spans files.

Effort-based cost tips

Billing is effort-based: the Agent charges by how much work a change takes. A simple, tightly scoped change can be under about $0.25; a large build or a messy refactor costs more. Three habits keep spend low:

Scope tightly. One feature per prompt with explicit out-of-scope limits means less work per run and fewer surprises. Use Plan Mode on big changes so you're not paying for a build in the wrong direction. Avoid debugging loops. If the Agent thrashes on the same bug, stop, roll back to a good checkpoint, and re-prompt with the exact error and a request to find the root cause — a loop that keeps "trying again" is the most expensive way to work.

9 example prompts you can copy

Each block is ready to paste into the Replit Agent composer. Fill the [bracketed placeholders], and run the non-trivial ones in Plan Mode first.

1. Complete first-build PRD

Build a full-stack team task manager web app.
Who it's for: small remote teams who assign work and track status without email threads.
Core flows: sign up / log in → create a project → add tasks → assign a teammate → drag tasks across a Kanban board (To Do / Doing / Done) → see a dashboard of open tasks by assignee.
Data model: Users; Projects(name, owner, created_at); Memberships(user, project, role); Tasks(title, description, status, due_date, assignee, project).
Stack: use Replit Auth for login and Postgres for storage. You choose the framework.
Design: clean and modern, brand color #4F46E5, mobile-responsive, light and dark mode.
Scope for this pass: auth, projects, tasks, Kanban board, dashboard. Out of scope (do NOT build yet): billing, email notifications, file uploads, a public API.
Run this in Plan Mode first, propose the Task Plan, and wait for my approval before building. Test the sign-up → create project → add task → assign flow in the browser yourself.

Why it works: It hits all seven PRD parts and fences out four tempting features, so the autonomous run ships exactly the core app instead of guessing.

2. Follow-up "add a feature" prompt

Add a single feature to the existing app: task comments.
Behavior: on a task's detail view, show a comment thread; any project member can post a comment; comments show author name and timestamp, newest at the bottom.
Data model: add Comments(task, author, body, created_at). Don't change existing tables' columns.
Scope: only comments. Do not touch the board, dashboard, or auth. Keep the current design and dark mode.
After building, test posting and viewing a comment as a logged-in member and confirm it persists on refresh.

Best for: Iterating safely — naming the one feature and telling the Agent not to touch the rest protects everything that already works.

3. Plan-Mode prompt (approve before building)

Plan Mode: I want to add role-based access to the task manager — Admins can manage members and delete any task; Members can only edit their own tasks.
Before writing any code, produce a Task Plan: What and Why, Done looks like, Out of scope, and numbered build steps. Call out where you'll enforce permissions (server side, not just UI) and any changes to the Memberships table. Ask me any clarifying questions and WAIT for my approval before editing files.

Why it works: Permissions are exactly the kind of risky change to plan first — you review the enforcement approach before code exists, catching security gaps for free.

4. Debug-with-error prompt

There's a bug. When I click "Assign" on a task, the page shows a 500 error and the assignee doesn't save.
Exact error from the console/logs:
[paste the full error text and stack trace here]
Expected: the task's assignee updates and the board reflects it without a full reload.
Actual: 500 error, no change saved.
Find the root cause before editing anything, explain what was wrong in one or two lines, then make the smallest fix. Add a test for the assign flow so this can't regress. If your fix makes things worse, roll back to the last checkpoint.

Best for: Fast fixes — the exact error, expected-vs-actual, root-cause-first, and a regression test together keep the Agent out of a guess-and-check loop.

5. Deploy prompt

Deploy this app so it's live on a public URL. Use an Autoscale Deployment (it's a standard web app with variable traffic).
Before deploying: make sure all required environment variables are read from Secrets (not hard-coded), the database is the production Postgres instance, and the app builds cleanly.
After deploying, give me the live URL and confirm the sign-up and login flow works on the deployed version. Tell me which Secrets I still need to set, if any.

Why it works: Naming Autoscale (right for web apps) and forcing a Secrets/build check before deploy avoids the classic "works in dev, 500s in prod" surprise.

6. Integration prompt (Secrets)

Add Stripe Checkout so a team can upgrade to a paid plan ($10/user/month).
Use the Stripe integration; store STRIPE_SECRET_KEY and STRIPE_WEBHOOK_SECRET in Secrets — never hard-code keys.
Flow: on a "Billing" page, an Admin clicks Upgrade → Stripe Checkout → on success, mark the team as paid via a webhook.
Done looks like: I can complete a purchase in Stripe TEST mode and the team's plan flips to "paid"; the webhook is verified with the signing secret.
Scope: only the upgrade flow and paid flag. No proration, no invoices UI yet. Ask me for the keys if they aren't set in Secrets.

Best for: Third-party services — naming the service, putting keys in Secrets, and defining "done" as a passing test-mode purchase makes the integration verifiable.

7. "Fix my design" prompt

The dashboard looks cluttered and cramped on mobile. See the attached screenshot [attach screenshot] — I've marked the problem areas with Canvas annotations.
Fixes: increase spacing and use a clear visual hierarchy; make the cards stack in a single column under 640px; ensure tap targets are at least 44px; keep the current #4F46E5 brand color and dark mode.
Don't change any functionality or data — this is design only. After the change, test the dashboard at mobile and desktop widths in the browser and show me the result.

Why it works: A screenshot with Canvas annotations points the Agent at the exact spots, and "design only, no functionality changes" keeps the fix contained.

8. Refactor prompt

Plan Mode: the tasks route file has grown too large and mixes data access, business logic, and HTTP handling. Refactor it into clear layers without changing any behavior.
First produce a Task Plan showing the new structure and which functions move where. The app's behavior and API responses must stay identical.
After I approve: make the change, then run the existing tests and manually test the create / assign / move-status flows to prove nothing broke. Keep it scoped to this file's concerns only — don't touch the database schema or auth.

Best for: Cleanups that shouldn't change behavior — planning the new structure first and verifying flows after prevents a refactor from silently altering the app.

9. Add-tests prompt

Add automated tests for the core flows of this app so future changes are safe.
Cover: sign-up and login, creating a project, adding a task, assigning a task, and moving a task across statuses. Include at least one permission test (a Member cannot delete another user's task).
Set up the test runner if one isn't configured, put tests in a conventional folder, and make sure I can run the whole suite with a single command — tell me that command.
Scope: tests only. Don't change app behavior. Report which flows are now covered and any you couldn't test and why.

Why it works: Listing the exact flows plus a permission case gives you a real safety net, and "tests only, don't change behavior" keeps the Agent from refactoring under the guise of testing.

Ready-made skeletons for all of these — build, feature, plan, debug, deploy, integration, design, refactor, tests — live in the Replit Agent prompt templates. To see full apps built end to end, browse the Replit Agent prompts for web apps collection.