@agent-native/core 0.152.0 → 0.153.0

package/dist/templates/headless/.agents/skills/upgrade-agent-native/SKILL.md

@@ -1,127 +0,0 @@
----
-name: upgrade-agent-native
-description: >-
-  Bring an older Agent Native app or workspace current. Use when updating
-  @agent-native/core, fixing a broken upgrade, or when tempted to patch or
-  override core/dispatch packages to make an old branch run.
-scope: dev
-metadata:
-  internal: true
----
-
-# Upgrade Agent Native
-
-## Rule
-
-When an older Agent Native app/branch needs to run on current packages, use
-`agent-native upgrade`. Never "fix" upgrade breakage with
-`pnpm patch`, `pnpm patch-commit`, `pnpm.patchedDependencies`,
-`pnpm.overrides`, `patchedDependencies`, `resolutions`, local patch artifacts,
-or edits under `node_modules/@agent-native/*` — especially not against
-`@agent-native/core` or `@agent-native/dispatch`.
-
-## Why
-
-Agents often respond to a failed core bump by inventing framework patches and
-dispatch behavior overrides. That hides the real app-level break, drifts from
-upstream, and makes the next upgrade worse. The supported path is bump →
-install → refresh scaffold skills → verify, then fix **app** code only.
-
-## How
-
-1. **Preview migration codemods first**
-
-   ```bash
-   npx @agent-native/core@latest upgrade --codemods
-   ```
-
-   Codemods are preview-by-default: read the diff before applying it. Do not
-   manually edit imports before running this command; the migration manifest is
-   the source of truth for renamed specifiers and symbols.
-
-2. **Apply the reviewed codemods, then run the upgrade**
-
-   ```bash
-   npx @agent-native/core@latest upgrade --codemods --yes
-   npx @agent-native/core@latest upgrade
-   ```
-
-   Or from an already-installed CLI: `pnpm exec agent-native upgrade` /
-   `agent-native upgrade`.
-
-   What it does:
-
-   - Blocks (unless `--force`) when `@agent-native/*` overrides/patches exist
-   - Rewrites non-local `@agent-native/*` dependency pins to `latest`
-   - Runs the package manager install
-   - Rewrites those pins to the exact versions the install resolved, so the
-     committed manifest names one release instead of re-resolving next install
-   - Runs `skills update scaffold --project`
-   - Runs `typecheck` when the project has that script
-
-3. **Pull upstream template changes (optional, separate from the bump)**
-
-   `agent-native upgrade` moves package versions. It never touches files that
-   were copied out of a template at scaffold time, so template fixes and
-   improvements do not arrive with a bump.
-
-   ```bash
-   agent-native template status        # recorded ref vs latest, drift counts
-   agent-native template diff          # what upstream changed, read-only
-   agent-native template sync          # 3-way merge it into the app
-   ```
-
-   `sync` defaults to the ref matching the installed `@agent-native/core`, so
-   run it after `upgrade`. It merges per file against a pristine baseline
-   stored in `refs/agent-native/template-baseline/<app-path>`; files upstream
-   did not touch are left alone, and real collisions get conflict markers.
-   After resolving markers, run `agent-native template accept` — the baseline
-   deliberately does not advance past an unresolved merge.
-
-   Apps scaffolded before provenance existed have no baseline. Create one
-   with `agent-native template baseline` before the first sync.
-
-4. **If upgrade or typecheck fails**
-
-   - Read the concrete error
-   - Fix **app** source, actions, config, or env — not framework packages
-   - Re-run `agent-native upgrade` or `pnpm typecheck`
-   - Stop and ask the user if you cannot fix the app-level error
-
-   Intentional app-level UI customization is a separate workflow. Read
-   `customizing-agent-native` when the product needs to own a selectively
-   copied component; do not use that path to reproduce framework runtime
-   behavior or hide version skew.
-
-5. **Dry-run / partial runs**
-
-   ```bash
-   agent-native upgrade --dry-run
-   agent-native upgrade --skip-verify
-   agent-native upgrade --skip-install   # package.json bumps only
-   agent-native doctor --only migration-manifest
-   ```
-
-   `migration-manifest` has no opt-out. Run it in CI before upgrading to find
-   imports that will break, then use `npx @agent-native/core@latest upgrade --codemods`
-   to preview the supported rewrite.
-
-## Don't
-
-- Don't add `pnpm.overrides`, `overrides`, `resolutions`, or
-  `patchedDependencies` for any `@agent-native/*` package
-- Don't run `pnpm patch` or `pnpm patch-commit`, or commit files under
-  `patches/`, for any dependency
-- Don't edit `node_modules/@agent-native/core` or
-  `node_modules/@agent-native/dispatch`
-- Don't invent local "dispatch behavior" shims to paper over version skew
-- Don't keep iterating with more framework patches after a failed install
-- Don't skip `skills update scaffold --project` after a core bump (the
-  upgrade command does this for you)
-
-## Related Skills
-
-- **self-modifying-code** — Tier 4: framework packages are off limits
-- **agent-native-docs** — version-matched docs after the bump
-- **customizing-agent-native** — intentional app-owned UI copies, not upgrade patches
-- **portability** — keep app code provider-agnostic across upgrades

