@agent-native/core 0.145.8 → 0.146.0

package/docs/content/agent-native-config.mdx

@@ -1,14 +1,14 @@
 ---
 title: "Agent-Native app configuration"
-description: "Configure public Agent-Native app defaults with agent-native.ts, its typed aliases, or agent-native.json compatibility."
-search: "agent-native.ts agent-native.config.ts agent-native.config.mts agent-native.json onboarding runtime readiness configuration"
+description: "Configure public Agent-Native app defaults with agent-native.config.ts, its typed aliases, or agent-native.json compatibility."
+search: "agent-native.config.ts agent-native.ts agent-native.mts agent-native.config.mts agent-native.json onboarding runtime readiness configuration instructions"
 ---
 
 # Agent-Native app configuration
 
-Use `agent-native.ts` for new shared Agent-Native configuration. It is a typed,
-mode-aware source for committed, non-secret app defaults. The framework also
-accepts `agent-native.mts`, `agent-native.config.ts`, and
+Use `agent-native.config.ts` for new shared Agent-Native configuration. It is a
+typed, mode-aware source for committed, non-secret app defaults. The framework
+also accepts `agent-native.ts`, `agent-native.mts`, and
 `agent-native.config.mts` as filename aliases, and continues to read
 `agent-native.json` for compatibility.
 
@@ -23,9 +23,9 @@ app's Vite configuration. In a workspace, each app has its own root and its own
 configuration file. The Vite preset reads from the current app root, not from
 `server/plugins/` or a workspace-wide directory.
 
-For new apps, create `agent-native.ts`:
+For new apps, create `agent-native.config.ts`:
 
