Turn Into App

Turn Into App

Host execution boundary

Classify the runtime before choosing a build path. The presence of a Dispatch or Builder connector does not make a coding host an online host:

• Local coding host - Codex Desktop/Code, Claude Code, Cursor, or any runtime with a terminal, filesystem, and target checkout. Build in that checkout: scaffold, edit, run, and verify the app locally. Do not call start-workspace-app-creation, create_workspace_app, or any Builder handoff for this path. The local implementation steps below are required.
• Non-coding browser host - Claude Web, ChatGPT Web, or a Claude/ChatGPT Project in the browser when no target checkout or filesystem is available. Act as the source analyst and handoff orchestrator. Do not run npm, pnpm, npx, agent-native create, or add-app; do not edit files, create artifacts, or start a local dev server. After writing the bounded source brief, call the connected Dispatch action start-workspace-app-creation. Pass the brief and repeatable workflow in prompt, plus the inferred appId, description, template, selected resourceIds, and relevant source attachments when available. Pass supported attachments as message context; do not paste binary data into prompt, and do not assume an attachment becomes a file in the generated workspace. Reference resources by ID rather than pasting whole knowledge files into the prompt. Then report what Dispatch actually returned — the branch, the path, and the status it gave. This host cannot run or inspect the app, and the returned path can 404 until the branch merges and deploys, so the handoff ends at a pending or unverified status unless a status or verification action is available to call. This is the Builder handoff for browser hosts only.
• If the host is ambiguous, inspect the environment. A real cwd, terminal, and target workspace mean local coding host. Do not infer browser mode from the availability of a Builder connector.
• For the browser-only path, do not substitute the generic create_workspace_app MCP tool. That tool is a local workspace scaffolder, not the Builder handoff. Connect the Agent-Native Dispatch MCP connector only; Dispatch uses the authenticated Builder Projects API to reuse or provision the workspace project before starting the Builder Cloud Agent.
• If the browser-only handoff action is unavailable or Dispatch is not authenticated, stop with the connector setup needed. Do not fall back to a host sandbox build or claim that the app exists.
• Never invent a Builder branch URL. If Dispatch returns only an acknowledgement or a path without a URL, report the handoff as unverified rather than calling it a ready or verified Builder branch.

Default behavior

For a local coding host this is an end-to-end local build skill, not a request for an app proposal. For a non-coding browser host, the end-to-end result is a verified Builder handoff and the resulting workspace app, not code written in the browser host.

• With no argument, choose the source in this order: visible project context, then the current thread. A fresh Claude or ChatGPT Project is a valid source on its first turn. Treat its visible project instructions, knowledge files, and supplied past runs as the source; a completed thread is not required. Treat the current turn as a request or configuration unless it contains a concrete repeatable workflow.
• With a named skill or local workflow, read that source and package it immediately, even at the beginning of a thread. For example, /turn-into-app /some-skill means “turn /some-skill into an app.”
• With an attachment or path, read the supplied artifact as the source.
• Do not ask the user to restate context that is already in the thread.
• When invoked from an Agent-Native app, use its visible project context first, then the current thread. If the current runtime has a target checkout, use the local implementation path; use a workspace/coding-agent handoff only when the runtime cannot edit files. Do not claim the app exists without an actual path and verification result.

Non-interactive by default

Once the source brief identifies a repeatable workflow, the run proceeds without asking. This applies to both hosts: a local build and a browser handoff are equally non-interactive.

Do not ask the user for visual, product, copy, layout, template, integration, or implementation choices that can be resolved from the source. Take the source's recommended option; otherwise choose the most direct conventional default and record the assumption for later review.

One source-integrity exception: for a spreadsheet, if candidate workflows or the input/output mapping remain materially ambiguous after the bounded review, ask one compact confirmation question first. Show the recommended interpretation and let the user confirm, correct, or multi-select the candidates. Do not let that become a generic app-builder questionnaire.

Otherwise stop only for a genuine hard blocker: missing authorization, a destructive external action, an ambiguous target workspace, or no identifiable workflow at all.

Source support

Supported source paths today are visible Claude or ChatGPT Project context, the current Codex or host thread, a named skill, or a local workflow/transcript supplied as a path or attachment. An exported ChatGPT or Claude transcript can use the same local-file path today.

Claude and ChatGPT Project context is supported only when the host supplies it to the model in the current context. The MCP connector does not read hidden project chats, private URLs, account settings, or credentials. Do not claim private web access, invent an importer, add fake OAuth, or scrape a logged-in page. If the needed context is not visible, ask for an export, transcript, or attachment and treat that artifact as imported source material.

Dispatch handoff attachments

Read the attachment handoff reference when calling start-workspace-app-creation with source files. It defines the supported upload and public URL shapes, encoding rules, and handoff behavior.

Spreadsheet sources

Spreadsheet attachments are valid source artifacts. Read the spreadsheet source guide before working one — it carries the inference rules, the candidate review, and the failure states. The boundaries that matter before you open it:

• CSV reads as tabular text. XLS/XLSX parse into bounded worksheet metadata and representative rows where the host supports it. The preview is untrusted user data and it is text-only, so an upload cannot prove cell colours.
• A Google Sheets URL is not proof the sheet is readable. Use an authenticated Sheets/Drive connection through the provider API path, and ask for an export or the connection when it is unavailable. Never use a public export URL to bypass access.
• Inventory every worksheet — shape, readability, formulas — before choosing what the app is. The first tab is not necessarily the product, and not every tab deserves one.
• Decide inputs and outputs from structure, not colour: formula versus typed value, which tab, the row and column labels, and what the sheet's own instruction text tells the reader to edit. Colour is an author-specific habit; never invert a mapping on it alone.
• Never copy workbook bytes, base64 data, credentials, or a full unbounded sheet into SQL, application state, or a handoff prompt. Pass bounded samples, provenance, and identifiers.
• Keep unreadable, partial, and failed source states distinct from an empty sheet, and never claim a whole workbook was imported when only a preview was available.