package/dist/templates/workspace-core/.agents/skills/a2a-protocol/SKILL.md

@@ -1,411 +0,0 @@
----
-name: a2a-protocol
-description: >-
-  How agent-native apps discover, authenticate with, and call each other over
-  A2A. Use when connecting one app to another, debugging a remote agent that
-  won't authenticate, exposing skills to peers, or calling agents from scripts.
-scope: dev
-metadata:
-  internal: true
----
-
-# A2A Protocol (Agent-to-Agent)
-
-## Rule
-
-Agents call other agents over A2A, a JSON-RPC protocol for discovery and
-delegation. Use it when work belongs to a different agent entirely — not the
-local agent chat.
-
-**No workarounds when A2A feels flaky.** The strong default is `ask_app` (or
-`call-agent`) working reliably, full stop — not apps reaching around it. Do
-not have app A generate and execute raw SQL against app B's database, and do
-not expose B's internal tools directly to A as a substitute for delegation.
-The receiving agent has context, skills, and guardrails the caller doesn't;
-bypassing it to work around a flaky A2A call reintroduces exactly the bugs A2A
-exists to prevent, and makes the real reliability problem invisible instead of
-fixing it. If A2A delegation is unreliable, fix A2A — file it as a bug in the
-delegation path (timeout handling, retries, typed terminal states), don't
-route around it app by app.
-
-Connecting app A to app B is two independent things, and both must be true:
-
-1. **B is registered on A** as a `remote-agents/<id>.json` resource.
-2. **A and B share a secret**, so A's signed JWT verifies on B.
-
-Neither is a code change, and neither is symmetric. Registering B on A does not
-let B call A.
-
-## A2A is already mounted
-
-`createAgentChatPlugin` calls `mountA2A` for every app, so a generated app
-already serves:
-
-- `GET /.well-known/agent-card.json` — public discovery, never authenticated
-- `POST /_agent-native/a2a` — JSON-RPC, authenticated
-
-Do not add a `mountA2A` server plugin to enable A2A; it is on. Hand-mounting is
-only for a bespoke card or a custom handler (see **Custom mount** below).
-
-The client falls back to `POST /a2a` for external peers that only expose that
-path. New agent-native apps should call `/_agent-native/a2a`.
-
-## Registering a remote agent
-
-A remote agent is **a row in the resources table, not a file on disk**. Path
-`remote-agents/<id>.json`, owner `SHARED_OWNER`, content:
-
-```json
-{
-  "id": "analytics",
-  "name": "Analytics",
-  "description": "Queries analytics data across providers",
-  "url": "https://analytics.example.com",
-  "color": "#6B7280"
-}
-```
-
-`url` is the only required field. `parseRemoteAgentManifest` accepts **only**
-these five keys — there is no `apiKey`, `env`, `skills`, or `token` field, and
-anything else is silently dropped.
-
-Four ways to create it, all writing the same row:
-
-| Surface | Where |
-| --- | --- |
-| Settings → Manage agent → Connected Agents (A2A) | any app with the settings panel |
-| Agent page → Connections | apps mounting `AgentTabsPage` |
-| Dispatch → Agents → Add external agent | workspace dispatch |
-| The agent itself | `resources` tool, `action: "write"`, `--scope shared` |
-
-The last one matters for template apps with no Code tab: "connect me to
-https://analytics.example.com" is a complete instruction. `remote-agents/` is
-whitelisted as a durable control path, so the write is workspace-scoped, and it
-takes effect on the next `discoverAgents()` call with no restart.
-
-First-party templates are seeded automatically and overlaid on top of manifests,
-so `Mail`, `Calendar`, and friends appear without registration. In dev they
-resolve to `http://localhost:<devPort>`; a manifest pointing at localhost is
-ignored in production.
-
-`call-agent` also accepts a raw URL, which skips registration entirely — useful
-for one-off calls, useless for @-mentions.
-
-### Checking a peer
-
-`GET /_agent-native/agents/probe?url=<base>` reads the peer's card and makes one
-authenticated no-op call, returning `reachable` and `authorized` as independent
-fields. Omit `url` to probe every registered peer. Reachable-but-unauthorized is
-the failure worth looking for: local dev runs the receiver unauthenticated, so a
-mismatched secret only surfaces after deploy. The Connected Agents settings
-section calls this on add and on open.
-
-## Authentication
-
-A2A authenticates with a **short-lived JWT the caller signs**, not a stored
-bearer key. `Authorization: Bearer <jwt>`; claims carry the caller's email and
-org domain; HS256; 15-minute default TTL. There is no per-peer API key
-anywhere in the system, which is why the manifest has no field for one.
-
-Two secrets can sign it:
-
-| Secret | Scope | How it is set |
-| --- | --- | --- |
-| `A2A_SECRET` | whole deployment | env var, **never auto-generated** |
-| org `a2a_secret` | one organization | auto-generated on org creation; Team page UI |
-
-The org secret is the managed path: **Team page → A2A secret** (owner only)
-reveals, copies, regenerates, and pushes it to every discovered peer. Rotation
-is tolerated — the caller tries both secrets in order and sticks to whichever
-worked.
-
-`A2A_SECRET` is the deploy-level path. `workspace-deploy` refuses a production
-workspace deploy without it and prints the generator command. Peers that must
-trust each other need the *same* value on both sides.
-
-With no secret configured at all:
-
-| Runtime | Result |
-| --- | --- |
-| local dev | open, one-time console warning |
-| production | `503` — "A2A authentication not configured" |
-| production, secret set, bad/absent token | `401` |
-
-"Production" is detected broadly (NODE_ENV, Netlify, Lambda, Vercel, Render,
-Fly, Cloud Run, …) and unrecognized deployed hosts fail closed unless the
-request is genuine loopback or `A2A_ALLOW_UNSIGNED_INTERNAL=1`.
-
-`A2AConfig.apiKeyEnv` still exists for static bearer auth against non-agent-native
-peers, but the framework's own mount never sets it. Do not reach for it when
-debugging a connection between two agent-native apps — the answer there is
-always the shared secret.
-
-Never hardcode either secret in source, docs, prompts, app state, action
-descriptions, client bundles, or examples. Read them from runtime config; never
-log or return them.
-
-## Advertising what this agent can do
-
-Card `skills` are derived from actions marked `publicAgent`. An app that marks
-none publishes `"skills": []`, but natural-language delegation still works
-because the receiving agent loads its own instructions, skills, data
-dictionary, credentials, and tools. Mark only stable machine contracts that a
-peer may intentionally invoke directly; leave implementation actions internal.
-
-## Calling another agent
-
-Natural-language delegation is the default for agent-to-agent work. Tell the
-receiving specialist the objective, relevant IDs/date range, and desired result
-shape. The receiver owns source selection, schemas, queries, joins, SQL, and
-provider-specific details. Do not switch to a direct action merely because a
-delegated run is slow or flaky; fix the A2A path instead.
-
-### Simple: `callAgent()` (text in, text out)
-
-```ts
-import { callAgent, resolveA2ACallerAuth } from "@agent-native/core/a2a";
-
-const auth = await resolveA2ACallerAuth();
-const answer = await callAgent(
-  "https://analytics.example.com",
-  "What were last week's signups?",
-  auth,
-);
-// answer is a plain string
-```
-
-`callAgent` signs nothing on its own — with no `userEmail`/`orgSecret` in opts
-it calls **unauthenticated**, which silently works in local dev and 401s in
-production. `resolveA2ACallerAuth()` pulls the authenticated email, org domain,
-and org secret out of request context; pass them explicitly only from CLI or
-cron, where there is no request.
-
-### Explicit machine-contract exception: `invokeAgentAction()`
-
-Use direct invocation only when a trusted integration already specifies the
-exact receiver-owned semantic read action and complete arguments. It is an
-optional machine API, not an agent-performance shortcut or fallback for failed
-message delegation:
-
-```ts
-import { invokeAgentAction } from "@agent-native/core/a2a";
-
-const { result } = await invokeAgentAction({
-  target: "analytics",
-  action: "gong-calls",
-  input: { company: "Acme", days: 90, includeTranscripts: true },
-  userEmail,
-  orgDomain,
-  orgSecret,
-});
-```
-
-The receiver still owns schema validation, credentials, access scoping, audit
-attribution, and exposure policy. Direct invocation is available only for
-cataloged, authenticated, explicitly exposed read-only actions that do not
-require approval. Its JWT is audience-bound to the receiving app. Use normal
-message delegation whenever the receiver must interpret the request, choose a
-source, consult its data dictionary, plan, synthesize, join data, or perform a
-multi-step workflow.
-
-Inside an agent loop, `call-agent` exposes the same path with `action` + `input`;
-omit `message` and `taskId` in that mode.
-
-### Retry safety and trace linkage
-
-`call-agent` automatically derives an owner-scoped idempotency key from the
-originating turn, target, and exact message. If a retry reaches the receiver
-after the caller timed out, asynchronous `message/send` returns the existing
-active or completed task instead of starting a duplicate agent run. Failed and
-canceled tasks release the key for an intentional retry; synchronous calls are
-never deduplicated. Lower-level clients may pass an
-`idempotencyKey` explicitly; keep it stable for the same logical submission and
-change it when the work changes. Dedupe is scoped to the JWT-authenticated
-owner and verified org, and keys are limited to 128 characters.
-
-The caller also forwards bounded correlation metadata (`callerApp`,
-`callerThreadId`, `parentRunId`, `parentTurnId`, and direct-read
-`invocationId`). These fields
-are telemetry hints only. Receivers must continue to derive identity,
-ownership, org scope, access, and approval from the verified request context.
-Delegated model loops emit `$ai_generation` with A2A/MCP lineage, while direct
-reads emit the content-free `$a2a_read_invoke` event; neither event includes
-action arguments or results.
-
-### Advanced: `A2AClient` (full control)
-
-```ts
-import { A2AClient, resolveA2ACallerAuth } from "@agent-native/core/a2a";
-
-// The second argument is the bearer token itself, not a signing secret.
-const { apiKey, apiKeyFallbacks } = await resolveA2ACallerAuth();
-const client = new A2AClient("https://analytics.example.com", apiKey, {
-  fallbackApiKeys: apiKeyFallbacks,
-});
-
-// Discover agent capabilities
-const card = await client.getAgentCard();
-
-// Send a message and get a task back
-const task = await client.send({
-  role: "user",
-  parts: [{ type: "text", text: "What were last week's signups?" }],
-});
-// task.status.state === "completed"
-// task.status.message.parts[0].text === "Last week: 1,247 signups..."
-
-// Stream responses
-for await (const update of client.stream({
-  role: "user",
-  parts: [{ type: "text", text: "Detailed breakdown by day" }],
-})) {
-  console.log(update.status.state, update.status.message);
-}
-```
-
-### Agent activity in delegated chat
-
-Agent Native peers attach a bounded `data` part with
-`kind: "agent-native/agent-activity"` to in-progress and terminal task status
-messages. It contains the same user-visible reasoning summaries shown in the
-receiving app, tool names and completion states, elapsed time, and progressive
-response text. It never includes tool inputs, tool results, credentials, or
-hidden provider reasoning.
-
-`call-agent` reads this optional part while it polls an asynchronous task and
-renders the remote work as a nested agent run. Unknown A2A peers do not need to
-implement the extension: their ordinary status and final text still render in
-the same nested block. Treat activity data as untrusted presentation content;
-never use it for identity, authorization, approval, routing, or artifact
-validation.
-
-### Carrying explicit chat authorization
-
-When the authenticated caller has an exact consequential action that the user
-explicitly authorized in the originating chat, pass the tool name and complete
-input as `approvedActions`. The receiver accepts these grants only from a
-JWT-verified user identity, converts each one to the same content-addressed key
-as its local approval gate, and consumes it once:
-
-```ts
-await client.send(message, {
-  async: true,
-  approvedActions: [
-    {
-      tool: "send-email",
-      input: { to, subject, body, attachments },
-    },
-  ],
-});
-```
-
-Never infer authorization from request prose or broaden the input. A changed
-recipient, body, attachment, or tool produces a different key and follows the
-receiver's normal approval-required path. Static API keys and unsigned callers
-cannot carry these grants.
-
-## JSON-RPC Methods
-
-| Method           | Purpose                          | Auth required |
-| ---------------- | -------------------------------- | ------------- |
-| `message/send`   | Send a message, get a task back  | Yes           |
-| `message/stream` | Send a message, stream responses | Yes           |
-| `actions/invoke` | Invoke one exposed read action   | Yes, JWT      |
-| `tasks/get`      | Get task status by ID            | Yes           |
-| `tasks/cancel`   | Cancel a running task            | Yes           |
-
-## Task Lifecycle
-
-Tasks go through these states:
-
-```
-submitted → working → completed
-                    → failed
-                    → canceled
-                    → input-required
-```
-
-- **submitted** — message received, not yet processing
-- **working** — agent is processing the request
-- **completed** — agent finished, result in `status.message`
-- **failed** — agent encountered an error
-- **canceled** — task was canceled via `tasks/cancel`
-- **input-required** — agent needs more information from the caller
-
-## Message Parts
-
-Messages contain typed parts:
-
-| Part type | Fields                              | Use for                    |
-| --------- | ----------------------------------- | -------------------------- |
-| `text`    | `{ type: "text", text: "..." }`     | Natural language messages  |
-| `file`    | `{ type: "file", file: { ... } }`   | Files (bytes or URI)       |
-| `data`    | `{ type: "data", data: { ... } }`   | Structured JSON data       |
-
-## Custom mount
-
-Only when the default card is wrong for the app — a curated skill list, a
-non-agent handler, or static bearer auth against an external peer:
-
-```ts
-// server/plugins/a2a.ts
-import { mountA2A } from "@agent-native/core/a2a";
-
-export default defineNitroPlugin((nitro) => {
-  mountA2A(nitro, {
-    appId: "analytics",
-    name: "Analytics Agent",
-    description: "Queries analytics data across providers",
-    skills: [
-      {
-        id: "query-data",
-        name: "Query Data",
-        description: "Run analytics queries across connected data sources",
-        tags: ["analytics", "data"],
-        examples: ["What were last week's signups?", "Show conversion rates"],
-      },
-    ],
-    streaming: true,
-  });
-});
-```
-
-Config also carries `handler`, `publicSkillsOnly`, `durableBackgroundRuns`,
-`executeReadOnlyAction`, `executeApproval`, and `apiKeyEnv`. See `A2AConfig` in
-`@agent-native/core/a2a` for the full shape.
-
-## All Types
-
-All types are exported from `@agent-native/core/a2a`:
-
-```ts
-import type {
-  A2AConfig,
-  A2AHandler,
-  A2AHandlerContext,
-  A2AHandlerResult,
-  AgentCard,
-  AgentSkill,
-  AgentCapabilities,
-  Task,
-  TaskState,
-  TaskStatus,
-  Message,
-  Part,
-  TextPart,
-  FilePart,
-  DataPart,
-  Artifact,
-  JsonRpcRequest,
-  JsonRpcResponse,
-} from "@agent-native/core/a2a";
-```
-
-## Related Skills
-
-- **delegate-to-agent** — For work the local agent handles. Use A2A when the work goes to a different agent.
-- **authentication** — Org creation, membership, and where the org secret lives.
-- **actions** — A2A calls typically happen inside actions; `publicAgent` marks what peers can see.
-- **storing-data** — Results from A2A calls are stored in SQL like any other data.
-</content>
-</invoke>

