Replit Agent Prompt Templates (2026): Fill-in-the-Blank

Build [one-line app description].

Who it's for: [target user] who needs to [job-to-be-done].

Core user flows:
- [flow 1, e.g. sign up -> create a project]
- [flow 2, e.g. invite a teammate]
- [flow 3, e.g. see a dashboard]

Data model:
- [Entity 1] ([field, field, field])
- [Entity 2] ([field, field, field])

Stack & integrations: [you choose the stack OR name it]. Use Replit Auth for login and Postgres for data. [Add any integration, e.g. Stripe via Secrets].

Design: [clean/modern], brand color [#hex], mobile-responsive[, dark mode].

Scope for THIS pass: build [must-haves]. Out of scope for now: [don't build X yet].

Run this in Plan Mode first, propose a plan, and wait for my approval before changing any files.

Plan Mode only — do not write or change any code yet.

I want to [goal, e.g. add multi-tenant workspaces to my app]. Before building, produce a Task Plan with: What and Why, "Done looks like", Out of scope, and numbered build steps. Ask me any clarifying questions about [ambiguous area, e.g. how billing maps to workspaces] first. Wait for my approval on the plan before you start building.

Add ONE feature to the existing app: [feature name].

What it does: [plain-language description].
User flow: [where the user starts -> what they do -> what they see].
Data changes: [new fields/entities, or "none"].
UI: [where it lives in the app, e.g. a new tab in the sidebar].

Done looks like: [observable result, e.g. "a user can archive a task and it disappears from the active list"]. Don't touch [unrelated area]. When finished, test this flow yourself in the browser and confirm it works.

Set up the data model in Postgres for [app].

Entities and key fields:
- [Entity] ([field: type], [field: type], created_at)
- [Entity] ([field: type], [field: type], created_at)

Relationships: [e.g. a Project has many Tasks; a Task belongs to one User].

Add sensible indexes for [common query, e.g. "listing tasks by project and status"]. Seed [N] rows of realistic sample data so I can see the UI populated. Don't build any UI in this pass — schema, migrations, and seed data only.

Add authentication using Replit Auth.

Requirements: users can [sign up / log in / log out]; protect these pages/routes: [list]; on first login create a matching user record in the database with [fields, e.g. email, name, created_at]. Redirect logged-out users hitting a protected route to the login page.

Done looks like: I can log in, only I see my own [data], and logging out blocks access. Test the full login -> protected page -> logout flow yourself in the browser.

Integrate [service, e.g. SendGrid / Twilio / OpenAI / Slack] into the app.

Use case: [what it does, e.g. "send a welcome email when a user signs up"]. Store the API key in Secrets as [SECRET_NAME] — do not hardcode it. Handle failures gracefully (retry or log, don't crash the request).

Done looks like: [observable result, e.g. "a test email arrives at my address"]. Tell me exactly which Secret(s) to add and where to get the key, then test the integration end to end.

Add Stripe payments to the app.

What to sell: [one-time purchase OR subscription] for [product/plan] at [price]. Flow: user clicks [Buy / Upgrade] -> Stripe Checkout -> on success, mark [what changes, e.g. "the user's account as Pro"]. Handle the webhook for [checkout.session.completed] to update the database reliably.

Keys go in Secrets (STRIPE_SECRET_KEY, STRIPE_WEBHOOK_SECRET). Use Stripe test mode. Done looks like: I complete a test-mode checkout and my account flips to [Pro]. Test the full flow yourself, including the webhook.

Add role-based access control on top of Replit Auth.

Roles: [Admin], [Member], [Viewer]. Permissions:
- [Admin] can [do X, Y, Z]
- [Member] can [do X, Y]
- [Viewer] can [read only]

Store the role on the user record; default new users to [role]. Hide UI actions a role can't use AND enforce the rules on the server so they can't be bypassed. Done looks like: a [Viewer] account cannot [restricted action] via UI or direct request. Test each role yourself.

Add a CSV import feature for [entity, e.g. contacts].

Flow: user uploads a .csv -> the app previews the parsed rows and maps columns to [target fields] -> user confirms -> rows are inserted. Expected columns: [col1, col2, col3]. Validate each row (required fields, email format, etc.), skip or flag bad rows instead of failing the whole import, and show a summary: [N imported, N skipped, with reasons].

Done looks like: I upload a sample file and see the right records created with a clear import report. Test it with a messy sample file that has a few bad rows.

Build a dashboard for [user/purpose].

Metrics to show: [metric 1], [metric 2], [metric 3] — each with its current value and [trend / comparison to prior period]. Include [charts you want, e.g. a line chart of X over time] and a filterable table of [records] with filters for [dimension 1, dimension 2].

Pull all numbers from the real data in the database — do not invent figures. Keep it mobile-responsive. Done looks like: the dashboard loads with real data and the filters update the charts and table. Test the filters yourself.

Add a REST API endpoint: [METHOD] [/path, e.g. GET /api/tasks].

Purpose: [what it returns or does]. Input: [query params / body fields with types]. Output: [JSON shape, e.g. {"tasks": [{id, title, status}]}]. Auth: [require a logged-in user / API key in Secrets / public]. Validate input and return proper status codes (400 for bad input, 401 unauthorized, 404 not found).

Done looks like: calling it with [example request] returns [example response]. Add one example request I can copy, and test the endpoint yourself.

Build a one-page marketing landing page for [product].

Sections in order: hero (headline + subhead + CTA button), 3-feature row, [social proof / logos], a short FAQ ([5] questions), and a footer with an email signup form. Style: [clean/modern], brand color [#hex], [sans-serif], mobile-responsive. Copy: [paste it OR say "write persuasive copy from this description: ..."].

Make the primary CTA prominent above the fold and use a placeholder for [LOGO] and the [FORM ENDPOINT]. Done looks like: a polished, responsive page I can preview. Test it at phone and desktop widths.

Make the app fully mobile-responsive without changing any functionality or data.

Focus on: [pages/components that break, e.g. the dashboard tables and the nav]. On small screens: [expected behavior, e.g. "the sidebar collapses into a hamburger menu; tables scroll horizontally or become stacked cards"]. Keep tap targets large enough and text readable without zoom.

Only touch layout/styling — don't change logic. Open the running app at a phone width, find what overflows or overlaps, fix it, and re-check yourself.

Fix the design of [page/component]. Here's what's wrong: [specific issues, e.g. "spacing is inconsistent, the buttons look default, contrast is poor"]. [Attach a screenshot and use Canvas to mark the exact spots.]

Target look: [clean/modern], brand color [#hex], consistent spacing and typography, clear button hierarchy. Don't change any functionality or copy — visual polish only. Show me the before/after by testing the page yourself in the browser.

There's a bug. Find the root cause before changing anything.

What happens: [actual behavior]. What should happen: [expected behavior]. Steps to reproduce: [1, 2, 3]. Error message:
[paste the FULL error / stack trace here]
Likely file(s): [if known].

Explain the root cause first, then make the smallest fix that resolves it. Don't refactor unrelated code. After fixing, reproduce the steps yourself to confirm it's gone, and add a quick test so it can't regress.

Refactor [file / module, e.g. the checkout logic] to [goal, e.g. "split it into smaller functions and remove duplication"].

Hard rule: behavior must stay exactly the same — this is a pure refactor, no feature changes. Keep the public interface [/routes/props] identical. Do it in [small steps / one file at a time] so it's easy to review.

Run this in Plan Mode first and show me the plan. After refactoring, run the app and confirm the affected flows still work. If anything behaves differently, stop and tell me.

Add automated tests for [feature/module, e.g. the task API and the auth flow].

Cover: [key cases — happy path, invalid input, unauthorized access, edge case]. Use [the project's existing test setup, or pick a standard framework and set it up]. Don't change the app's behavior — only add tests; if a test reveals a real bug, tell me instead of silently fixing it.

Done looks like: I can run the tests with one command and they pass. Run them yourself and paste the results.

Deploy the app.

Deployment type: [Autoscale for a web app / Reserved VM for an always-on service / Static for a static site / Scheduled for a cron job]. Make sure all required Secrets are set for production ([list them]). Run any needed database migrations against the production database. Confirm the build succeeds.

Done looks like: a live public URL that loads the app and passes a quick smoke test of [key flow]. Tell me the URL and walk me through the smoke test yourself.

Create a scheduled job that runs [cadence, e.g. every day at 8am UTC].

Each run should: [task, e.g. "fetch new rows from [source], summarize them, and email me a digest"]. Use Secrets for any API keys ([SECRET_NAME]). Log each run's outcome (success/failure + counts) so I can see history. Make it idempotent — if it runs twice, don't duplicate work.

Deploy this as a Scheduled Deployment (cron). Done looks like: a test run produces [expected output] and the schedule is registered. Trigger one run now to prove it works.

The last change broke [what's broken] — it was working before. Stop making new changes.

First, help me roll back to the last good checkpoint before this feature (in History, "Rollback here"). After we're back to the working state, in Plan Mode only, propose a smaller, safer plan to achieve [original goal] that avoids [what went wrong]. Wait for my approval before building anything.