Start here

1. project_read list to see the user's projects, or project create (name, template) to start one. Templates are starting stacks, not apps: nextjs-app (Next.js 16, React 19, TypeScript, Tailwind CSS 4, PostgreSQL), python-fastapi (FastAPI, uvicorn, psycopg), static-site (HTML and CSS) and blank (a database and nothing else). Another stack (SvelteKit, Astro, Remix, Django, Rails, Laravel, Phoenix, Go, Rust, .NET, Spring…): start from blank, pin the toolchain in .tool-versions (mise installs any language: go 1.27, ruby 3.4, java temurin-21…; PHP 8.5 with Composer is already installed; Erlang compiles on first use, several minutes on a paid plan, and another PHP version longer: run mise install with exec background: true and follow it with job), use the framework's own generator and commands, and point services.json at them (dev, build, start, the port from $PORT, a migrate command if the framework has one), and rewrite Dockerfile and compose.yml for the stack: never just delete them, they are how the code runs outside LazyFrog (preflight warns without a Dockerfile). Existing code: project import from its repository; a prototype made in the chat (a Claude artifact, a ChatGPT preview or Site): see "Make it real: from a chat prototype to a project".
2. Read README-for-AI.md in the project (fs_read, path workspace/README-for-AI.md) for the template's specifics.
3. Build with fs_write / fs_edit, run things with exec, check with http_get and preview_screenshot, and read logs_tail when something fails.
4. Whenever you install or set up an app the owner will use (CMS, shop, dashboard, admin tool), call project about with where to sign in or manage it (the admin or login address), what it is and its version, where its data lives, how to update it and what the owner must do next; credentials go in secrets, never here (write "Admin password: stored as secret WP_ADMIN_PASSWORD, change it on first login"); keep it current when anything changes. The owner sees it at the top of the project's page, and project_read get shows it to the next session. Put the site's conventions in its facts too: the currency prices are in, the languages, the time zone, who the visitors are, so the next session keeps them.

Every tool takes project (slug or id). The workspace wakes automatically (about a second) when a tool needs it and sleeps after 15 idle minutes; files, databases and logs are kept.

On Free there is a preview and no live site. Build it, check it with preview_screenshot, and show the user the preview's own address (project_read get: https://p-….lazyfrog.app). Anyone with that link can open it while the month's preview hours last (40 on Free; past them it still wakes for your tool calls, not for visitors); it sleeps after 15 quiet minutes, search engines don't list it, and it carries the small "Built with LazyFrog" badge. Going live (a publish, the site at https://<slug>.lazyfrog.app or the user's own domain) needs a paid plan: when the user asks to publish, or wants an address to give out, say so plainly once, in their words ("Going live needs a paid plan. Your preview stays free: share its address while it's awake. Upgrade to put it at <slug>.lazyfrog.app or your own domain.") and give the plans page, https://app.lazyfrog.dev/upgrade (the upgrade_url of the refusal). Don't keep raising it, and never present the preview as the finished, public site. account get says the plan; a publish on Free is refused with plan_limit and limit: "live_sites". A Free project nobody works on for 14 days (their own actions: your work for them, the portal, signing in; visits to the preview don't count) is archived after two emails, and can be brought back.