package/dist/templates/workspace-core/.agents/skills/adding-workspace-apps/SKILL.md

@@ -1,107 +0,0 @@
----
-name: adding-workspace-apps
-description: >-
-  How to add an app to an Agent Native workspace: classifying an "agent"
-  request, scaffolding `apps/<app-name>`, app discovery and descriptions,
-  mounting and base paths, action-first data, and finishing a chat-template app.
-  Use when asked to create, build, scaffold, or generate a new agent or app in a
-  workspace.
-scope: dev
----
-
-# Adding Workspace Apps
-
-## Classify The Ask First
-
-When a user asks from Dispatch chat or through `@agent-native` in Slack or
-Telegram to create, build, make, scaffold, or generate an "agent", classify
-the ask first.
-Simple Dispatch-native behavior such as a reminder, digest, monitor, routing
-rule, saved instruction, or recurring workflow can stay in Dispatch as a
-recurring job/resource/destination. Robust unique products or teammates that
-need their own UI, data model, actions, integrations, or domain workflow should
-become a separate workspace app under `apps/<app-name>`, mounted at
-`/<app-name>`.
-
-## Where The App Lives
-
-Do not implement a new app by adding a route, page, component, or file to
-`apps/chat` or another existing app unless the user explicitly asks to modify
-that existing app.
-
-## Vault Access
-
-Dispatch vault access is workspace-wide by default: every saved vault key is
-available to every workspace app. Only create or request per-app vault grants
-when Dispatch's vault access setting is switched to manual mode.
-
-When an app needs a provider credential, use the app's scoped secret or
-workspace-connection resolver so Dispatch remains the source of truth. Do not
-ask a non-admin builder to add a key to local project settings or `.env`; use
-Dispatch's vault request workflow for a missing key and keep the value out of
-app code.
-
-## Discovery, Links, And The UI Stack
-
-Workspace apps are discovered from `apps/<app-name>/package.json`. There is no
-separate workspace app registry to edit for Dispatch to list the app. Always
-save a concise, human-readable `description` there; Dispatch lists and A2A
-connected-agent context use the app name plus description so agents know what
-the app does. Use relative workspace links like `/<app-name>` and never
-hardcode `localhost`, `127.0.0.1`, `8080`, `8100`, or any dev port in app
-cards, instructions, redirects, or navigation; the active workspace
-gateway/browser origin owns the port. React Router apps must preserve
-`APP_BASE_PATH` / `VITE_APP_BASE_PATH` in
-`app/entry.client.tsx` via `appBasePath()` so the app hydrates correctly when
-mounted at `/<app-name>`. Use the framework/template UI stack for standard UI:
-shadcn/ui components and `@tabler/icons-react`. Do not add `lucide-react` or
-another icon library. Read `.agents/skills/shadcn-ui/SKILL.md` before adding,
-updating, or debugging shadcn components.
-
-## App Data Goes Through Actions
-
-Normal app data must flow through actions. For CRUD that the agent can perform,
-create `defineAction` files in `actions/`, mark reads with
-`http: { method: "GET" }`, and call them from React with `useActionQuery` /
-`useActionMutation`. Do not add duplicate JSON CRUD routes under `/api/*` for
-the same data unless the route is for uploads, streaming, webhooks, OAuth, or
-another route-only concern. Do not add routes whose main job is to wrap,
-proxy, or re-export an action; the action endpoint already exists at
-`/_agent-native/actions/:name`. Action-backed UI is what makes agent-created or
-agent-edited records appear without a manual refresh.
-
-## Database Portability
-
-App database code must be provider-agnostic. Define schemas with
-`@agent-native/core/db/schema` helpers and write app reads/writes with Drizzle's
-query builder and portable `drizzle-orm` operators. Do not import from
-`drizzle-orm/sqlite-core` or `drizzle-orm/pg-core` in app templates. Keep raw SQL
-for additive migrations, health checks, or carefully scoped maintenance, and
-never write SQLite-only or Postgres-only product code. Do not use SQL as object
-storage; file bytes belong in upload/private-blob providers with only references
-saved to app tables.
-
-## Scaffolding
-
-In local development, run
-`pnpm exec agent-native create <app-name> --template=<template>` from the
-workspace root. In production, Dispatch posts new-app requests to Builder
-branch creation; Builder should still scaffold the separate workspace app. The
-workspace dev gateway (`pnpm dev`) detects new `apps/<app-name>` directories
-automatically.
-
-## Finishing A Chat-Template App
-
-When using the chat template, treat it as scaffolding only. The finished app
-must be branded as the requested app, with its own home screen, navigation,
-package metadata, manifest, and domain workflow. Do not leave visible
-`Chat`, `Starter`, `Blank app`, `Start building`, or `New app` UI in a chat-derived
-app.
-
-## Related Skills
-
-- **workspace-conventions** — Shared workspace rules this workflow assumes.
-- **actions** — How to define the app operations the agent and UI share.
-- **composable-mini-apps** — Splitting work across focused sibling apps.
-- **portability** — Keeping database and hosting assumptions provider-agnostic.
-- **shadcn-ui** — Adding and upgrading the UI primitives.