TL;DR: Replit Agent prompts are instructions to something that runs commands, so scope is the variable that matters most. This page confirms the current version, teaches Replit's own five-habit prompting structure, explains how checkpoints change what you should write, and gives 21 copy-paste prompts across eight build stages.
Is it still called Replit Agent, and what version ships now?
Yes, and Agent 4. The name has not changed. The version has, twice in a year, and most published Replit prompting advice has not caught up.
Replit's changelog entry for 13 March 2026 is headed "Introducing Replit Agent 4" and opens "Agent 4 is here." The previous generation arrived in the 12 September 2025 entry, which reads "This week, we launched Agent 3." The older announcement page has been retired into the new one: a request to replit.com/agent3 resolves at replit.com/agent4, and the legacy docs path docs.replit.com/replitai/agent redirects to docs.replit.com/features/agent/overview. Everything above was checked on 27 August 2026.
Two surrounding renames catch out older tutorials. Replit's 20 February 2026 changelog says "Fast Mode is now Lite Mode", and the current Agent Modes page carries a flat notice: "Economy Mode is no longer available. Power Mode replaces it at the same price." The modes you see today are Free, Power and Max. If a guide tells you to pick Fast or Economy, it predates both changes and its other details are the same age.
What does a Replit Agent prompt do that a chat prompt does not?
It executes. That is the whole difference, and it is why prompt technique transfers badly from ChatGPT.
Agent writes files, installs packages, starts the app, and can test the result in an actual browser. Replit's App Testing documentation describes Agent navigating your app "just like a real user would, entering mock data when necessary", then reporting back and fixing what broke. If it hits a sign-in wall it offers to hand you the mouse, and "If you do not respond within 10 minutes, the Agent will continue as if you pressed" skip. There is a real shell alongside it. Publishing then provisions cloud resources and routes a domain, with Autoscale, Reserved VM, Static and Scheduled as the deployment types.
An agent that edits files and runs commands can create a mess a chat model cannot. Replit puts two hard walls around that, and both should shape how you prompt. First, background tasks run "in an isolated copy of your project, so your main version stays unchanged while the task runs" — you review and apply, or dismiss. Second, on the production database, Replit's comparison table gives it four words: "Agent can't touch it". The prose is more explicit still: "Agent is not able to modify the production database. This restriction is in place so that your production database stays safe." Schema changes you make in development are applied to production at publish time, not before.
Where does Replit Agent sit next to Lovable, Base44 and v0?
It scaffolds a working core first and postpones infrastructure, which puts it beside Lovable and opposite Base44. That single difference makes advice non-portable.
Replit's beginner walkthrough ends its worked first prompt with "Do not add login, a database, payments, or external integrations yet", and explains that "Those boundaries keep the first build focused." Login, database, payments and integrations each get their own later guide. Lovable does the same thing in its own words, as our Lovable prompt templates cover: its quick-start example prompt closes "No login or database yet", and the page adds that "Keeping your first version free of logins and databases means there is less to go wrong, and you can add both later with a single prompt."
Base44 cannot follow that pattern, because there is nothing to defer. Its own description says the platform "generates UI, backend logic, database schemas, authentication, file storage, and APIs automatically", which is why our Base44 prompt templates spend the opening prompt on the schema instead. Two of the three vendors publish a first prompt that ends by naming what not to build. Copying that habit into the third produces nothing.
| Feature | Replit Agent 4 | Lovable | Base44 |
|---|---|---|---|
| Vendor's own example first prompt names non-goals | Backend is generated automatically | ||
| What the opening prompt is documented to produce | A running app, infrastructure postponed | A working frontend, backend added later | UI, backend, schemas, auth, storage and APIs |
| Where preview work touches live data | Separate development database | Not published in these terms | A branch uses your real, live data |
| Restoring data alongside code | Optional tick box on each rollback | Database backups documented separately | Data version history on Elite and Enterprise |
If your interest is generating interface code rather than a whole application, the shape of the prompt changes again, which is the subject of our v0 prompt templates.
What does Replit's own prompting guidance actually say?
It publishes two real structures, and they are better than most of what ranks for this query. The framework below is Replit's, not ours. Everything in quotation marks was read on the page it is attributed to on 27 August 2026.
The first is a five-habit loop from the Build with Agent page: "be specific, plan the work, add context, review and test, and use checkpoints when you need to recover."
| Replit's habit | What it asks you to put in the prompt |
|---|---|
| Be specific | The goal, the focus area, and the constraints |
| Plan the work | A request to plan first when there are tradeoffs to approve |
| Add context | Files, screenshots, errors, and what should not change |
| Review and test | Success criteria you can check in Preview yourself |
| Use checkpoints | A decision to roll back rather than untangle a bad change |
The line worth memorising sits under the third habit: "Good context also includes what should not change." That is the sentence that prevents runaway builds, and it is the one most people skip.
The second structure is the Effective prompting page, which adds five principles: plan first, build incrementally, be specific, use positive language, and keep it simple. On the fourth, Replit's own example of a bad prompt is "Don't make the user profile page confusing", replaced by a description of the profile page it wants instead. On conversation hygiene it is blunt: "Start a new chat when switching to unrelated tasks. This prevents confusion from accumulated context."
Replit also publishes a five-step loop in its first-app guide that is the practical version of all of the above: describe one useful outcome, add observable success criteria, set boundaries for what not to build yet, test in Preview, then ask for one focused improvement.
How do checkpoints change what you should write?
They let you prompt more boldly and revise less defensively, but only if you know what a rollback restores and what it does not.
A checkpoint, per Replit, "is a complete snapshot of your Replit App state created automatically by Agent at key development milestones." It captures project files, installed packages, the conversation history, environment configuration and Agent memory, which Replit defines as "The AI's understanding of your project architecture, preferences, and patterns." You can move both directions, though "Rolling forward is only possible if you have checkpoints ahead of your current position in the timeline."
The exception is the one that bites. "By default, rollbacks do not change your database." You tick Database in the rollback dialog to include the development database, and restoring the production database is a separate point-in-time operation entirely. So a prompt that seeds records, migrates a table or deletes rows is not covered by the reflex you have built up for code changes. Say so in the prompt, and take a snapshot of the data yourself first.
The task board adds a second asymmetry. Archiving a draft is reversible; cancelling a task that has started building is not. Replit's table is explicit: "Cancelled tasks can't be restored." Review the plan while it is still a draft.
The templates below are ours. Replace every bracket. They assume you are in a project with Agent open, and they are written to be pasted verbatim.
Stage 1: how do you write the first Replit Agent prompt?
With the non-goals attached. Replit's own worked example postpones four things by name, and yours should too.
Build [app name], a [one-line description] for [who uses it].
Visitors should be able to [action 1], [action 2], and [action 3],
using realistic sample data.
Success means: [observable check 1], [observable check 2], and the
layout works on mobile and desktop.
Do not add login, a database, payments, or external integrations yet.
Before making changes, create a plan for [feature].
Include the user flow, the data it needs, the pages or components
that will change, the risks, and how I should test it.
Do not write any code until I approve the plan.
This plan is too broad.
Reduce it to the smallest version I can test today in Preview.
Move everything else into a future improvements list I can come
back to.
Stage 2: how do you prompt the data model without losing the rollback?
Say what persists, say what must never be duplicated, and say that you want a data snapshot first, because the default rollback will not save you.
Move [app]'s data out of memory and into the database so [entity 1]
and [entity 2] survive a refresh, a restart, and a publish.
Attach every [record] to the signed-in user so each person only sees
their own.
Prevent [the impossible state, e.g. the same slot booked twice].
Before you change any schema, tell me exactly which tables and
columns you will add, rename or drop, and wait for my go-ahead.
I am about to ask for a schema change.
First, give me a short script or export I can run to back up the
current development data, and tell me how to restore it.
Then list which of my existing rows would fail the new constraints.
Stage 3: how do you prompt authentication safely?
Set the public boundary and the private boundary in the same message, and ask for a two-account test plan. One account cannot prove separation.
Add sign-in to [app] so each [customer] has their own [records].
Use [Replit Auth / the auth provider you have chosen].
Keep [these pages] public so visitors can still browse without an
account.
Require sign-in before someone can [the gated action].
After sign-in, show the user's name in the header and a [My items]
section containing only their records.
Add a sign-out button.
Give me a test checklist using two different accounts.
Review every route and API endpoint in [app] and tell me, in a table,
which ones require authentication, which check that the record
belongs to the requester, and which do neither.
Do not change any code yet. I want the list first.
Stage 4: how do you change one screen without touching the rest?
Name the element, name the intended effect, and name what stays. Replit's own guidance treats the last of those as part of the context, not as an afterthought.
Update only [the specific screen or component].
Change: [the specific change].
Keep the current [colour palette / form fields / routing / copy]
exactly as they are.
Do not modify [the other area] or any shared component used
elsewhere. If a change requires touching a shared file, stop and
tell me before you do it.
Use this screenshot as layout direction for [the screen].
Match the overall structure and spacing. Keep the existing fields,
labels, and submission behaviour unchanged.
Tell me which parts of the screenshot you are deliberately not
copying, and why.
Before you build this, list the files you intend to create or edit
and one sentence on why each one needs to change.
Wait for my confirmation. If the list has more than [N] files,
propose a smaller first step instead.
Stage 5: how do you prompt an integration?
Say which connector, say what happens when it fails, and insist the core flow survives the failure. That last clause is the one people forget.
After a user completes [the action] in [app], send [the payload] to
[the external service].
Use [Replit's connector for that service] and do not ask me for
OAuth credentials.
Include [these fields] in the payload.
Keep [the action] working even if [the service] is unreachable.
Show a clear message saying the action succeeded but the sync did
not, and log the failure so I can retry it.
Tell me exactly which secret keys I need for [the integration], where
each one comes from, and where in Replit I paste them.
Do not put any key in the code or in a file that ships to the
browser. Confirm in writing which files reference the secrets and how.
Stage 6: what do you prompt when a run fails?
Symptom, location, expectation, and what you already tried. Replit's debugging guidance asks for the exact error message, the relevant snippet, the file, the goal and the steps already attempted, which is a better bug report than most humans file.
When I [exact steps to reproduce] on [page or route], I see [exact
error message, pasted verbatim] in [browser console / server logs].
I expected [expected behaviour].
I already tried [what you tried] and it did not help.
Find the root cause before changing anything. Tell me what it is in
one paragraph, then fix the smallest thing that resolves it.
The last change made [app] worse.
Compare the current version to the previous working checkpoint.
Tell me whether it is safer to fix forward or roll back, and explain
why in three sentences. Do not act until I choose.
Do not add defensive code, try/catch wrappers, or fallbacks to hide
this error.
Show me the failing value and where it comes from. If you cannot
determine the cause from the code, tell me what to log and where.
Stage 7: how do you iterate without regressions?
One improvement per message, with the previous success criteria restated as constraints. Long threads drift, and Replit's own advice is to start a fresh one when they do.
Add [one improvement] to [app].
Keep the existing visual style and do not add [the thing you are
still deferring].
Everything that worked before must still work: [list the two or three
flows you care about]. Tell me how to verify each one after the change.
Starting a fresh thread. Context you need:
[App] is a [description]. The main flow is [step 1] to [step 2] to
[step 3]. It uses [stack or key services].
Rules that still apply: [constraint 1], [constraint 2].
For this thread, only work on [the single area]. Ignore everything else.
Write a replit.md for this project capturing: the stack, the folder
conventions, the naming rules, the things you must never change
without asking, and the flows that must keep working.
Keep it short and specific. I will edit it before you use it.
Stage 8: what do you prompt before you publish?
A security pass and a release checklist, in that order, and separately from the build. Replit's own security tooling exists for this and its own checklist tells you what to ask for.
Run a security review of [app] before I publish.
Check specifically for: secrets reachable from the browser, endpoints
with no authentication, records readable by users who do not own them,
missing input validation, and error messages that leak internals.
Give me findings by severity with the file and line for each. Do not
fix anything yet.
Fix only the [severity] findings from the security review, one at a
time, in separate steps.
After each fix, tell me what changed and how I verify it. Do not
touch anything the review did not flag.
I am publishing [app] for the first time.
List every schema change that will be applied to the production
database at publish, and flag any that could fail against existing
data or cause downtime.
Then give me a rollback plan: what I do if the release is broken.
What does the free tier actually give you?
The free plan is called Starter, it is real, and it is narrower than the marketing summaries suggest. Replit's own Starter page says users "receive daily credits for Agent usage, up to a monthly cap", plus separate monthly credits for databases, object storage and publishing. You get one free published app, and "This published link will automatically go down after 30 days." Your app carries a "Made with Replit" badge.
The constraint that matters for prompting is capability, not credits. Replit lists Full build, Plan Mode, third-party connectors, converting a Design Canvas design into an artifact, and the non-web artifact types as Core-or-Pro features: "Full build requires Core or Pro." On the free plan you are working in the lighter build mode, without the plan-then-approve surface that makes long prompts safe.
Where does Replit Agent stop?
At the point where "it works when I click it" and "it is safe to put in front of strangers" stop being the same sentence. That gap is widest around exactly the three things Replit's own first prompt tells you to defer.
Authentication is the first. An app can render a personalised dashboard perfectly and still return another user's records to a crafted request, because the screen checks who you are and the endpoint does not. Payments are the second, and Replit's own walkthrough makes the boundary visible: it asks Agent to tell you "exactly which secret keys I need to paste from Stripe and where to paste them", which means you are handling live credentials and a webhook you should understand. Personal data is the third, and it carries legal weight rather than merely a bug report.
Replit ships genuine tooling here. Agent security scans combine model-based and static analysis, and produce findings you can send back as fix tasks. But Replit itself sets the ceiling in one line: "A scan is not a complete security review."
The autonomy is its own risk. A chat model that misunderstands you wastes a reply. An agent that misunderstands you edits files, installs packages and runs commands, and the more capable modes are the more autonomous ones. Replit hedges even its strongest scoping tool: "Custom instructions may impact Agent performance. Agent is guided to follow them, but strict requirements aren't guaranteed." Treat every scope constraint as a strong preference that you verify, not a lock. And note the same failure mode we cover in why AI rewrites code you did not ask it to touch: the fix is naming the untouchable surface, in the prompt and in replit.md.
Does a prompt library help with an agent builder?
It helps with the half you are actually reusing.
We build prompts. We do not build apps, we do not run your container, and nothing here generates or deploys software. Replit does that. What repeats across every Replit session is the wording: the non-goals list, the two-account auth test, the "do not touch shared files without asking" clause, the fresh-thread context block. Those are the sentences you retype dozens of times and get slightly wrong under pressure, which is exactly what a saved, variable-driven prompt is for.
If a template above becomes part of your loop, save it with [app], [feature] and [severity] as variables so the next build starts from a filled-in version rather than a blank box. If you are debugging more than building, our 30 AI prompts for debugging go deeper on getting from an error to a root cause.
Stop rewriting prompts. Start shipping.
Works with ChatGPT, Claude, Gemini, Grok, Midjourney, Ideogram, Veo3 & Kling. 5.0★ on the Chrome Web Store.
Create An AccountThe Replit Agent build-stage checklist
- Confirm the version before trusting any guide. Agent 4, checked at
replit.com/agent4. - Put the non-goals in the first prompt. Login, database, payments, integrations, by name.
- Plan first when the work has more than one step, and read the plan while it is a draft.
- State what must not change. Replit's own guidance calls this context, not politeness.
- Give observable success criteria you can check yourself in Preview.
- Remember the rollback excludes the database unless you tick the box.
- Cancel is permanent on a running task. Archive is not, on a draft.
- One improvement per message, with the old criteria restated as constraints.
- Start a fresh thread when the subject changes, and re-state the context block.
- Run the security review before publishing, and read the findings yourself.
Sources and access date
All Replit claims above were read on Replit-owned pages on 27 August 2026: the Agent overview, Agent Modes, Plan Mode, Model selector, App Testing, General Agent, Agent Skills and Agent Customization pages under docs.replit.com/features/agent/; Checkpoints and Rollbacks under /features/version-control/; the task system and task lifecycle pages; Effective prompting and Build with Agent under /learn/; Build your first app, Add login, Add a database, Add payments, Add integrations and Publish your app under /build/; development and production databases under /features/data-and-storage/; Agent security scans and the security checklist; the Starter plan and AI Billing pages under /billing/; and the dated changelog entries for 12 September 2025, 20 February 2026 and 13 March 2026. The comparison table was checked the same day against vendor-owned pages: base44.com/llms.txt and the Base44 branching and data-version-history documentation, and Lovable's own quick start at docs.lovable.dev/introduction/getting-started. No prices or ratings are quoted here, and where Replit's pages disagree with each other both readings are shown rather than resolved.