@agent-native/core 0.141.6 → 0.144.0

package/corpus/templates/brain/app/routes/sources.tsx

@@ -105,6 +105,10 @@ import {
   sourceReviewRequired,
   sourceType,
 } from "@/lib/brain";
+import {
+  dispatchIntegrationsHref,
+  getDispatchHref,
+} from "@/lib/dispatch-links";
 import {
   createOneTimeIngestHandoff,
   type OneTimeIngestHandoff,
@@ -418,11 +422,6 @@ function isSourceProvider(providerId: string): providerId is Provider {
   return providers.some((provider) => provider.value === providerId);
 }
 
-function dispatchIntegrationsHref(providerId: string) {
-  const params = new URLSearchParams({ provider: providerId, appId: "brain" });
-  return `/dispatch/integrations?${params.toString()}`;
-}
-
 function grantStateLabel(state: BrainWorkspaceConnectionGrantState, t: BrainT) {
   switch (state) {
     case "connected":
@@ -1045,11 +1044,13 @@ function ProviderCatalog({
   providers: connectionProviders,
   loading,
   workspaceError,
+  dispatchHref,
   onAddSource,
 }: {
   providers: BrainConnectionProvider[];
   loading: boolean;
   workspaceError?: string | null;
+  dispatchHref: string;
   onAddSource: (provider: Provider) => void;
 }) {
   const t = useT();
@@ -1122,7 +1123,8 @@ function ProviderCatalog({
                 provider.providerHealth?.status === "unhealthy" ||
                 provider.providerHealth?.status === "missing_credentials");
             const providerSetupHref =
-              provider.setupLink ?? dispatchIntegrationsHref(provider.id);
+              provider.setupLink ??
+              dispatchIntegrationsHref(provider.id, dispatchHref);
             return (
               <div
                 key={provider.id}
@@ -1411,7 +1413,11 @@ function ProviderCatalog({
                   </Button>
                   {grantState === "needs_grant" || providerNeedsSetup ? (
                     <Button size="sm" variant="outline" asChild>
-                      <a href={providerSetupHref}>
+                      <a
+                        href={providerSetupHref}
+                        target="_blank"
+                        rel="noopener noreferrer"
+                      >
                         <IconExternalLink className="size-4" />
                         {grantState === "needs_grant"
                           ? t("sources.grantInDispatch")
@@ -1734,6 +1740,7 @@ function SourceListItem({
 
 export default function SourcesRoute() {
   const t = useT();
+  const dispatchHref = getDispatchHref();
   const [params, setParams] = useSearchParams();
   const type = params.get("type") ?? "all";
   const [advancedOpen, setAdvancedOpen] = useState(false);
@@ -2149,6 +2156,7 @@ export default function SourcesRoute() {
             <ProviderCatalog
               providers={connectionProviders}
               loading={connectionProvidersQuery.isLoading}
+              dispatchHref={dispatchHref}
               workspaceError={
                 connectionProvidersQuery.data?.workspaceConnections?.error ??
                 null

package/corpus/templates/brain/app/routes/team.tsx

@@ -7,5 +7,5 @@ export function meta() {
 }
 
 export default function TeamRoute() {
-  return <Navigate to="/settings#organization" replace />;
+  return <Navigate to="/settings/organization" replace />;
 }

package/corpus/templates/brain/app/routes.ts

@@ -8,7 +8,7 @@ export default [
   route("review", "./routes/review.tsx"),
   route("sources", "./routes/sources.tsx"),
   route("ops", "./routes/ops.tsx"),
-  route("settings", "./routes/settings.tsx"),
+  route("settings/*", "./routes/settings.tsx"),
   route("team", "./routes/team.tsx"),
   route("extensions", "./routes/extensions.tsx", [
     index("./routes/extensions._index.tsx"),

package/corpus/templates/brain/changelog/2026-08-06-brain-provider-setup-links-open-dispatch-correctly-in-standa.md

@@ -0,0 +1,6 @@
+---
+type: fixed
+date: 2026-08-06
+---
+
+Brain provider setup links open Dispatch correctly in standalone and workspace deployments.

package/corpus/templates/brain/server/plugins/agent-chat.ts

@@ -62,6 +62,7 @@ Important rules:
 - Company-tier knowledge may create a proposal instead of publishing immediately, depending on settings.
 - Slack and Granola sources are configurable v1 connectors. Generic capture and transcript import are always available.
 - Source/read actions are convenience readers, not provider capability limits. Before any provider API request, call list-connection-providers and inspect the matching provider. If configured is not true, do not attempt the request; explain that the connection needs setup or repair and include setupLink. Jira is queried on demand through the provider API rather than indexed as a Brain source. For ad hoc provider analysis that needs an endpoint, filter, payload, pagination mode, or API version not modeled by a Brain action, call provider-api-catalog/provider-api-docs, then provider-api-request against the provider's real HTTP API. Use connectionId for a specific shared grant and accountId for a specific OAuth account.
+- Analytics owns live HubSpot, Gong, CRM, call, pipeline, and provider-backed analytics questions. For those requests, use describe-workspace-apps when needed and delegate a bounded task with call-agent so Analytics chooses the provider, credentials, and query shape. Do not duplicate Analytics provider queries in Brain. If shared access is unavailable, include the absolute setupLink and mention the personal MCP option when the chat offers it; personal MCP connections are user-scoped and do not require workspace-admin privileges.
 - For broad searches, joins, classification, source-corpus counts, or absence claims across provider records, fetch every relevant page or an explicitly bounded cohort, stage/save large responses with stageAs/saveToFile/fetchAllPages, then use query-staged-dataset or run-code to reduce the corpus. Report source, filters, row counts, pagination, truncation, and gaps.`,
   a2aMessageFallback: async ({ text }) => tryAnswerBrainA2AQuestion(text),
   mentionProviders: async () => {

package/corpus/templates/calendar/.agents/skills/event-management/SKILL.md

@@ -15,6 +15,12 @@ Create, search, list, update, and delete calendar events. Events come from the G
 
 **Events live in Google Calendar, not SQL.** Never use `db-query` or `db-exec` to work with events. Always use the dedicated scripts which query the Google Calendar API directly.
 
+Event detail panels and popovers expose `calendar.event-detail.bottom` as an
+`ExtensionSlot` with `slotContext` containing the event id, title, times,
+timezones, location, attendees, and account email. Use the first-party
+attendee-timezone UI or a source edit for adornments next to guest rows; the
+slot does not inject per-row UI.
+
 ## Scripts
 
 ### list-events
@@ -232,6 +238,25 @@ Update an existing Google Calendar event. Use the event `id` from `list-events`,
 `search-events`, or `get-event`. Always preserve the event's `accountEmail` on
 the update so multi-account calendars use the right connected account.
 
+To move an existing event between connected Google account calendars, pass its
+current account as `--accountEmail` and the destination account as
+`--targetAccountEmail`:
+
+```bash
+pnpm action update-event \
+  --id google-event-id \
+  --accountEmail work@example.com \
+  --targetAccountEmail personal@example.com
+```
+
+The action creates a copy on the destination account and deletes the source
+event. It preserves the supported event fields and creates a fresh Google Meet
+when the original has one. Do not combine a calendar move with other event
+field changes. If guests are present, pass `--sendUpdates all` or
+`--sendUpdates none` explicitly when the desired notification behavior matters.
+Moving an entire recurring series is not supported; use `--scope single` for
+one occurrence.
+
 ```bash
 pnpm action update-event --id google-event-id --accountEmail secondary@example.com --title "New title"
 pnpm action update-event --id google-event-id --start 2026-04-03T10:00:00 --end 2026-04-03T10:30:00
@@ -385,6 +410,7 @@ When the user says:
 | "schedule a meeting"                           | `create-event --title ... --start ... --end ...`                             |
 | "draft an invite"                              | `manage-event-draft --action create --title ... --start ... --end ...`       |
 | "schedule a Zoom meeting"                      | `create-event --title ... --start ... --end ... --addZoom=true`              |
+| "move an event to another connected calendar"   | `update-event --id ... --accountEmail ... --targetAccountEmail ...`         |
 | "move/rename/update a meeting"                 | `update-event --id ...`                                                      |
 | "add Zoom to this meeting"                     | `update-event --id ... --addZoom=true`                                       |
 | "delete/remove a meeting"                      | `delete-event --id ...`                                                      |

package/corpus/templates/calendar/.agents/skills/turn-into-app/SKILL.md

@@ -0,0 +1,296 @@
+---
+name: turn-into-app
+description: >-
+  Turn 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.
+user-invocable: true
+scope: both
+metadata:
+  internal: true
+---
+
+# Turn Into App
+
+## Default behavior
+
+This is an end-to-end build skill, not a request for an app proposal.
+
+- With no argument, use the current thread as the source. This is the normal
+  invocation at the end of a successful 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, keep the current thread as the source
+  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 the current Codex 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.
+
+ChatGPT shared-conversation import and Claude web conversation/project import
+are **coming soon**. Do not claim private web access, invent an importer, add
+fake OAuth, or scrape a logged-in page without an explicit supported adapter.
+If a user gives one of those URLs before an adapter exists, ask for an export or
+transcript instead and treat it 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.
+
+## 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.
+- Use a sans-first SaaS hierarchy for the app shell. Choose a named visual
+  direction in `DESIGN.md` before styling: product mode, audience, palette
+  family, type treatment, composition, shape language, and anti-references.
+  One restrained editorial cue is welcome, but warm beige plus terracotta is
+  not the default and serif type belongs in content previews or a deliberate
+  brand moment rather than the whole tool.
+- Preserve existing brand tokens. For a new unbranded app, choose a
+  product-fitting palette family and compare sibling apps before reusing their
+  accent. Keep shared semantic tokens and Agent-Native behavior consistent
+  while varying the visual world, density, composition, and shape language.
+- Give the AgentSidebar a subtle surface or divider boundary so it is visually
+  distinct from the domain page without becoming a heavy panel wall.
+- Every AI-labeled button must actually call `sendToAgentChat` with bounded
+  context and `openSidebar: true`. Keep `submit: true` for direct execution and
+  `submit: false` only when the user should edit the staged prompt first. Label
+  deterministic local actions as local, preview, or analyze instead of AI.
+- 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.
+- 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.
+- 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.
+- Before handoff, inspect the first viewport for text density, repeated cards,
+  unrelated forms, and generic helper copy. Remove what the user does not need
+  until the next decision.
+- Run a `distill`, `typeset`, `colorize`, `layout`, `polish`, and `audit` pass
+  as useful named reviews. Make one intervention at a time and commit the
+  chosen direction rather than averaging several options into generic SaaS.
+- For before/after or original/generated review, stack the source first and the
+  result second by default. Reserve side-by-side layouts for short content that
+  remains comfortable to scan at the target width.
+
+## 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.
+
+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, and publishing in `actions/`
+  with `defineAction`. The UI and agent must call the same action surface.
+- 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 })` for intentional
+  button-triggered agent work. Use `submit: false` when the user should review
+  or edit the proposed prompt first.
+- 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/corpus/templates/calendar/.agents/skills/turn-into-app/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Turn Into App"
+  short_description: "Turn a thread or skill into a runnable app"
+  default_prompt: "Scan the current thread, turn the workflow into a new Agent-Native app with clear buttons, run it locally, verify it, and complete the deployment handoff."

package/corpus/templates/calendar/.agents/skills/turn-into-skill/SKILL.md

@@ -0,0 +1,112 @@
+---
+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/corpus/templates/calendar/.agents/skills/turn-into-skill/agents/openai.yaml

@@ -0,0 +1,4 @@
+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."

package/corpus/templates/calendar/AGENTS.md

@@ -44,10 +44,8 @@ ladder.
   version matters, use `provider-api-catalog`, `provider-api-docs`, and
   `provider-api-request` against the real provider API instead of weakening the
   answer around a narrow action.
-- For relationship-history searches, prefer raw Google Calendar API calls via
-  `provider-api-request` so the agent controls `calendarId`, `timeMin`,
-  `timeMax`, `q`, `maxResults`, and pagination. For large scans, stage results
-  with `stageAs` and analyze them with `query-staged-dataset`.
+- For relationship-history searches, use `provider-api-request`; stage large
+  scans with `stageAs` and analyze them with `query-staged-dataset`.
 - For Google Calendar, distinguish an empty calendar from missing auth,
   reauth-needed, or fetch failures.
 - `list-events` returns the UI-compatible list by default and the compact
@@ -55,35 +53,14 @@ ladder.
   `sourceCoverage`, and `coverageComplete` fields — a partial source failure is
   not an empty calendar. See `event-management` for the formats and the
   `accountEmails` rules.
-- Treat Google Calendar working locations as native status events, never as
-  generic all-day events. See `event-management` for
-  `workingLocationProperties`, single-occurrence scope, and the working-hours
-  limitation.
-- Full-day out-of-office creation uses inclusive human dates plus an IANA
-  timezone. `create-event` translates them to local-midnight timed bounds and
-  sends provider `allDay: false`; do not expose Google's timed-only constraint
-  as a required pair of time inputs in the UI. See `event-management` for the
-  action contract and decline behavior.
-- Use framework sharing actions for calendars/events/booking resources when
-  applicable.
-- Booking-link sharing controls who can manage the link. Public booking access
-  is still controlled by the `/book/{username}/{slug}` URL and `isActive`.
-- `create-booking-link` and `update-booking-link` accept `hosts` for required
-  co-hosts besides the owner, e.g. `hosts: ["brent@example.com"]`. Group links
-  only offer times when the owner and all co-hosts are free, then invite
-  co-hosts to the created Google Calendar event.
+- Treat Google Calendar working locations and full-day out-of-office events as
+  native status events; see `event-management` for their action contracts.
+- Use framework sharing actions for calendar, event, and booking resources;
+  see `availability-booking` for booking-link controls and co-hosts.
 - Keep scheduling answers concrete: exact dates, time zones, conflicts, and
   assumptions.
-- Event detail (panel and popover) exposes `calendar.event-detail.bottom` as an
-  `ExtensionSlot`. Extensions render as widgets there with `slotContext`
-  (eventId, title, start/end, timezones, location, attendees, accountEmail).
-  For inline adornments next to each guest email (e.g. local times), prefer the
-  first-party attendee timezone UI / `set-attendee-timezone` settings, or a
-  source edit — do not claim the slot can inject per-row UI.
-- Use `rsvp-event` for invitation responses, and `update-event` with
-  `addAttendees` (not a replacement `attendees` list) when inviting more people.
-  See `event-management` for RSVP notes, optional guests, recurring guest scope,
-  and `get-attendee-timezones` / `set-attendee-timezone` overrides.
+- Event detail extensions, attendee adornments, RSVP scope, and multi-account
+  updates are documented in `event-management`; follow that skill before edits.
 
 ## Application State
 
@@ -95,4 +72,6 @@ ladder.
 - Preserve `accountEmail` on every Google event write. When more than one
   Google account is connected, pass the chosen account to `create-event`, and
   pass the event's returned `accountEmail` to `update-event`, `delete-event`,
-  and `rsvp-event`. These actions target that account's primary calendar.
+  and `rsvp-event`. These actions target that account's primary calendar. For a
+  move, pass the original account as `accountEmail` and the destination as
+  `targetAccountEmail` to `update-event`.