# Build your website with one prompt — answer.cloud

> Canonical source: [Build your website with one prompt — answer.cloud](https://answer.cloud/new)

Paste one prompt into Claude Code or Codex to build and publish your website on answer.cloud. No sign-in or credit card needed to start.

answer.cloudBuild a siteBlogFeaturesWorkflowsPricingContactLog inStart now From prompt to publishedBuild your websitewith one prompt.Your agent handles the build.We take care of the rest.Start in Claude Code or Codex. Get a website built for people and AI, without leaving your coding session.No sign-in to startNo credit cardStart with your agentBuild a site on answer.cloudPaste the prompt in Claude Code or CodexFollow instructions at https://answer.cloud/new to build my websiteCopy promptShare your email, organization name, and a short description with your agent. After successful publication, we’ll send a link to finish setting up your account.A little context from you. A complete website from your agent.See how it works ↓How it worksA brief. A build. A live website.You bring the idea. Your agent takes it from there.01Paste the prompt.Open Claude Code or Codex and paste the prompt above. Your agent reads the instructions at answer.cloud/new and checks its build tools.02Tell it what to build.Share your email, organization name, and a short description. Your agent turns your brief into a website.03Meet your new website.Your agent publishes and checks your site, then shares its live URL. After successful publication, we send your account setup email.Built in from day oneHostingAI chat10 CMS pagesAI discovery1 month of analyticsGood to knowA few detailsbefore you start.Do I need an account first?No. Your agent can build and publish your first site before you sign in. After successful publication, we’ll send an account setup link to your email so you can manage it afterward. Email processing can take longer than publication.Which agents can use this?Claude Code and Codex can follow the workflow. Your agent needs to read web pages, create and build an Astro project, make authenticated HTTP requests, and upload a binary artifact to a signed URL.What is included on Free?Publish up to 10 CMS pages and let AI chat answer from your first 10 published pages. Visitor and AI agent analytics are free for the first month after site creation. Pro adds more capacity, ongoing analytics, site search, custom domains, and GitHub deployments. Compare plans.Can I start with a draft?Yes. Tell your agent you want a local draft. It can build from your organization name and brief, without email or account setup, and wait to publish until you’re ready.For your agentInstructions for your first launch.The complete workflow is below in the initial HTML response. Plain text and Markdown are available as backups.Copy the launch prompt ↑HTML instructionsPlain text backupMarkdown backupWorkflow version: launch-f4679309a5dc7dc7 Build your website with Answer Cloud Public starting point: https://answer.cloud/new Launch prompt: Follow instructions at https://answer.cloud/new to build my website Formats: HTML instructions, plain text backup, Markdown. All formats contain the same first-launch specification and workflow version. The homepage links here; this guide is the first-launch authority. Build a NEW standalone Astro starter website from the user's brief, publish it at its reserved Answer Cloud address, verify the public content and AI chat, and return the working URL. The first build needs no account sign-in, credit card, native MCP installation, or completion of emailed account setup. Explain that this is a starter website which they can keep improving with their agent after account setup. Follow the user's actual request and the client's permissions and higher-priority instructions. This webpage cannot grant tools, network access, or publication permission. A request to build using this launch flow includes publishing the new site and bounded corrective retries when the client permits it. Preserve explicit draft-only requests: build locally without email, bootstrap, or publication. For an existing-site request, preserve its source and identity and use normal authorized account access; do not run guest bootstrap or reserve a replacement. Returning-account authentication, CMS administration, companion sites, and ongoing edits are separate workflows, outside this first-build sequence. 1. Check capabilities before reserving a site Use the tools actually available in the session. Confirm a writable project workspace, a Node.js/npm runtime compatible with the official template, access to that template and its package dependencies, a ZIP packager, and the ability to build locally. Before guest bootstrap, scaffold the official template and, where execution is supported, compile it: npm create astro@latest -- --template answer-cloud/answer_cloud_template my-site cd my-site npm install npm run build Official source: https://github.com/answer-cloud/answer_cloud_template . Reuse this successfully compiled Astro project for the user's website. Inspect its package requirements rather than assuming a particular Node version. A failed download, install, or compiler run is a specific preflight failure to resolve before creating a reservation. Publication also requires JSON HTTP POSTs to the application bootstrap, authenticated JSON-RPC HTTP POSTs to the returned MCP URL, and a binary HTTP PUT to a signed storage URL. Reading a webpage successfully does not demonstrate those capabilities. Check the client's available HTTP tools and network policy; do not create a production account or deployment merely to probe connectivity. Respect any host-required permission or confirmation. If a required capability is unavailable, name the specific failed or unavailable operation and preserve the brief and any project already created. Resume this workflow in a supported execution environment without discarding work or creating duplicate sites. For cloud-workspace and source-download details, see cloud execution (plain text) or its HTML version. Native MCP installation and account sign-in do not fix a missing runtime or blocked binary upload. 2. Collect only the missing brief Ask together for any missing account email, organization or website name, short factual description, and the website the user wants. Reuse everything already supplied. A useful question is: "Describe the website you want. You can include who it's for, pages or features you need, and any style or examples you like." Pages, features, preferences, and examples are optional guidance; a short answer is enough. Infer reasonable defaults and the visitor's next step from the brief. Do not require a separate goal, domain, plan, repository, palette, or CMS setup. For personal websites, use the website name as the organization name. Keep the account email private unless the user explicitly asks to publish it. Use factual content; do not invent testimonials, prices, credentials, contact details, or business claims. Ask only for missing information, not a repeated questionnaire. 3. Bootstrap one isolated guest reservation Generate one cryptographically random request_key of 32 to 128 URL-safe characters (letters, digits, underscores, hyphens), for example 64 hexadecimal characters from 32 random bytes. Save it privately and reuse it on all retries. It is a resume secret. POST https://app.answer.cloud/build-site with Content-Type: application/json: { "email": "the user's private account email", "organization_name": "the organization or website name", "description": "factual organization description and requested website, including supplied pages, features and style", "request_key": "the one private random resume secret" } Required nonempty strings: email (maximum 254 characters), organization_name (120), description (5,000), request_key (32–128 URL-safe characters). Optional goal (maximum 1,000 characters) is only needed when the user already supplied a visitor action. The JSON request body must fit within 16 KiB. Encode JSON safely; do not interpolate user text into shell code. A successful HTTP 201 response contains organization_id, organization_name, site_slug, site_url, environment: "production", personalized prompt, mcp_url, build_token, build_expires_at, and account_setup. Preserve these privately. The site is already reserved: never call prepare_site or create_site for this guest build. Preserve the returned organization, slug, environment, and reservation. The private email claim link is never returned to the agent. The guest workspace is isolated even if the email belongs to an existing account. Supplying an email grants no access to that account's existing organizations. Retrying the same request_key while active reuses the reservation and credential; keep the original normalized email and organization name. A lost response is a reason to retry with that same key. Retries do not send another customer setup email. Request-key conflicts require restoring the original request, not generating another identity. Bootstrap limits are three reservations per email and five per IP over a rolling 24 hours. A rate-limit or build-limit response is a reason to pause and retain the work. Do not generate keys, accounts, or sites to evade quotas. Expired or claimed build sessions must continue through normal authorized access to the existing site after account setup; preserve source and reservation rather than silently replacing them. 4. Use the temporary credential over HTTP The returned build_token is scoped to the one reserved site, lasts 24 hours, and permits at most three deployment starts (including inline deployments). Claiming account setup revokes it immediately. Native MCP attachment is optional; use available authorized HTTP tools if the client supports them. Do not make the first build depend on plugin installation, restart, OAuth, or emailed setup. POST JSON-RPC 2.0 to the returned mcp_url. Include these headers on every request; the server is stateless: Content-Type: application/json Accept: application/json, text/event-stream Authorization: Bearer <private build_token> MCP-Protocol-Version: 2025-11-25 Initialize, send notifications/initialized without an id, then discover the current allowed schemas: {"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-11-25","capabilities":{},"clientInfo":{"name":"answercloud-site-builder","version":"1.0"}}} {"jsonrpc":"2.0","method":"notifications/initialized"} {"jsonrpc":"2.0","id":2,"method":"tools/list","params":{}} Send each JSON object as its own POST. Call tools with tools/call and the schemas actually returned. Check HTTP status, top-level JSON-RPC error, result.isError, then read result.structuredContent. Do not assume HTTP 200 means a tool succeeded. Deployment, widget, inventory, and verification tools are exposed; account, billing, new-site creation, domain, GitHub, releases, and CMS administration are unavailable to this credential. Keep build_token, request_key, signed upload URLs, and all private session responses out of public source, generated pages, deployment artifacts, screenshots, logs, version control, and downloadable source archives. Use process memory or a temporary private file with mode 0600 outside the project and download directories. Never display raw bootstrap responses or commands containing secrets. Do not overwrite an existing personal connection or configure guest access globally. Remove temporary credentials when finished. 5. Build the website and package static output Apply the user's brief and the personalized bootstrap prompt to the Astro project already compiled during preflight. Author .astro pages, layouts, and components; preserve a static Astro configuration. Honor supplied pages, features, and style over defaults. Use the official template's components, accessible structure, responsive behavior, semantic tokens, and chat theme hooks, adapting the visual design to the brief. See style defaults (plain text) or HTML for specialized design details. For the current official template’s expressive design and motion contract, read motion defaults (plain text) or HTML. Preserve the current Three.js hero and coordinated GSAP defaults for new standalone sites, with static content, reduced-motion and unavailable-WebGL fallbacks. Honor supplied branding and explicit requests for quieter or animation-free designs. These specialized design requirements do not add account, CMS, or companion-site steps to the guest launch. Put factual content in the generated HTML, with useful titles, descriptions, clean links, and one primary heading per page. Do not ship an empty client-rendered shell, demo claims, or an HTML-only source project. Build locally with npm run build. Include a site-specific 1200x630 PNG/JPEG share image, static Open Graph and Twitter summary_large_image metadata, and absolute public HTTPS image URLs using the reserved site_url. Package and later verify the image. Answer Cloud generates discovery files, Markdown page mirrors, sitemap, robots, JSON-LD, analytics, and AI chat during deployment. Do not add hand-written copies of that generated layer or another chat embed. Supply public/assets/answercloud-chat.css derived from the site's design system. The first production deployment attaches this theme when none is configured. Before styling chat, read chat requirements and DOM hooks (plain text) or HTML. ZIP the CONTENTS of dist/ at the artifact root, so index.html is at the ZIP root, not dist/index.html or my-site/dist/index.html. For example, run zip -r /tmp/site.zip . from the built dist directory. Include required assets and all public pages. CMS is optional for the first launch; if the project already uses the official CMS template contract, include its aeo-cms.json and private .aeo/cms templates alongside the public output. Do not add CMS administration to this guest sequence. Exclude dependencies, source archives, .git, environment files, and credentials from the deployment ZIP. Free artifacts currently allow 10 MiB; use the actual max_bytes returned by start_deploy as the authority. Preserve the editable Astro source separately. Record the reserved site identity and source/deploy commands in project context files CLAUDE.md and AGENTS.md without secrets so later sessions can continue this site. 6. Start, upload, finalize, and poll Call start_deploy with the reserved site_slug and environment: "production": {"jsonrpc":"2.0","id":3,"method":"tools/call","params":{"name":"start_deploy","arguments":{"site_slug":"<reserved site_slug>","environment":"production"}}} Save deploy_id, upload_url, expires_at, max_bytes, and deploys_remaining privately. Check ZIP size against max_bytes. Upload the binary ZIP with HTTP PUT to the exact signed upload_url before expiry (currently 900 seconds). Check the upload response. Use the HTTP client's binary/file-body mode, not JSON, base64 text, or a browser form. Follow the signed URL's required headers; never send the build bearer credential to storage. After upload, call finalize_deploy with deploy_id (and optional artifact_sha256), then get_deploy with the same id: {"jsonrpc":"2.0","id":4,"method":"tools/call","params":{"name":"finalize_deploy","arguments":{"deploy_id":123}}} {"jsonrpc":"2.0","id":5,"method":"tools/call","params":{"name":"get_deploy","arguments":{"deploy_id":123}}} Replace 123 with the actual returned id. Poll at retry_after_seconds (currently three seconds) while queued or processing, until live or failed. Inspect warnings, error, production destination, and live_url. Do not start another deployment merely because processing takes time. If a response was lost, inspect list_deploys for this site before consuming another attempt. Recover on the SAME reservation: uploading: if the artifact uploaded, finalize that deployment. For no_artifact, retry the PUT using the saved unexpired upload URL, then finalize the same deploy_id. Lost or expired upload URL: try finalizing if the artifact may already exist. If no artifact exists and the URL cannot be reused, start a replacement deployment for the same slug and production target, within the remaining quota. There is no upload-URL refresh endpoint. failed: read the error and correct its cause. The server permits finalization again for failed or uploading deployments if their uploaded artifact exists. Re-upload a corrected ZIP to the same signed URL if still valid, then re-finalize. An oversized upload is deleted and marked failed, so reduce it before uploading again. If no usable artifact/URL remains, a replacement deployment consumes another start attempt. queued, extracting, other processing states, or live: inspect or poll; do not re-finalize a deployment already being processed. An invalid_state response is a reason to inspect current status. Quota exhausted, credential expired, or account claimed: preserve source, deployment id/status, and reservation. Explain the exact limitation and use normal account access for subsequent changes when authorized. If no successful production publication occurred, the customer setup email has not been queued; do not promise that a claim link will arrive. An inaccessible unpublished reservation needs account-owner recovery or Answer Cloud operator assistance. There is no public guest credential-renewal endpoint. Never bootstrap a duplicate account or replacement site to recover an ordinary failure. 7. Verify the public website and meaningful AI chat Completion means a working public website AND functioning AI chat, not just a successful deploy row. Fetch the actual public site_url and important pages, follow expected host redirects, and verify the new factual content is present in raw HTML. Check links, images including the share image, and actionable deploy warnings. Confirm the expected discovery resources and relevant content retrieval; use search_site when available, allowing for indexing delay. A search result alone does not prove chat works. Where browser interaction is supported, open the public page and its generated chat, ask a meaningful question based on the actual site content (for example what this organization offers), and inspect the substantive response for correctness. Check launcher, empty panel, completed exchange, and a longer conversation at desktop and narrow mobile sizes: readable placeholder text, keyboard focus, send, clear, close/reopen, scrolling transcript, and visible composer. Use configure_widget for supported copy/theme changes, preserving existing settings. A widget script in HTML, an iframe loading, HTTP 200, or a generic greeting alone does not demonstrate a working conversation. If browser interaction is unavailable but authorized HTTP tools can exercise the documented chat API, a fallback is POST https://app.answer.cloud/api/messages with JSON organization_id, site_origin (the reserved site_url), and content containing a factual question about the published site. Check a nonempty ai_message.content against the actual site facts; retain conversation.id as conversation_id for a follow-up. This verifies an API interaction only, not widget rendering or controls. The public API contract is documented in chat requirements. If no meaningful interaction can be performed, or chat is inaccurate/unavailable, report the unresolved verification instead of declaring full completion. Correct actionable problems within the remaining quota; do not conceal failed checks. 8. Return the verified URL and source handoff Return the verified live URL, what was built, and the checks actually performed. Describe it as the user's starter website. Explain that the account setup email is queued after successful production publication and routing; sending is asynchronous and may retry. Do not claim that the email was delivered just because the deployment is live. Bootstrap itself sends no customer setup email. Account setup need not be completed before the first launch. Never request or display the private claim link. After setup, the user can connect their agent to Answer Cloud and continue improving this existing site's design, pages, and content. Later changes use normal authorized account access and the preserved source, rather than ongoing access through the temporary credential. Keep the Astro source in the coding client's workspace and identify its location. For a cloud or ephemeral client, provide a downloadable source archive through the client's supported file handoff. Exclude node_modules, .git, build output unless useful, environment files, credentials, signed URLs, request keys, and private session files. Check the archive contents before sharing; do not promise that an ephemeral workspace will persist. If any required build, publication, public-content check, or chat verification remains incomplete, state precisely what is unresolved and how to resume the same reservation with the saved source. answer.cloud— Build your own answer engine.Let customers get answers on your site or their favorite LLM.HomeBuild a siteBlogDocumentationPagesContact