-```ts filename="agent-native.ts"
+```ts filename="agent-native.config.ts"
 import { defineAgentNativeConfig } from "@agent-native/core/config";
 
 export default defineAgentNativeConfig(({ command, mode, isBuild }) => {
@@ -88,6 +88,32 @@ configuration portion of `agent-native.json`:
 | `runtime.database.required`    | `boolean`                                                         | Declares whether production needs a persistent remote SQL database.                                                                                                                       |
 | `runtime.environment.required` | `string[]`                                                        | Declares additional required environment variable names. Names must match `[A-Za-z_][A-Za-z0-9_]*`; values do not belong in the config.                                                   |
 | `diagnostics.failOnBuild`      | `boolean`                                                         | When `true`, a production Vite build throws on runtime configuration issues. When absent or `false`, it reports them without failing the build.                                           |
+| `instructions.runtime`         | `string`                                                          | Optional relative Markdown path for the in-app runtime agent. Defaults to `AGENTS.md`.                                                                                                    |
+| `instructions.development`     | `string`                                                          | Optional relative Markdown path for development/coding agents. Defaults to `AGENTS.md`.                                                                                                   |
+
+### Separate runtime and development instructions
+
+The default is intentionally flat: both audiences read `AGENTS.md`, and
+existing apps do not need to change. To keep development guidance out of the
+deployed app agent, opt in with audience-specific paths:
+
+```ts filename="agent-native.config.ts"
+import { defineAgentNativeConfig } from "@agent-native/core/config";
+
+export default defineAgentNativeConfig({
+  instructions: {
+    runtime: "app-agent/AGENTS.md",
+    development: "DEVELOPING.md",
+  },
+});
+```
+
+Paths are relative to the app root and cannot escape it. If an explicitly
+selected file is missing, that audience receives no file; the framework does
+not fall back to `AGENTS.md`, because that could reintroduce development-only
+guidance into runtime. Skills keep their existing frontmatter audience scope:
+use `scope: runtime`, `scope: dev`, or `scope: both` when a skill needs a
+different boundary.
 
 ### Mode maps for onboarding
 
@@ -98,7 +124,7 @@ exact Vite modes. The resolver checks the exact `mode` first. If there is no
 exact match, it checks `development` for `serve` or `production` for `build`,
 then `default`, and finally falls back to `off`:
 
-```ts filename="agent-native.ts"
+```ts filename="agent-native.config.ts"
 import { defineAgentNativeConfig } from "@agent-native/core/config";
 
 export default defineAgentNativeConfig({
@@ -143,7 +169,7 @@ guidance, never secret values.
 For example, this is a useful readiness declaration when an app uses the
 framework's normal auth and database contracts:
 
-```ts filename="agent-native.ts"
+```ts filename="agent-native.config.ts"
 import { defineAgentNativeConfig } from "@agent-native/core/config";
 
 export default defineAgentNativeConfig({
@@ -160,7 +186,7 @@ Set the actual deployment values outside the repository. For example, provide
 `BETTER_AUTH_SECRET`, `DATABASE_URL`, and `PUBLIC_API_ORIGIN` in Netlify,
 Vercel, another deployment environment, or the appropriate scoped secret
 store. Do not replace those placeholders with literal values in
-`agent-native.ts`.
+`agent-native.config.ts`.
 
 `diagnostics.failOnBuild` is for runtime configuration diagnostics. It is not
 the same setting as the separate `doctor.failOnBuild` option documented in the
@@ -174,8 +200,8 @@ For a Vite app, the effective shared configuration follows this order:
    persistent database default to required in production diagnostics.
 2. `agent-native.json` at the app root.
 3. The automatically loaded typed file, if present. The loader checks these
-   candidates in order: `agent-native.ts`, `agent-native.mts`,
-   `agent-native.config.ts`, `agent-native.config.mts`.
+   candidates in order: `agent-native.config.ts`, `agent-native.ts`,
+   `agent-native.mts`, `agent-native.config.mts`.
 4. An explicit `agentNativeConfig` passed to `agentNative()` or the legacy
    `defineConfig()` wrapper. Supplying this option skips automatic typed-file
    loading, while the explicit value still overlays `agent-native.json`.
@@ -185,8 +211,8 @@ For a Vite app, the effective shared configuration follows this order:
    resolved onboarding mode. Use the config file for new work.
 
 Use only one of the four typed filenames. If more than one exists, the first
-candidate in the loader's order wins, with `agent-native.ts` preferred for new
-apps. The names are aliases, not four layers that are merged together.
+candidate in the loader's order wins, with `agent-native.config.ts` preferred
+for new apps. The names are aliases, not four layers that are merged together.
 
 The JSON and typed sources are merged by supported nested section:
 
@@ -200,7 +226,7 @@ The JSON and typed sources are merged by supported nested section:
   supplies it, it replaces the lower-precedence string or mode map as a whole.
 
 For example, JSON can provide `runtime.auth.enabled` and
-`NOTION_API_KEY`, while `agent-native.ts` adds `runtime.database.required` and
+`NOTION_API_KEY`, while `agent-native.config.ts` adds `runtime.database.required` and
 `GOOGLE_CLIENT_ID`. The result keeps the auth setting, adds the database
 setting, and checks both environment names.
 
@@ -223,7 +249,7 @@ Do not commit these values to either config format:
   vary by environment.
 
 Even a value that is not a secret should stay in deployment configuration when
-it changes between targets. `agent-native.ts` should describe the app's
+it changes between targets. `agent-native.config.ts` should describe the app's
 public shape, not become a second environment-variable file.
 
 ## `agent-native.json` compatibility
@@ -254,7 +280,7 @@ default that never depends on the Vite command or mode:
 }
 ```
 
-For new app-owned configuration, prefer `agent-native.ts` when the app needs
+For new app-owned configuration, prefer `agent-native.config.ts` when the app needs
 types, a mode-aware factory, or a clear place to evolve public defaults. Keep
 `agent-native.json` when portability or existing manifest sections are the
 reason to use it. Both formats accept the same shared options shown above.

package/docs/content/environment-variables.mdx

@@ -90,7 +90,7 @@ values.
 Every framework app exposes the redacted report at
 `/_agent-native/ping?configuration=1`. The shared provider shell turns a
 non-healthy production report into a warning or error chip with a **Copy
-prompt for AI** button. `agent-native.ts` or its compatibility aliases can add
+prompt for AI** button. `agent-native.config.ts` or its compatibility aliases can add
 non-secret requirements under `runtime.environment.required`; set the actual
 values in Netlify, Vercel, or the deployment's secret store.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@agent-native/core",
-  "version": "0.145.8",
+  "version": "0.146.0",
   "description": "Framework for agent-native application development — where AI agents and UI share SQL state, actions, and context",
   "homepage": "https://github.com/BuilderIO/agent-native#readme",
   "bugs": {
@@ -412,8 +412,8 @@
     "y-protocols": "^1.0.7",
     "yjs": "^13.6.31",
     "zod": "^4.3.6",
-    "@agent-native/recap-cli": "0.5.3",
-    "@agent-native/toolkit": "^0.13.4"
+    "@agent-native/toolkit": "^0.13.4",
+    "@agent-native/recap-cli": "0.5.3"
   },
   "devDependencies": {
     "@ai-sdk/anthropic": "^3.0.71",

package/src/templates/chat/.agents/skills/turn-into-app/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Turn visible project context, a proven thread, skill, or workflow into a
   runnable Agent-Native app with simple buttons, visible agent steps, preview,
   and deployment handoff. Use when a user invokes `/turn-into-app` or asks to
-  make a workflow into an app.
+  make a workflow into an app, including from Claude or ChatGPT on the web.
 user-invocable: true
 scope: both
 metadata:
@@ -13,9 +13,32 @@ metadata:
 
 # Turn Into App
 
+## Host execution boundary
+
+The build location depends on the host. Treat this as a hard routing rule:
+
+- In Claude Web, ChatGPT Web, or a Claude/ChatGPT Project on the web, you are
+  the source analyst and handoff orchestrator. You must not build the app in
+  the host sandbox. 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`, and selected
+  `resourceIds` when available. This is the Builder handoff.
+- Do not substitute the generic `create_workspace_app` MCP tool in an online
+  host. That tool is a local workspace scaffolder, not the Builder handoff.
+- If `start-workspace-app-creation` is not available or Dispatch is not
+  authenticated, stop with the connector setup needed. Do not fall back to a
+  local build or claim that the app exists.
+- In Claude Code, Codex Code, or another local code-agent runtime with a target
+  workspace, follow the local implementation steps below. The local agent may
+  scaffold, edit, run, and verify the app there.
+
 ## Default behavior
 
-This is an end-to-end build skill, not a request for an app proposal.
+For a local code-agent runtime this is an end-to-end build skill, not a request
+for an app proposal. For an online host, the end-to-end result is a verified
+Builder handoff and the resulting workspace app, not code written in the 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
@@ -47,9 +70,12 @@ 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.
 
-Deliver a fresh app in a new directory, implement the repeatable workflow with
-buttons and agent handoffs, start its dev server, verify the main path, and
-continue through build/deployment handoff. Do not stop at a plan.
+For local code-agent runtimes, deliver a fresh app in a new directory,
+implement the repeatable workflow with buttons and agent handoffs, start its dev
+server, verify the main path, and continue through build/deployment handoff. Do
+not stop at a plan. For online hosts, call Dispatch first after the source brief,
+then report the returned Builder branch/path and verify the workspace app through
+Dispatch when it becomes available.
 
 ## Fresh project context mode
 
@@ -190,12 +216,12 @@ Do not use `create` for an existing workspace; it scaffolds a new standalone
 workspace rather than adding an app to the current one.
 
 When the source came from a fresh external Project and the target is a Builder
-workspace, prefer the available Dispatch MCP workspace handoff after writing
-the source brief. Call `start-workspace-app-creation` with a concise prompt,
-the inferred app id, and the brief's repeatable workflow. Pass selected
-workspace resource IDs when they are available, rather than pasting entire
-knowledge files. Continue from the returned workspace path or Builder handoff
-and report the actual verification result.
+workspace, the online host path is mandatory: after writing the source brief,
+call `start-workspace-app-creation` with a concise prompt, the inferred app id,
+and the brief's repeatable workflow. Pass selected workspace resource IDs when
+they are available, rather than pasting entire knowledge files. Continue from
+the returned workspace path or Builder branch handoff and report the actual
+verification result. Do not run the local scaffold commands in this host mode.
 
 Use a first-party template only when it materially fits the workflow. Keep the
 new app independent from the source thread's working tree unless the user

package/src/templates/chat/.agents/skills/turn-into-app/references/fresh-project.md

@@ -51,13 +51,24 @@ also place the skill instructions or this reference in the Project
 instructions/knowledge files. Then add and authenticate the Dispatch MCP
 connector from the packaged `adapters/chatgpt-mcp/connector.json`.
 
+For Claude Web, ChatGPT Web, and their web Projects, the host is an
+orchestrator, not the build environment. After forming the source brief, call
+the Dispatch `start-workspace-app-creation` action so Builder creates the app
+in the connected workspace. Do not use the host's code interpreter, shell,
+artifact editor, `create_workspace_app`, or local `pnpm`/`npm` commands. If the
+handoff action is unavailable, stop and ask the user to authenticate Dispatch;
+do not fall back to a local sandbox build. Claude Code and Codex Code are the
+local-agent exception and may follow the implementation steps in the main
+skill.
+
 In a new Project chat, say:
 
 ```text
 Turn this project into an app. Use the visible Project instructions,
 knowledge files, and any selected successful runs as the source. Create the
-app in the connected Agent-Native workspace, keep the source brief bounded,
-and report the real path and verification result.
+app in the connected Agent-Native workspace through Dispatch and Builder, keep
+the source brief bounded, and report the real Builder branch/path and
+verification result. Do not build it in this chat's sandbox.
 ```
 
 If the host does not show the Project instructions or files to the model, stop

package/src/templates/default/.agents/skills/turn-into-app/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Turn visible project context, a proven thread, skill, or workflow into a
   runnable Agent-Native app with simple buttons, visible agent steps, preview,
   and deployment handoff. Use when a user invokes `/turn-into-app` or asks to
-  make a workflow into an app.
+  make a workflow into an app, including from Claude or ChatGPT on the web.
 user-invocable: true
 scope: both
 metadata:
@@ -13,9 +13,32 @@ metadata:
 
 # Turn Into App
 
+## Host execution boundary
+
+The build location depends on the host. Treat this as a hard routing rule:
+
+- In Claude Web, ChatGPT Web, or a Claude/ChatGPT Project on the web, you are
+  the source analyst and handoff orchestrator. You must not build the app in
+  the host sandbox. 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`, and selected
+  `resourceIds` when available. This is the Builder handoff.
+- Do not substitute the generic `create_workspace_app` MCP tool in an online
+  host. That tool is a local workspace scaffolder, not the Builder handoff.
+- If `start-workspace-app-creation` is not available or Dispatch is not
+  authenticated, stop with the connector setup needed. Do not fall back to a
+  local build or claim that the app exists.
+- In Claude Code, Codex Code, or another local code-agent runtime with a target
+  workspace, follow the local implementation steps below. The local agent may
+  scaffold, edit, run, and verify the app there.
+
 ## Default behavior
 
-This is an end-to-end build skill, not a request for an app proposal.
+For a local code-agent runtime this is an end-to-end build skill, not a request
+for an app proposal. For an online host, the end-to-end result is a verified
+Builder handoff and the resulting workspace app, not code written in the 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
@@ -47,9 +70,12 @@ 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.
 
-Deliver a fresh app in a new directory, implement the repeatable workflow with
-buttons and agent handoffs, start its dev server, verify the main path, and
-continue through build/deployment handoff. Do not stop at a plan.
+For local code-agent runtimes, deliver a fresh app in a new directory,
+implement the repeatable workflow with buttons and agent handoffs, start its dev
+server, verify the main path, and continue through build/deployment handoff. Do
+not stop at a plan. For online hosts, call Dispatch first after the source brief,
+then report the returned Builder branch/path and verify the workspace app through
+Dispatch when it becomes available.
 
 ## Fresh project context mode
 
@@ -190,12 +216,12 @@ Do not use `create` for an existing workspace; it scaffolds a new standalone
 workspace rather than adding an app to the current one.
 
 When the source came from a fresh external Project and the target is a Builder
-workspace, prefer the available Dispatch MCP workspace handoff after writing
-the source brief. Call `start-workspace-app-creation` with a concise prompt,
-the inferred app id, and the brief's repeatable workflow. Pass selected
-workspace resource IDs when they are available, rather than pasting entire
-knowledge files. Continue from the returned workspace path or Builder handoff
-and report the actual verification result.
+workspace, the online host path is mandatory: after writing the source brief,
+call `start-workspace-app-creation` with a concise prompt, the inferred app id,
+and the brief's repeatable workflow. Pass selected workspace resource IDs when
+they are available, rather than pasting entire knowledge files. Continue from
+the returned workspace path or Builder branch handoff and report the actual
+verification result. Do not run the local scaffold commands in this host mode.
 
 Use a first-party template only when it materially fits the workflow. Keep the
 new app independent from the source thread's working tree unless the user

package/src/templates/default/.agents/skills/turn-into-app/references/fresh-project.md

@@ -51,13 +51,24 @@ also place the skill instructions or this reference in the Project
 instructions/knowledge files. Then add and authenticate the Dispatch MCP
 connector from the packaged `adapters/chatgpt-mcp/connector.json`.
 
+For Claude Web, ChatGPT Web, and their web Projects, the host is an
+orchestrator, not the build environment. After forming the source brief, call
+the Dispatch `start-workspace-app-creation` action so Builder creates the app
+in the connected workspace. Do not use the host's code interpreter, shell,
+artifact editor, `create_workspace_app`, or local `pnpm`/`npm` commands. If the
+handoff action is unavailable, stop and ask the user to authenticate Dispatch;
+do not fall back to a local sandbox build. Claude Code and Codex Code are the
+local-agent exception and may follow the implementation steps in the main
+skill.
+
 In a new Project chat, say:
 
 ```text
 Turn this project into an app. Use the visible Project instructions,
 knowledge files, and any selected successful runs as the source. Create the
-app in the connected Agent-Native workspace, keep the source brief bounded,
-and report the real path and verification result.
+app in the connected Agent-Native workspace through Dispatch and Builder, keep
+the source brief bounded, and report the real Builder branch/path and
+verification result. Do not build it in this chat's sandbox.
 ```
 
 If the host does not show the Project instructions or files to the model, stop

package/src/templates/headless/.agents/skills/turn-into-app/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Turn visible project context, a proven thread, skill, or workflow into a
   runnable Agent-Native app with simple buttons, visible agent steps, preview,
   and deployment handoff. Use when a user invokes `/turn-into-app` or asks to
-  make a workflow into an app.
+  make a workflow into an app, including from Claude or ChatGPT on the web.
 user-invocable: true
 scope: both
 metadata:
@@ -13,9 +13,32 @@ metadata:
 
 # Turn Into App
 
+## Host execution boundary
+
+The build location depends on the host. Treat this as a hard routing rule:
+
+- In Claude Web, ChatGPT Web, or a Claude/ChatGPT Project on the web, you are
+  the source analyst and handoff orchestrator. You must not build the app in
+  the host sandbox. 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`, and selected
+  `resourceIds` when available. This is the Builder handoff.
+- Do not substitute the generic `create_workspace_app` MCP tool in an online
+  host. That tool is a local workspace scaffolder, not the Builder handoff.
+- If `start-workspace-app-creation` is not available or Dispatch is not
+  authenticated, stop with the connector setup needed. Do not fall back to a
+  local build or claim that the app exists.
+- In Claude Code, Codex Code, or another local code-agent runtime with a target
+  workspace, follow the local implementation steps below. The local agent may
+  scaffold, edit, run, and verify the app there.
+
 ## Default behavior
 
-This is an end-to-end build skill, not a request for an app proposal.
+For a local code-agent runtime this is an end-to-end build skill, not a request
+for an app proposal. For an online host, the end-to-end result is a verified
+Builder handoff and the resulting workspace app, not code written in the 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
@@ -47,9 +70,12 @@ 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.
 
-Deliver a fresh app in a new directory, implement the repeatable workflow with
-buttons and agent handoffs, start its dev server, verify the main path, and
-continue through build/deployment handoff. Do not stop at a plan.
+For local code-agent runtimes, deliver a fresh app in a new directory,
+implement the repeatable workflow with buttons and agent handoffs, start its dev
+server, verify the main path, and continue through build/deployment handoff. Do
+not stop at a plan. For online hosts, call Dispatch first after the source brief,
+then report the returned Builder branch/path and verify the workspace app through
+Dispatch when it becomes available.
 
 ## Fresh project context mode
 
@@ -190,12 +216,12 @@ Do not use `create` for an existing workspace; it scaffolds a new standalone
 workspace rather than adding an app to the current one.
 
 When the source came from a fresh external Project and the target is a Builder
-workspace, prefer the available Dispatch MCP workspace handoff after writing
-the source brief. Call `start-workspace-app-creation` with a concise prompt,
-the inferred app id, and the brief's repeatable workflow. Pass selected
-workspace resource IDs when they are available, rather than pasting entire
-knowledge files. Continue from the returned workspace path or Builder handoff
-and report the actual verification result.
+workspace, the online host path is mandatory: after writing the source brief,
+call `start-workspace-app-creation` with a concise prompt, the inferred app id,
+and the brief's repeatable workflow. Pass selected workspace resource IDs when
+they are available, rather than pasting entire knowledge files. Continue from
+the returned workspace path or Builder branch handoff and report the actual
+verification result. Do not run the local scaffold commands in this host mode.
 
 Use a first-party template only when it materially fits the workflow. Keep the
 new app independent from the source thread's working tree unless the user

package/src/templates/headless/.agents/skills/turn-into-app/references/fresh-project.md

@@ -51,13 +51,24 @@ also place the skill instructions or this reference in the Project
 instructions/knowledge files. Then add and authenticate the Dispatch MCP
 connector from the packaged `adapters/chatgpt-mcp/connector.json`.
 
+For Claude Web, ChatGPT Web, and their web Projects, the host is an
+orchestrator, not the build environment. After forming the source brief, call
+the Dispatch `start-workspace-app-creation` action so Builder creates the app
+in the connected workspace. Do not use the host's code interpreter, shell,
+artifact editor, `create_workspace_app`, or local `pnpm`/`npm` commands. If the
+handoff action is unavailable, stop and ask the user to authenticate Dispatch;
+do not fall back to a local sandbox build. Claude Code and Codex Code are the
+local-agent exception and may follow the implementation steps in the main
+skill.
+
 In a new Project chat, say:
 
 ```text
 Turn this project into an app. Use the visible Project instructions,
 knowledge files, and any selected successful runs as the source. Create the
-app in the connected Agent-Native workspace, keep the source brief bounded,
-and report the real path and verification result.
+app in the connected Agent-Native workspace through Dispatch and Builder, keep
+the source brief bounded, and report the real Builder branch/path and
+verification result. Do not build it in this chat's sandbox.
 ```
 
 If the host does not show the Project instructions or files to the model, stop

package/src/templates/workspace-core/.agents/skills/turn-into-app/SKILL.md

@@ -4,7 +4,7 @@ description: >-
   Turn visible project context, a proven thread, skill, or workflow into a
   runnable Agent-Native app with simple buttons, visible agent steps, preview,
   and deployment handoff. Use when a user invokes `/turn-into-app` or asks to
-  make a workflow into an app.
+  make a workflow into an app, including from Claude or ChatGPT on the web.
 user-invocable: true
 scope: both
 metadata:
@@ -13,9 +13,32 @@ metadata:
 
 # Turn Into App
 
+## Host execution boundary
+
+The build location depends on the host. Treat this as a hard routing rule:
+
+- In Claude Web, ChatGPT Web, or a Claude/ChatGPT Project on the web, you are
+  the source analyst and handoff orchestrator. You must not build the app in
+  the host sandbox. 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`, and selected
+  `resourceIds` when available. This is the Builder handoff.
+- Do not substitute the generic `create_workspace_app` MCP tool in an online
+  host. That tool is a local workspace scaffolder, not the Builder handoff.
+- If `start-workspace-app-creation` is not available or Dispatch is not
+  authenticated, stop with the connector setup needed. Do not fall back to a
+  local build or claim that the app exists.
+- In Claude Code, Codex Code, or another local code-agent runtime with a target
+  workspace, follow the local implementation steps below. The local agent may
+  scaffold, edit, run, and verify the app there.
+
 ## Default behavior
 
-This is an end-to-end build skill, not a request for an app proposal.
+For a local code-agent runtime this is an end-to-end build skill, not a request
+for an app proposal. For an online host, the end-to-end result is a verified
+Builder handoff and the resulting workspace app, not code written in the 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
@@ -47,9 +70,12 @@ 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.
 
-Deliver a fresh app in a new directory, implement the repeatable workflow with
-buttons and agent handoffs, start its dev server, verify the main path, and
-continue through build/deployment handoff. Do not stop at a plan.
+For local code-agent runtimes, deliver a fresh app in a new directory,
+implement the repeatable workflow with buttons and agent handoffs, start its dev
+server, verify the main path, and continue through build/deployment handoff. Do
+not stop at a plan. For online hosts, call Dispatch first after the source brief,
+then report the returned Builder branch/path and verify the workspace app through
+Dispatch when it becomes available.
 
 ## Fresh project context mode
 
@@ -190,12 +216,12 @@ Do not use `create` for an existing workspace; it scaffolds a new standalone
 workspace rather than adding an app to the current one.
 
 When the source came from a fresh external Project and the target is a Builder
-workspace, prefer the available Dispatch MCP workspace handoff after writing
-the source brief. Call `start-workspace-app-creation` with a concise prompt,
-the inferred app id, and the brief's repeatable workflow. Pass selected
-workspace resource IDs when they are available, rather than pasting entire
-knowledge files. Continue from the returned workspace path or Builder handoff
-and report the actual verification result.
+workspace, the online host path is mandatory: after writing the source brief,
+call `start-workspace-app-creation` with a concise prompt, the inferred app id,
+and the brief's repeatable workflow. Pass selected workspace resource IDs when
+they are available, rather than pasting entire knowledge files. Continue from
+the returned workspace path or Builder branch handoff and report the actual
+verification result. Do not run the local scaffold commands in this host mode.
 
 Use a first-party template only when it materially fits the workflow. Keep the
 new app independent from the source thread's working tree unless the user

package/src/templates/workspace-core/.agents/skills/turn-into-app/references/fresh-project.md

@@ -51,13 +51,24 @@ also place the skill instructions or this reference in the Project
 instructions/knowledge files. Then add and authenticate the Dispatch MCP
 connector from the packaged `adapters/chatgpt-mcp/connector.json`.
 
+For Claude Web, ChatGPT Web, and their web Projects, the host is an
+orchestrator, not the build environment. After forming the source brief, call
+the Dispatch `start-workspace-app-creation` action so Builder creates the app
+in the connected workspace. Do not use the host's code interpreter, shell,
+artifact editor, `create_workspace_app`, or local `pnpm`/`npm` commands. If the
+handoff action is unavailable, stop and ask the user to authenticate Dispatch;
+do not fall back to a local sandbox build. Claude Code and Codex Code are the
+local-agent exception and may follow the implementation steps in the main
+skill.
+
 In a new Project chat, say:
 
 ```text
 Turn this project into an app. Use the visible Project instructions,
 knowledge files, and any selected successful runs as the source. Create the
-app in the connected Agent-Native workspace, keep the source brief bounded,
-and report the real path and verification result.
+app in the connected Agent-Native workspace through Dispatch and Builder, keep
+the source brief bounded, and report the real Builder branch/path and
+verification result. Do not build it in this chat's sandbox.
 ```
 
 If the host does not show the Project instructions or files to the model, stop