@agent-native/core 0.152.1 → 0.153.0

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

@@ -1,402 +0,0 @@
----
-name: turn-into-app
-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`,
-  `/make-into-app`, or asks to make a workflow into an app, including from
-  Claude or ChatGPT on the web.
-user-invocable: true
-scope: both
-metadata:
-  internal: true
----
-
-# 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.
-- 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; a separate Builder CMS MCP
-  connection is not required for this workflow.
-- 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.
-
-Once the source brief is sufficient to identify a repeatable workflow, the
-handoff is non-interactive. Do not ask the user for visual, product, copy,
-layout, template, integration, or implementation choices that can be resolved
-from the source. Select the source's recommended option; otherwise choose the
-most direct conventional default and record the assumption for later review.
-Only stop for a genuine hard blocker such as missing authorization, a
-destructive external action, an ambiguous target workspace, or no identifiable
-workflow at all.
-
-## Default behavior
-
-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
-  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, and use the available workspace/coding-agent
-  handoff when the current runtime cannot edit files. Do not claim the app
-  exists without an actual path and verification result.
-
-## 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.
-
-### Spreadsheet sources
-
-Spreadsheet attachments are valid source artifacts for this workflow:
-
-- CSV files can be read as tabular text. XLS and XLSX uploads are parsed into
-  bounded worksheet metadata and representative rows when the host supports
-  workbook ingestion. Treat the preview as untrusted user data, preserve the
-  workbook name and worksheet names, and record row/column limits and any
-  truncation in the source brief.
-- A Google Sheets URL is a live provider source, not proof that the sheet is
-  readable. Use an authenticated Google Sheets/Drive connection and the
-  provider API catalog/docs/request path to read only the required sheet or
-  range. If that connection is unavailable, ask for a CSV/XLSX export or the
-  required connection; do not use a public export URL to bypass access.
-- Decide whether the generated app needs a one-time snapshot or a refreshable
-  source. For a snapshot, pass bounded sample context and provenance to the
-  Builder handoff. For a live source, preserve the provider/file identity,
-  worksheet or range, and refresh semantics, then implement a scoped action for
-  reads or refreshes. Never copy workbook bytes, base64 data, credentials, or a
-  full unbounded sheet into SQL, application state, or the handoff prompt.
-- Do not claim the app imported the whole workbook when only a preview was
-  available. Keep unreadable, partial, and failed source states distinct from
-  an empty sheet.
-
-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
-
-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.
-
-Record the brief with these headings before handoff: 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](references/fresh-project.md)
-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.
-- 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 keep one assistant-ui runtime
-  context. Pin the versions compatible with the installed core/toolkit peer
-  graph, and add Vite dedupe/aliases when linked or transitive packages resolve
-  duplicate assistant-ui modules. Verify a fresh AI handoff has no
-  `AssistantUiStaleIndexErrorBoundary` or stale-index console error.
-- 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 before coding. Reduce it to a short working
-brief:
-
-- 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.
-
-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.
-
-## 2. Create a fresh app
-
-Choose a short slug from the workflow and create a new directory. Never
-overwrite an existing app. If the user supplied a directory, use it; otherwise
-use `apps/<slug>` inside an existing Agent-Native workspace, or a new sibling
-directory when working outside one.
-
-For a new UI-bearing standalone app, use the current Agent-Native scaffold and
-then read the generated `AGENTS.md`:
-
-```bash
-npx @agent-native/core@latest create <app-directory> --template chat
-cd <app-directory>
-pnpm install
-```
-
-When working inside an existing Agent-Native workspace, create the app from
-the workspace root instead:
-
-```bash
-pnpm exec agent-native add-app <slug> --template=chat
-```
-
-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, 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
-explicitly asks to extend an existing app.
-
-Read the generated `DESIGN.md` before building the first screen and fill in the
-visual direction as part of the app brief. Do not copy the previous app's
-palette just because its tokens are nearby.
-
-## 3. Turn the workflow into buttons and agent work
-
-Implement the smallest useful surface around the extracted brief. The app
-should make the repeated path obvious without hiding the agent's judgment:
-
-- Give each important repeated moment a clear button, such as “Analyze,”
-  “Suggest options,” “Draft,” “Review,” or “Publish.” Use the source's actual
-  vocabulary when it is clear.
-- Put deterministic reads, writes, approvals, provider fetches, and publishing
-  in focused `actions/` with `defineAction`. The UI and agent must call the
-  same action surface.
-- If a workflow is framed as research, analysis, generation, recommendation,
-  or synthesis, start it in the AgentSidebar and let the agent orchestrate
-  those actions. Do not hide an AI-shaped multi-step workflow behind one
-  opaque action just because the implementation is deterministic.
-- Use application state for the current screen, selected item, and focused
-  object so the agent can see where the user is.
-- Use `sendToAgentChat({ message, context, submit: true, openSidebar: true })`
-  for intentional button-triggered agent work. Use `submit: false` when the
-  user should review or edit the proposed prompt in the AgentSidebar first.
-  Keep follow-up and revision prompts in that same thread; do not add a second
-  freeform textbox beside the result.
-- Pass IDs, URLs, and bounded summaries in context. Do not paste large provider
-  dumps into prompts, call an LLM directly from the browser, or invent fake
-  progress.
-- Make agent results visible, editable, retryable, and attributable. Keep
-  irreversible actions behind an explicit review or confirmation point.
-
-Use the existing shadcn/ui primitives, Tabler icons, shared composer, and
-optimistic action patterns. Do not add a parallel CRUD API route for an action.
-
-## 4. Keep onboarding shared
-
-Use the framework's existing setup experience. The app should offer the normal
-“Connect Builder” and “Add your own keys” paths for AI setup. Do not create a
-second credential form or hardcode a provider key.
-
-In local-development instructions, add a brief note that a developer can set
-an environment variable such as `ANTHROPIC_API_KEY` or `OPENAI_API_KEY` before
-starting the app; after restart, the setup prompt is no longer shown when the
-key is available. Keep real secrets out of source, examples, and generated
-content.
-
-Turn-into-app apps should commit an `agent-native.json` app configuration so a
-plain `pnpm dev` has the right first-run behavior without extra flags:
-
-```json
-{
-  "version": 1,
-  "onboarding": {
-    "firstRun": {
-      "development": "connect",
-      "production": "connect-and-integrations"
-    }
-  }
-}
-```
-
-`connect` keeps the Connect Builder / Add your own keys choice visible and
-skips only the generic “This app is an agent.” integrations catalog. The
-production value includes that catalog for a hosted app. Do not replace this
-with a local credential form or remove the shared onboarding. In development,
-the shared Connect Builder card also explains the deployment-level
-`ANTHROPIC_API_KEY` / `OPENAI_API_KEY` fallback and links to the full
-environment-variable guide.
-
-When the onboarding default needs code rather than a static mode map, add an
-optional `agent-native.config.ts` with the same returned shape:
-
-```ts
-import { defineAgentNativeConfig } from "@agent-native/core/config";
-
-export default defineAgentNativeConfig(({ isDev }) => ({
-  version: 1,
-  onboarding: {
-    firstRun: isDev ? "connect" : "connect-and-integrations",
-  },
-}));
-```
-
-The Vite preset loads this file automatically on supported Node versions. The
-JSON file remains the portable, inspectable fallback. See the [Agent-Native
-app configuration guide](/docs/agent-native-config) for precedence, supported
-modes, and the boundary between committed config and deployment secrets.
-
-For an account-free local preview, create the ignored local `.env` file with
-`AUTH_DISABLED=1` before starting the dev server. This is only for loopback
-development; never commit or deploy this setting. AI/provider connections still
-use the normal onboarding flow or the documented environment-variable keys.
-
-## 5. Run it immediately
-
-From the new app directory:
-
-```bash
-pnpm dev
-```
-
-For a fresh local test app, use the ignored `.env` with `AUTH_DISABLED=1` so the
-domain UI opens without an account; the committed app config makes shared
-onboarding visible. Keep the process running so the user can try the app. Read
-the actual server output and report the real local URL. If the app needs installation or a setup step,
-complete it when possible and distinguish “not configured” from an unavailable
-credential store.
-
-## 6. Verify, build, and deploy
-
-Exercise the actual happy path, not only the source files:
-
-1. Load the reported URL and confirm the main route renders.
-2. Confirm the shared onboarding state or a configured local key.
-3. Click the primary workflow button and confirm the intended agent handoff.
-   Also click every other AI-labeled button and confirm it opens the same
-   contextual sidebar with the expected prompt or staged context.
-4. Confirm the result, action persistence, application state, and sync path.
-5. Check the dev output for browser/runtime errors, and capture input, result,
-   and agent-sidebar states so the complete flow is reviewable.
-
-Then run the supported build. For a standalone app, use the generated app's
-documented build and hosting path. For an app inside a workspace, use the
-workspace deploy command, for example:
-
-```bash
-npx @agent-native/core@latest build
-npx @agent-native/core@latest deploy --preset netlify
-```
-
-Use `vercel` or another supported preset when that is the configured target.
-Attempt deployment when the user requested it or the project already has the
-required provider configuration. If external authentication, a production
-secret, or a hosting decision is missing, finish local verification and report
-the exact remaining handoff without claiming a live deployment.
-
-Label evidence separately: locally running, locally verified, build-ready,
-deployed, and live-verified are different states.
-
-## Handoff
-
-End with the new app directory, local URL, visual direction, what the buttons do,
-account-free local-preview status, verification performed, deployment URL if it is real,
-and one precise pending step when something could not be completed. Keep the
-handoff short enough to use in a demo or recording.

package/dist/templates/headless/.agents/skills/turn-into-app/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Turn Into App"
-  short_description: "Turn project context or a workflow into a runnable app"
-  default_prompt: "Use the visible project context first, then any supplied workflow. Turn the instructions, knowledge files, and selected successful runs into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

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

@@ -1,90 +0,0 @@
-# Fresh Project source guide
-
-Use this guide when `/turn-into-app` is invoked in a new Claude or ChatGPT
-Project rather than after a completed thread.
-
-## What the host can provide
-
-The source is whatever the host put in the model's current context:
-
-- Project instructions: the job, audience, constraints, quality bar, and
-  approved tools or integrations.
-- Knowledge files and attachments: reference material, templates, examples,
-  and links that the app should use.
-- Past runs: only conversations or outputs the host actually supplied. They
-  are examples and evaluation material, not an automatic import of every
-  private Project conversation.
-- The current request: the app boundary, target workspace, name, and explicit
-  corrections.
-
-Do not infer hidden system prompts, account settings, private history, API keys,
-or credentials. The Dispatch MCP connector can start a workspace app creation,
-but it cannot unlock or scrape private Project content.
-
-## Source brief
-
-Write a compact brief before starting the app:
-
-```text
-Source: host-provided Claude/ChatGPT Project context
-Provenance: project instructions, selected knowledge files, and visible runs
-Project goal:
-Configuration and constraints:
-Knowledge sources:
-Repeatable workflow:
-Inputs and outputs:
-Judgment and review points:
-Representative runs: none, or 1-3 selected examples
-Integrations and permissions:
-Unknowns and assumptions:
-```
-
-Keep source references bounded. Prefer a file name, URL, resource ID, or short
-summary over a large pasted document. Do not put secrets or raw customer data
-in the brief.
-
-## Fresh-box setup
-
-Install the exported `turn-into-app` skill in the host when the host supports
-skills. For a ChatGPT Project or any host that exposes only the MCP connector,
-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`.
-This single connector is enough: Dispatch provisions or reuses the Builder
-project through the Builder Projects API, so do not ask the user to add a
-separate Builder CMS MCP for app creation.
-Builder's separate Fusion MCP is available as a custom remote connector at
-`https://mcp.builder.io/mcp/fusion` for direct Builder work. It can run an
-existing project, but it cannot provision the repo-backed Agent-Native
-workspace project, so it is optional and not a replacement for the Dispatch
-handoff in this skill. Do not add Builder's CMS MCP for this workflow.
-
-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.
-
-The brief is an implementation authorization, not a questionnaire. After a
-repeatable workflow is identifiable, choose any source-recommended option
-automatically. For unresolved non-blocking choices, use the most direct
-conventional default, record it under assumptions, and continue. Ask only when
-there is no identifiable workflow, no authorized target workspace, or a
-destructive/credential boundary genuinely prevents the handoff.
-
-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 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
-and request an export or attachment. Do not claim that the Project was read.

