Build an app from a chat #

View this page as Markdown

Prompt:

Build a simple AI chat web app where I sign in with an account and ask questions. Use the Free plan. Read https://turnzero.ai/cloud/getting-started/build-an-app-from-a-chat/index.md in full and follow the steps. Deploy it and give me its link.

What your AI tool does #

• Designs and builds the app you describe, using an example app if one helps.
• Checks your plan, configures the services, and deploys the app.
• Tests what its tools can verify and gives you the link, with any checks left for you.

No terminal, ZIP file, or folder on your computer is needed. An AI chat app can use the plan's included AI allowance without a separate provider key.

What you need #

• A signed-in Turn Zero Cloud connection in your chat.
• Room for a new application on the plan you choose. Your AI checks the account's current limits before creating it.

With a usable shell, your AI can use turnzero scaffold to start from a template, install dependencies, and run tests. The MCP connection and CLI have separate credentials; follow Authorize this computer for deploys before using the CLI.

Before your AI starts #

For the AI tool: The checks and procedures below address you directly. When a step needs the person, tell them what to do and wait for their response.

Build the app the person requested. You may browse the example apps, choose a useful starting point, and adapt it, or write the app yourself. A template's features are examples, not requirements for the person's app.

Read the deploy skill through read_context, plus the skills for the services you need, such as add-sign-in and use-ai-allowance. Keep their approval and retry rules. With no usable shell, use the MCP steps below in place of instructions to scaffold, run local commands, or deploy through the CLI. Do not ask the person to create a local folder or install the CLI for this route.

Steps #

1. Design and write the app #

Use the person's prompt to decide what to build. If you use an example, read its complete source before adapting it. The example catalog lists the available templates; none is required.

If a web fetch fails or returns a summary, use read_documentation with tree: "cloud" and the page's path, such as /examples/overview. Follow each response's next_offset and stamp until you have the whole page. Example pages include all their files inline and link to text downloads. The downloads' .txt suffix is not part of an application's filename.

For sign-in, use the platform's sign-in pages and verify sessions through the Account package. Use the AI Allowance package for questions answered from the plan's allowance. Add a database or other services when the app needs them. Keep each user's saved data private to that user.

2. Create the application #

Call list_applications and read_plan_quotas. Use the plan the person named; the prompt above selects Free. If the response includes application_limit_exemption, the account is exempt from per-account application limits. Otherwise, compare its applications with the returned application_limit. Ask how to proceed only if the chosen plan has no room. Do not delete an application or change plans without approval.

Call create_application with the chosen plan and keep the returned identifier. A new application has production only; a development environment is optional.

3. Declare the services and libraries #

Submit a manifest for the services, health path, region, audience, and external hosts the app needs. Read each required library entry with read_library_entry and put its current name and version in the manifest's packages list. Use the library name, such as account, not the dependency name @turnzero/account. Copy the version returned by the read, not one from an old example.

In package.json, declare these packages as local library dependencies, such as "@turnzero/account": "file:lib/account". Keep the app's other dependencies too. Omit the library folders from deploy_files: Cloud fills them from the entries listed in the submitted manifest. You do not need to download those copies first.

Call submit_manifest with the application's identifier and completed manifest. A manifest.json file in the upload is optional; deployment uses the submitted manifest. If you keep that file, keep it consistent with what you submitted. No local credential file or local_run request is needed for this route.

New end-user realms default to Google, GitHub, emailed codes, and passkeys, with open sign-up. Use read_realm to check the effective settings, including any audience restrictions, and configure the methods and access the app needs.

4. Check and deploy the files #

Review the complete file set. With no usable shell, do not claim to have run Node.js tests or started the app locally. Keep useful tests from any example you adapt, updating them to match your app.

Call check_deploy for configuration checks, then call deploy_files with check_only: true and the app's complete file list. Each entry gives its application-relative path and full text as content, with package.json at the root. Do not send credentials, node_modules, or the library folders Cloud fills.

The file check retains accepted content and returns kept, with each file's path and computed sha256. Resolve any refusals. Once it returns files_checked, call deploy_files again without check_only, listing every file by those returned paths and hashes. Do not calculate hashes yourself or resend unchanged content. These checks cover deployment requirements and source syntax, not the app's runtime behavior.

The limits are 200 listed files, 512 KiB per file, and 4 MiB total including the library copies Cloud fills. The JSON request has its own size limit. If the content will not fit in one call, send files first using file, then list them by their returned hashes; see the deploy_files reference. Never truncate a file to fit.

Follow the returned read_status call until deployment ends; a build can take several calls. Check filled for the library copies. If a response does not establish whether deployment started, read status before retrying.

5. Verify the app #

Use request_route to check the health path and home page. Check that a route requiring sign-in refuses a request without a session. A healthy app is not proof that sign-in or AI answers work.

If you can operate a browser or send HTTP requests while preserving cookies, follow Test sign-in with test end users. On an application with production only, your signed-in MCP session can create temporary test users and read their codes without the separate approval required by the CLI-token route. If development exists, test there. Do not substitute sign_in_test_end_user's CLI command when you have no shell.

Test the signed-in behavior the person requested, including an AI answer for the demo. Ask before writing test data to production. Remove temporary test users and any test data you created, and discard their cookies. Deleting a test user does not delete the app's saved data automatically.

If your available tools cannot complete sign-in, say which checks remain. Give the person the deployed link and ask them to sign in and try the app. Do not describe an untested sign-in or AI call as verified.

Expected result #

The app is deployed at its own address. You have its link and a clear account of the behavior your AI tested and any checks left for you.

Refusals #

See the deploy_files reference for the complete refusal list.

Related #

Keep working in the same chat to change the app. Preserve your changes when deploying another version. To work locally later, save the files at their application paths and follow Test your application locally.