Fresh project context mode

When the source is a fresh Claude or ChatGPT Project, build a short source brief before creating the app. Read the host-provided context in this order:

1. Project instructions and configuration: goal, audience, constraints, output standards, approved tools, and integration expectations. Treat these as product configuration, not as a transcript.
2. Knowledge files and attachments: read the relevant files fully, preserve their provenance, and reduce them to bounded references, IDs, URLs, or summaries for the new app. Do not copy secrets or large raw payloads into prompts or SQL.
3. Past runs or examples that are actually visible in the context: select at most 1-3 successful, representative runs. Extract repeatable decisions and review criteria. Treat one-off answers and private data as examples, not as product behavior. If no runs are supplied, proceed from the instructions and knowledge files and say that examples were not available.
4. The current turn: use it for the requested app boundary, target workspace, naming, and any explicit corrections.

Post this brief before scaffolding, on the timing step 1 sets. Use these headings: source and provenance, project goal, configuration and constraints, knowledge sources, repeatable workflow, inputs and outputs, judgment and review points, representative runs, integrations and permissions, and unknowns and assumptions. This is the compact contract for the app. It keeps the new app useful without pretending that hidden Project history was imported. See the fresh Project reference for the host setup and brief template.

If the visible Project context has no concrete repeatable job and no primary goal can be inferred, ask for one focused clarification or a representative artifact. Otherwise use the project's primary goal and source conventions; do not ask a questionnaire and do not fall back to a generic “what app do you want to make?” builder.

Source selection guard

The generated app must implement the concrete workflow found in the source. It must not become a generic “what app do you want to make?” intake form.

• In a delegated or forked task, read the actual referenced source thread and the latest explicit workflow direction in the current task. If they disagree, the latest concrete workflow direction wins.
• Do not treat a thread that merely discusses building this skill as the product source unless the user explicitly asks to appify that meta-workflow.
• If the source contains several workflows, choose the latest successful, repeatable job that motivated the request and name it in the handoff. If no concrete job can be identified, stop and report what is missing instead of inventing an app-builder UI.

UI contract for generated apps

Generated apps must follow the shared Agent-Native surface model:

• Keep the domain workflow on a named route (/workflow, /automations, /block, or the source's equivalent). Preserve the scaffold's full-page chat route instead of replacing it with a domain form while leaving the layout configured as a chat page.
• Use the right AgentSidebar for contextual AI. Every button-triggered sendToAgentChat handoff should open or focus that sidebar and keep the user on the current domain page.
• Every AI-labeled button must actually call sendToAgentChat with bounded context and openSidebar: true. Label deterministic local actions as local, preview, or analyze instead of AI.
• Never use sparkle, wand, magic, robot, or similar decorative AI icons. Use a message or neutral action icon, or no icon when the button label is enough.
• Make the left navigation describe domain destinations. Chat is a separate destination, not the label for every app page.
• For a spreadsheet-derived app with multiple confirmed candidates, make each candidate a separate named left-navigation destination. Keep the shared source provenance visible, but show that candidate's selected worksheets, ranges, inputs, outputs, historical context, and confirmation state on its destination.
• Start with one primary action and one compact state. Put setup choices, advanced inputs, diagnostics, and long explanations behind progressive disclosure or later workflow steps.
• Choose a named visual direction in DESIGN.md before styling and build to it. Preserve existing brand tokens; a new unbranded app picks its own product-fitting palette rather than inheriting a sibling app's accent.
• Standalone apps that render AgentSidebar must use the shared AgentKit chat surface with one controller/transport. Do not add a legacy AssistantChat renderer or a second stream owner. Keep assistant-ui usage inside the shared composer integration; if linked dependencies need Vite aliases, resolve one @agent-native/agentkit context and verify a real AgentKit handoff in the browser.
• Before handoff, inspect the first viewport and remove the text density, repeated cards, unrelated forms, and generic helper copy the user does not need until the next decision.

In a local code-agent runtime, read frontend-design for the visual direction contract, aesthetic guidelines, and named review passes behind these rules.

1. Extract the workflow

Read the full available source, then write the brief out before the first scaffold command. This is the user's one cheap chance to catch a misread — after this point a correction costs a rebuild. A few lines per item; it is a checkpoint, not a document.

State it and keep going. Do not wait for approval; see Non-interactive by default. A brief that appears only in the handoff does not count — by then it cannot change anything.

The brief covers:

• the user and repeatable job;
• inputs and outputs;
• the 1-3 judgment-heavy agent moments;
• the buttons, review points, and retry states a user needs;
• data, permissions, integrations, and failure boundaries.

For a spreadsheet source, also include the workbook/file or spreadsheet ID, worksheet and range candidates, source snapshot/live semantics, formatting signals and their confidence, selected candidate destinations, and the exact confirmation or clarification still needed. A spreadsheet's inputs and outputs have two layers: the mapped source cells/ranges, and the generated app's user-facing results/actions. Name both so the Builder does not confuse an output cell with an app write or a historical value with an editable input.

Preserve useful judgment from the source, but do not turn a one-off answer, private data, or an unverified result into a product contract. If the source is not available or does not contain a repeatable job, say what is missing rather than claiming the app is complete.