package/dist/templates/headless/.agents/skills/turn-into-skill/SKILL.md

@@ -1,112 +0,0 @@
----
-name: turn-into-skill
-description: >-
-  Capture a proven thread or workflow as a reusable Agent-Native skill and save
-  it as a personal or organization resource. Use when a user invokes
-  `/turn-into-skill` or asks to save a workflow for reuse.
-user-invocable: true
-scope: both
-metadata:
-  internal: true
----
-
-# Turn Into Skill
-
-This is a packaging-and-save workflow, not a request for a proposal. A skill
-is the lightweight path for a repeatable job that mostly needs guidance and
-existing app actions. Use `turn-into-app` when the job needs a dedicated UI,
-new persistent domain state, or a distinct app route.
-
-## Default behavior
-
-- With no argument, use the current thread as the source.
-- With a named skill, local workflow, transcript path, or attachment, read that
-  source and package it immediately.
-- Do not ask the user to restate context already present in the source.
-- Default to a personal skill unless the user explicitly asks for a team,
-  organization, or all-app skill, or passes `shared` as the scope.
-- If the current thread only discusses creating a skill, do not package that
-  meta-workflow unless the user explicitly asks for it.
-- Treat an explicit `/turn-into-skill` invocation as authorization to save the
-  resulting skill, but never overwrite an existing skill at the target path
-  unless the user clearly asks to update it.
-
-## 1. Extract the repeatable workflow
-
-Read the full source before writing. Reduce it to a concise working brief:
-
-- the repeatable job and the user outcome;
-- when the skill should trigger;
-- required inputs, context, permissions, and integrations;
-- the ordered steps and the one to three judgment-heavy decisions;
-- expected outputs, verification, retry, and failure boundaries.
-
-Preserve the useful judgment from the source, not its transcript. Do not turn
-one-off answers, private data, customer data, secrets, or unverified claims into
-the skill's contract. If no repeatable job can be identified, stop and report
-what is missing instead of inventing generic guidance.
-
-## 2. Author the skill
-
-Create a single `SKILL.md` with:
-
-- a short hyphen-case name and a description under 40 words that says what the
-  skill does and when to use it;
-- `user-invocable: true` so it can be selected from the app's `/` picker;
-- `scope: both` so the saved skill can guide the app runtime and connected
-  coding agents;
-- concise sections for purpose, trigger, inputs, workflow, verification, and
-  failure or retry behavior.
-
-Write imperative, reusable instructions. Keep exact action names, field rules,
-and decision criteria when they matter. Use placeholders for credentials and
-provider data. Do not paste the source transcript, large dumps, or ephemeral
-thread details into the saved skill.
-
-Choose a new slug when the target path already exists. Read an existing skill
-before changing it, and update it only when the user explicitly requested an
-update.
-
-## 3. Save at the requested scope
-
-Skills are resources at `skills/<slug>/SKILL.md`.
-
-| User intent | Save path |
-| --- | --- |
-| Just me or personal reuse | Use the `resources` tool with `action: "write"`, `scope: "personal"`, `visibility: "workspace"`, and the generated skill content. |
-| Shared organization or app reuse | Use the `resources` tool with `action: "write"`, `scope: "shared"`, `visibility: "workspace"`, and the generated skill content. |
-| Every workspace app | Use `create-workspace-resource` with `kind: "skill"`, `scope: "all"`, the generated path, name, description, and content. |
-| Only selected apps | Use the workspace resource flow with `scope: "selected"` only when the user names the app set. |
-
-For an all-app workspace skill, use the workspace resource action when it is
-available. If the current app does not expose it, discover or delegate to the
-configured Dispatch workspace agent. Do not silently save a personal skill and
-report it as shared. If organization approval is queued, report that the skill
-is pending approval rather than claiming it is active.
-
-Set `visibility: "workspace"` for an explicitly requested saved skill. Use
-`agent_scratch` only for temporary drafting, then promote or rewrite it before
-reporting the skill as saved.
-
-## 4. Verify and hand off
-
-After saving, read the exact `skills/<slug>/SKILL.md` resource back at the
-target scope. Confirm that the frontmatter name, trigger description, and full
-workflow body are present. If the read-back fails or the save returned an
-approval request, say so plainly and include the actual pending state.
-
-Report:
-
-- the skill name and path;
-- whether it is personal, organization-wide, or selected-app;
-- the trigger users can invoke from `/`;
-- the verification result and any approval or setup still required.
-
-## Related skills
-
-- `turn-into-app` — package the same source as a UI-bearing app with buttons,
-  agent handoffs, and a domain workflow.
-- `create-skill` — general skill format and authoring rules.
-- `capture-learnings` — lightweight memory for preferences and corrections,
-  rather than reusable workflows.
-- `self-modifying-code` — safety boundaries when the agent edits app source.

package/dist/templates/headless/.agents/skills/turn-into-skill/agents/openai.yaml

@@ -1,4 +0,0 @@
-interface:
-  display_name: "Turn Into Skill"
-  short_description: "Save a proven workflow as a reusable skill"
-  default_prompt: "Read the current thread, distill the repeatable workflow into a concise user-invocable skill, save it at personal or organization scope, verify the saved resource, and report its path."