Skip to main content
Connect Replo to Cursor, Claude Code, or your coding client, then ask it to open your site locally. Use your own AI plan to make edits and see them in a live preview. Your coding client commits and pushes after each completed editing turn, keeping the Replo draft in sync. Publish separately when you want the changes live.

​
Start here

Connect the Replo MCP server, open a local workspace, and paste this prompt with your project name:
The setup checklist for coding clients and Git authentication reference below cover the steps your client needs to complete this request. Your client handles the clone and setup. You need Git, Node.js, and pnpm on your computer. If it cannot open a browser, open the local URL it gives you.

​
Try an edit

Once the preview is running, ask for a change. For example:
Check the result in the browser, then keep refining in the same chat. Local coding uses your coding client’s plan; work requested inside Replo uses applicable Replo credits.

​
Keep Replo in sync

At the end of each editing turn, your coding client checks the changes, commits them, and pushes them to Replo before reporting completion. This keeps the site draft up to date as you work. If a check or push fails, the client should report the failure and resolve it before calling the turn complete. Review the draft in Replo whenever you need to. Publishing is a separate action that makes the changes live.

​
Setup checklist for coding clients

When a user gives you this page to set up a site, complete these steps. The Git authentication reference contains the credential setup and commands; read it before cloning.
  1. Find the site repository. If the user supplied a site ID, set REPLO_GIT_URL to https://git.replo.app/<site-id>.git. This needs no Replo MCP server or dashboard access. Otherwise, use the connected Replo MCP server’s list_projects, then list_sites, and use the site’s returned clone_url. Follow pagination and ask the user to choose if names are ambiguous.
  2. Set up clone and push access. This workflow pushes every completed editing turn, so it requires both repo.read and repo.write. If REPLO_API_KEY is already supplied, confirm it has both scopes and is exported to child processes without printing it. Otherwise, call create_api_key with the resolved workspace and project IDs and both scopes. Store a newly returned key securely; never print it in chat, put it in the clone URL, or commit it. Follow the authentication reference to configure Git.
  3. Clone into a new folder. Verify access with git ls-remote, then clone the returned URL. Run subsequent commands from that checkout. If it already exists, inspect its remote and local changes before using it; preserve existing work.
  4. Verify the skills in this checkout. Follow the skills installation guide. Check which official Replo skills this client can find and read from the cloned workspace. Install missing skills from replohq/skills for this client, preserving existing instructions. Confirm discovery after installation; do not treat an installer exit message alone as proof that the client can read them.
  5. Install and start. Read the checkout’s instructions, package.json, package-manager configuration, and lockfile. Use their required Node.js and package-manager versions. If the checkout does not declare versions, use the supported Node.js 22 and pnpm 10 fallback in local SDK setup. Install dependencies and start the declared development script. Most Replo sites use pnpm install and pnpm dev. Keep credentials and machine-specific configuration out of commits.
  6. Verify the preview. Check the actual URL reported by the server and load the requested page. Confirm it renders the site, then open it in the user’s browser. A rendered route does not by itself prove that product data loaded successfully. When product data is expected, verify it against active products and confirm the expected data appears; an empty fixture or one with only inactive products leaves product loading unproven. If browser access is unavailable, provide the exact local URL. Keep the server running. Report a failed clone, install, skills check, or preview instead of claiming setup is complete; use Git troubleshooting for recovery.
At the end of every editing turn, fetch and reconcile newer Replo changes without discarding local work, run the site’s checks, and commit and push that turn’s intended changes. Never force-push. Verify the push succeeded before reporting the turn complete. If a check or push fails, report and resolve the failure rather than claiming the Replo draft is updated. Publish only when requested. Need help? Troubleshoot Git.