@agent-native/core 0.7.14 → 0.7.15

package/docs/content/onboarding.md

@@ -1,16 +1,80 @@
 # Onboarding
 
-The framework-level onboarding system gives every template a shared setup
-experience in the agent chat sidebar. Users see a checklist of setup steps,
-each with one or more ways to complete it — paste an API key, connect
-Builder, or ask the agent to do it for them.
+When you first open an app built on the agent-native framework, you'll see a
+**Setup** checklist in the agent sidebar. Each item is something the app needs
+from you — connect an AI engine, paste an API key, configure email delivery —
+before the agent can do its full job.
+
+## For end users
+
+### What you'll see
+
+- A **Setup** panel above the agent chat with a checklist like "Connect an AI
+  engine", "Email delivery", etc.
+- A counter at the top (e.g. "1 of 4") shows how many steps are done.
+- The current step is expanded; finished steps collapse with a green check;
+  remaining steps sit dimmed below.
+- Required steps show a small red **required** pill. The panel stays visible
+  until every required step is complete.
+- Once everything required is done, the panel hides itself automatically.
+- The whole panel can be collapsed with the chevron in the top-right, or
+  hidden entirely with **Hide setup** at the bottom.
+
+### How to complete each step
+
+Steps offer one or more **methods** — different ways to satisfy the same
+requirement. The recommended option is highlighted in blue; alternatives sit
+below it.
+
+- **Connect a service (one click)** — e.g. _Connect Builder_ for the managed
+  AI gateway. Click the button, a window opens, you sign in, the window closes,
+  and the step is marked complete. No keys to copy.
+- **Paste an API key or fill a form** — e.g. _Use your Anthropic API key_,
+  _Use Resend_ for email. Click the method, paste the value(s), click **Save**.
+  Secret fields use a password input so the value isn't shown on screen. Saved
+  values go into your local `.env` (or workspace settings) — see
+  [Secrets](/docs/secrets) for where they live.
+- **Open a link** — some steps point to a sign-in page or docs. Click
+  **Continue** and finish the flow in the new tab.
+- **Ask the agent** — a few steps offer a "Let the agent set it up" option.
+  Click it and the agent picks up in the chat, walking you through any
+  external setup (creating OAuth credentials, etc.).
+
+### The built-in steps you'll usually see
+
+- **Connect an AI engine** (required) — the only mandatory step. Either
+  connect Builder for a one-click managed gateway, or paste a key for
+  Anthropic, OpenAI, Google Gemini, or OpenRouter.
+- **Email delivery** (optional) — needed for password resets and team
+  invitations. Resend or SendGrid; without it, reset emails just log to the
+  server console.
+- **Database** and **Authentication** — only shown in local dev mode.
+  Production deployments configure these via environment variables.
+
+Templates can add their own steps on top of these — e.g. a CRM template might
+add "Connect Gmail", a docs template might add "Pick a default workspace". See
+[Authentication](/docs/authentication) for sign-in setup details.
+
+### Coming back to the checklist
+
+If you hit **Hide setup**, the panel disappears for that browser session.
+Required steps that aren't yet complete will surface again on next load. Once
+everything required is done, the panel auto-hides for good — there's nothing
+left to do.
+
+## For developers
+
+If you're building a template, you register onboarding steps so they appear in
+the user's sidebar checklist. The framework handles rendering, completion
+tracking, and dismissal — you just declare what the step is and how it's
+satisfied.
 
 The system is **auto-mounted**. Templates don't need to wire anything to get
-the three built-in steps (LLM, database, auth). To add app-specific steps
-(Gmail, Slack, Notion, etc.), call `registerOnboardingStep()` from a server
-plugin.
+the four built-in steps (LLM, database, auth, email). To add app-specific
+steps (Gmail, Slack, Notion, etc.), call `registerOnboardingStep()` from a
+server plugin.
 
-## Auto-mounted routes
+### Auto-mounted routes
 
 All routes live under `/_agent-native/onboarding/`:
 
@@ -22,7 +86,7 @@ All routes live under `/_agent-native/onboarding/`:
 | `POST /_agent-native/onboarding/reopen`             | Clear dismissal (re-show panel)   |
 | `GET /_agent-native/onboarding/dismissed`           | Read dismissal + allComplete flag |
 
-## Adding a step from a template
+### Adding a step from a template
 
 ```ts
 // server/plugins/my-onboarding.ts
@@ -61,7 +125,7 @@ export default defineNitroPlugin(() => {
 });
 ```
 
-## Method kinds
+### Method kinds
 
 | Kind               | Payload                   | Use for                                   |
 | ------------------ | ------------------------- | ----------------------------------------- |
@@ -72,18 +136,19 @@ export default defineNitroPlugin(() => {
 
 The `primary: true` flag marks a method as the big CTA for its step.
 
-## Built-in steps
+### Built-in steps
 
 | ID         | Required | Description                                   |
 | ---------- | -------- | --------------------------------------------- |
 | `llm`      | yes      | ANTHROPIC_API_KEY or Builder connection       |
 | `database` | no       | SQLite default or a DATABASE_URL for Postgres |
 | `auth`     | no       | Local dev mode, Google OAuth, or access token |
+| `email`    | no       | Resend or SendGrid for transactional email    |
 
 Any of these can be overridden by re-registering with the same `id` after the
 defaults load.
 
-## Client usage
+### Client usage
 
 The panel is already inside `<AgentPanel>`. To build a custom layout:
 
@@ -105,3 +170,8 @@ function MySidebar() {
   );
 }
 ```
+
+For background on where step values are stored and how secrets are handled,
+see [Secrets](/docs/secrets). For end-user messaging touchpoints (invitations,
+password resets) that depend on the **Email delivery** step, see
+[Messaging](/docs/messaging).

package/docs/content/template-analytics.md

@@ -1,23 +1,63 @@
 ---
-title: "Analytics Template"
-description: "AI-native analytics dashboards — connect data sources, prompt for charts, build reusable SQL dashboards and ad-hoc analyses."
+title: "Analytics"
+description: "Ask analytics questions in plain English, get charts and dashboards back. An open-source replacement for Amplitude, Mixpanel, and Looker."
 ---
 
-# Analytics Template
+# Analytics
 
-An open-source analytics app where the agent writes the SQL, builds the dashboards, and maintains the metric catalog. Replaces Amplitude, Mixpanel, and Looker for teams that want to own the code and the data.
+Ask analytics questions in plain English, get charts and dashboards back. The agent connects to BigQuery, GA4, your app database, HubSpot, Jira, and a dozen other sources, writes the SQL for you, validates it, and renders the answer as a chart, table, or saved dashboard panel.
 
-## Overview {#overview}
+It's an open-source replacement for Amplitude, Mixpanel, and Looker — for teams that want to own the code, the queries, and the data.
 
-The Analytics template is a dashboard app built on `@agent-native/core`. You ask a data question in chat, the agent queries the underlying source (BigQuery, GA4, the app database), and the answer appears as a chart, a table, or a saved dashboard panel. The agent sees the same screen the user sees and edits the same dashboards the user edits.
+## What you can do with it
 
-Three primary surfaces:
+- **Ask data questions in plain English.** "What percent of signups last month converted to paid?" or "Show me weekly active users for the past 6 months." The agent picks the right source, writes the SQL, and renders the chart.
+- **Build reusable SQL dashboards** with filters, saved views, and parametric queries.
+- **Run ad-hoc analyses** that cross-reference multiple data sources — saved as re-runnable investigations with the original question, instructions, and findings.
+- **Maintain a living data dictionary** of metrics, tables, and SQL recipes so the agent uses the right column names every time (no more guessed `is_closed` when it's actually `hs_is_closed`).
+- **Share dashboards** with your team — private by default, shareable per-user or per-org with viewer / editor / admin roles.
+- **Connect to many sources** out of the box: BigQuery, GA4, Mixpanel, Amplitude, PostHog, HubSpot, Jira, Apollo, Pylon, Gong, Common Room, Twitter, plus app-specific SEO sources.
 
-- **SQL Dashboards** — reusable panels with filters, saved views, and parametric SQL.
-- **Ad-hoc Analyses** — long-form investigations that pull from multiple sources and save re-run instructions.
-- **Data Dictionary** — a canonical catalog of metrics, tables, columns, and SQL recipes that the agent consults before writing any SQL.
+## Getting started
 
-## Quick start {#quick-start}
+Live demo: [analytics.agent-native.com](https://analytics.agent-native.com).
+
+When you first open the app:
+
+1. Sign in with Google.
+2. Open the **Data Sources** page from the sidebar.
+3. Each source has a walkthrough — connect the ones you need (start with one, like BigQuery or your app DB).
+4. Open a new chat with the agent and ask a question: "How many signups did we get last week?"
+
+The first question is enough to confirm the connection works. From there, ask the agent to "save this as a dashboard" or "build a 4-panel overview dashboard for our key metrics."
+
+### Useful prompts
+
+- "Build a dashboard showing weekly active users for the past 6 months."
+- "What percent of signups last month converted to paid?"
+- "Add a chart comparing revenue by plan to this dashboard."
+- "Reorder the panels on this dashboard so the MRR metric comes first."
+- "Analyze our closed-lost deals from Q1 and save the analysis."
+- "Re-run the churn analysis with this month's data."
+- "Document this metric in the data dictionary."
+
+The agent always knows what you're looking at — current dashboard, filters, view — so you can say "this dashboard" or "that panel" without being explicit.
+
+## Three things to know
+
+The app has three primary surfaces you'll spend time in:
+
+- **SQL Dashboards** — reusable panels with filters and saved views. Best for metrics you check regularly.
+- **Ad-hoc Analyses** — long-form investigations that pull from multiple sources, with re-run instructions saved alongside. Best for one-off questions you might want to revisit.
+- **Data Dictionary** — the canonical catalog of metrics, tables, columns, and SQL recipes. The agent consults it before writing any SQL, so it uses real warehouse column names and knows about caveats like "excludes internal emails".
+
+The dictionary is seeded by asking the agent: "import our dbt definitions" or "pull the metrics from our Notion handbook" and it does the work.
+
+## For developers
+
+The rest of this doc is for anyone forking the Analytics template or extending it.
+
+### Quick start
 
 Create a new Analytics app from the CLI:
 
@@ -25,8 +65,6 @@ Create a new Analytics app from the CLI:
 npx @agent-native/cli create analytics
 ```
 
-Or try the hosted demo: [analytics.agent-native.com](https://analytics.agent-native.com).
-
 Local dev:
 
 ```bash
@@ -37,15 +75,11 @@ pnpm dev
 
 The app runs at `http://localhost:3000`. Sign in with Google, then open the **Data Sources** page to connect BigQuery, HubSpot, Jira, and the rest.
 
-## Key features {#key-features}
+### Key features (technical)
 
-### Natural-language chart generation
+**Natural-language chart generation.** Ask the agent in plain English. It picks the right data source, writes the SQL, validates it against the warehouse, and renders the chart inline in chat or as a saved panel. Chart types: `line`, `area`, `bar`, `metric`, `table`, `pie`.
 
-Ask the agent in plain English. It picks the right data source, writes the SQL, validates it against the warehouse, and renders the chart inline in chat or as a saved panel. Chart types: `line`, `area`, `bar`, `metric`, `table`, `pie`.
-
-### Reusable SQL dashboards
-
-Dashboards are a named config with an array of panels. Each panel has an `id`, `title`, `sql`, `source` (`bigquery` / `app-db` / `ga4`), `chartType`, and `width` (1 or 2 columns). See the full shape in `templates/analytics/app/pages/adhoc/sql-dashboard/types.ts`.
+**Reusable SQL dashboards.** Dashboards are a named config with an array of panels. Each panel has an `id`, `title`, `sql`, `source` (`bigquery` / `app-db` / `ga4`), `chartType`, and `width` (1 or 2 columns). See the full shape in `templates/analytics/app/pages/adhoc/sql-dashboard/types.ts`.
 
 Dashboards support:
 
@@ -54,25 +88,13 @@ Dashboards support:
 - **Resizable panels** — 1- or 2-column width per panel; the grid fills the rest.
 - **Sharing** — private by default, share with users or orgs (`viewer` / `editor` / `admin`).
 
-### Ad-hoc analyses
-
-Long-form investigations that cross-reference sources. An analysis saves the original question, step-by-step re-run instructions, the data sources it touched, and the full findings in Markdown. Anyone with access can re-run it against fresh data.
-
-Stored in the `analyses` table (see `templates/analytics/server/db/schema.ts`).
-
-### Living data dictionary
+**Ad-hoc analyses.** Long-form investigations that cross-reference sources. An analysis saves the original question, step-by-step re-run instructions, the data sources it touched, and the full findings in Markdown. Anyone with access can re-run it against fresh data. Stored in the `analyses` table (see `templates/analytics/server/db/schema.ts`).
 
-The dictionary is the canonical catalog of metrics used by the org — metric name, definition, table, columns, SQL template, known gotchas, owner, and data lag. The agent reads it before writing any SQL, so it uses the real warehouse column names (`hs_is_closed`, not guessed `is_closed`) and knows about caveats like "excludes internal emails".
+**Living data dictionary.** Canonical catalog of metrics — metric name, definition, table, columns, SQL template, known gotchas, owner, and data lag. The agent reads it before writing any SQL, so it uses the real warehouse column names (`hs_is_closed`, not guessed `is_closed`) and knows about caveats like "excludes internal emails". Seeded by asking the agent to import definitions from an existing source (dbt descriptions, a Notion page, a team wiki).
 
-The dictionary is seeded by asking the agent to import definitions from an existing source (dbt descriptions, a Notion page, a team wiki).
+**SQL query explorer.** Direct SQL against BigQuery or the app DB from the **Ad-hoc** view. Useful for iterating on a query before saving it as a dashboard panel.
 
-### SQL query explorer
-
-Direct SQL against BigQuery or the app DB from the **Ad-hoc** view. Useful for iterating on a query before saving it as a dashboard panel.
-
-### Multiple data connectors
-
-Built-in actions for common sources:
+**Multiple data connectors.** Built-in actions for common sources:
 
 | Category      | Actions                                                                  |
 | ------------- | ------------------------------------------------------------------------ |
@@ -86,44 +108,28 @@ Built-in actions for common sources:
 
 Full list lives in `templates/analytics/actions/`. New sources are added by dropping a new action file — the agent picks them up automatically.
 
-### Organizations and sharing
-
-Multi-org deployments are wired up by default via `@agent-native/core/org`. Dashboards and analyses are scoped to the active org. The `/team` route manages members and invitations. See `templates/analytics/app/routes/team.tsx`.
-
-Sharing uses the framework's `share-resource` primitive. Coarse visibility is `private` / `org` / `public`; fine-grained grants are per-principal with `viewer` / `editor` / `admin` roles.
+**Organizations and sharing.** Multi-org deployments are wired up by default via `@agent-native/core/org`. Dashboards and analyses are scoped to the active org. The `/team` route manages members and invitations. See `templates/analytics/app/routes/team.tsx`. Sharing uses the framework's `share-resource` primitive. Coarse visibility is `private` / `org` / `public`; fine-grained grants are per-principal with `viewer` / `editor` / `admin` roles.
 
-## Working with the agent {#working-with-the-agent}
+### Working with the agent
 
 The agent always knows what you're looking at. The current screen state is injected into every message as a `<current-screen>` block — it contains the active view, the open dashboard or analysis, and any selected filters.
 
-Useful prompts:
-
-- "Build a dashboard showing weekly active users for the past 6 months."
-- "What percent of signups last month converted to paid?"
-- "Add a chart comparing revenue by plan to this dashboard."
-- "Reorder the panels on this dashboard so the MRR metric comes first."
-- "Analyze our closed-lost deals from Q1 and save the analysis."
-- "Re-run the churn analysis with this month's data."
-- "Document this metric in the data dictionary."
-
 The agent's system prompt gets an injected `<data-dictionary>` block with the approved metric entries for the active org. When you ask for a dashboard, the agent consults the dictionary first and uses the documented `table` / `columns` / `queryTemplate` verbatim — it does not guess column names.
 
-### Context it has automatically
+**Context it has automatically:**
 
 - **Current view** — `overview`, `adhoc` (with `dashboardId`), `analyses` (with `analysisId`), `data-dictionary`, `data-sources`, or `settings`.
 - **Active org** — scopes all queries and writes.
 - **Approved dictionary entries** — for the active workspace.
 
-### Dashboard edits
-
-The agent uses the `update-dashboard` action to edit dashboards. It supports two modes:
+**Dashboard edits.** The agent uses the `update-dashboard` action to edit dashboards. It supports two modes:
 
 - `ops` — JSON-Pointer patches for surgical edits (move a panel, replace one SQL string, remove a filter).
 - `config` — full replacement of the dashboard config.
 
 Every BigQuery panel's SQL is dry-run against the warehouse before the dashboard saves. If a column is wrong, the save is rejected with the BigQuery error — the agent fixes the SQL and retries instead of persisting broken panels.
 
-## Connecting data sources {#connecting-data-sources}
+### Connecting data sources
 
 Open the **Data Sources** page (`/data-sources`) to connect providers. Each source exposes an env-key list, a walkthrough, and a **Test Connection** button. The page calls `/api/credential-status`, `/api/credentials`, and `/api/test-connection`.
 
@@ -142,7 +148,7 @@ Provider-specific keys (HubSpot, Jira, Gong, Pylon, etc.) are documented in each
 
 Note: the BigQuery OAuth credential for Google sign-in is a **separate** credential from the BigQuery service account JSON. Create the sign-in client at GCP Console → APIs & Services → Credentials → OAuth client ID.
 
-## Data model {#data-model}
+### Data model
 
 Core tables (see `templates/analytics/server/db/schema.ts`):
 
@@ -157,7 +163,7 @@ Plus the org tables (`organizations`, `org_members`, `org_invitations`) provided
 
 The data dictionary lives in the framework's `settings` table under scoped keys; see the `list-data-dictionary` and `save-data-dictionary-entry` actions for the full shape.
 
-## Customizing it {#customizing-it}
+### Customizing it
 
 The Analytics template is meant to be forked and extended. Everything lives in `templates/analytics/`:
 

package/docs/content/template-clips.md

@@ -30,10 +30,6 @@ Three things make Clips a good showcase of what agent-native enables:
 
 The rest of this doc is for anyone forking the Clips template or extending it.
 
-### Naming note
-
-In the template, always say **"Clip"** in user-facing strings and agent messages. Internal table / variable names (`recordings`, `recording_transcripts`, etc.) stay as-is.
-
 ### Scaffolding
 
 ```bash
@@ -44,13 +40,15 @@ Clips is a larger template with a native recorder (it ships a desktop companion
 
 ### Customize it
 
-Ask the agent:
+Clips is a full cloneable SaaS — fork it and ask the agent to extend it. Some examples:
 
-- "Add a 'filler word removal' button that strips ums and uhs from the transcript and re-stitches the video." It edits the transcript processor and wires the UI.
-- "Auto-post a new clip to Slack #eng-demos when I record one." It adds the hook.
-- "Group the library by project — detect the project from the first words of each transcript." It updates the list view.
+- "Add a filler-word removal button that strips ums and uhs from the transcript and re-stitches the video."
+- "Auto-post a new clip to Slack #eng-demos whenever I finish a recording." (Connect Slack first via [Messaging](/docs/messaging).)
+- "Group the library by project — detect the project from the first words of each transcript."
+- "Add a 'Generate blog post from this clip' button that drafts a post from the transcript and saves it as a draft."
+- "Let viewers leave timestamped reactions on a shared clip."
 
-See [Cloneable SaaS](/docs/cloneable-saas) for the full clone → customize → deploy flow.
+The agent edits routes, components, the transcript pipeline, and the schema as needed. See [Cloneable SaaS](/docs/cloneable-saas) for the full clone, customize, deploy flow, and [Getting Started](/docs/getting-started) if this is your first agent-native template.
 
 ## What's next
 

package/docs/content/template-design.md

@@ -0,0 +1,55 @@
+---
+title: "Design"
+description: "An Agent-native design tool — sketch a UI, brand kit, or marketing visual by prompt or by hand, with the agent as your co-designer."
+---
+
+# Design
+
+A design tool where the agent is a real collaborator. Sketch a UI, a brand kit, or a marketing visual by prompt or by hand, and the agent generates layouts, suggests color systems, swaps fonts, and adjusts spacing alongside you on the same canvas.
+
+Think along the lines of Figma or Canva, but the agent has full edit rights — it can move shapes, restyle layers, and generate new artwork from a description, all in the same canvas you're working in.
+
+## What you can do with it
+
+- **Prompt-driven design.** Describe what you want — "a hero section for a B2B fintech SaaS, dark mode, brand color #14B8A6" — and the agent drafts it on the canvas.
+- **Edit by hand or by chat.** Drag, resize, recolor with the toolbar; or ask the agent to "tighten the spacing", "swap the headline font for something more editorial", "make every CTA the brand teal".
+- **AI image generation built in.** Generate background art, illustrations, or icons inline. Re-run with refined prompts without leaving the canvas.
+- **Brand-aware.** Save a brand kit (colors, fonts, voice). The agent applies it consistently across new artwork.
+- **Components and frames.** Reusable components, multi-page documents, and export to PNG/SVG/PDF.
+- **Agent context awareness.** When a layer is selected, the agent knows what you've selected and can act on just that piece.
+
+## Why it's interesting
+
+Three things make Design a good showcase of what agent-native enables:
+
+1. **The agent edits the canvas directly.** Layers, frames, styles — the agent calls the same actions the toolbar does. There's no "AI mode" separate from the design tool; they're the same tool.
+2. **Selection-aware editing.** Select a button and ask "make this the brand teal across all pages" — the agent knows which element you mean and propagates the change.
+3. **Designs you own.** The files live in your SQL, the artwork lives in your storage, the agent is yours. Fork the template, plug in a different image-generation provider, integrate your team's component library — it's your code.
+
+## For developers
+
+The rest of this doc is for anyone forking the Design template or extending it.
+
+### Scaffolding
+
+```bash
+pnpm dlx @agent-native/core create my-design --template design --standalone
+```
+
+### Customize it
+
+Design is a full cloneable SaaS — fork it and ask the agent to extend it. Some examples:
+
+- "Add a 'Generate variations' button that produces five color-swap alternatives for the selected frame."
+- "Wire the brand kit to read from our marketing-site repo so colors stay in sync."
+- "Add a comments layer with @-mentions and email notifications."
+- "Auto-export every published frame as a 1200×630 OG image and upload to our CDN."
+- "Let me drop a Figma link in chat and have the agent re-create it as native components here."
+
+The agent edits routes, components, canvas actions, and the schema as needed. See [Cloneable SaaS](/docs/cloneable-saas) for the full clone, customize, deploy flow, and [Getting Started](/docs/getting-started) if this is your first agent-native template.
+
+## What's next
+
+- [**Cloneable SaaS**](/docs/cloneable-saas) — the clone-and-own model
+- [**Context Awareness**](/docs/context-awareness) — how the agent knows the selected layer
+- [**Tools**](/docs/tools) — generate one-off image-creation utilities alongside the canvas

package/docs/content/template-dispatch.md

@@ -29,8 +29,21 @@ Use Dispatch when:
 
 Skip it for a single-app scaffold — use the [Starter template](/docs/template-starter) or any of the domain templates directly.
 
+## What you'll do with it {#what-youll-do}
+
+Day-to-day, Dispatch is the place admins and ops folks open to keep the workspace running:
+
+- **Connect Slack, email, and Telegram** so people can message your agent from wherever they already work. See [Messaging](/docs/messaging) for the wiring steps.
+- **Save shared secrets once.** API keys, OAuth tokens, and service credentials live in the vault and the other apps in your workspace pull from there instead of every team member juggling their own `.env`.
+- **Set up recurring jobs.** "Every Monday at 7am, ask the analytics agent for last week's signups and email me a summary." See [Recurring Jobs](/docs/recurring-jobs).
+- **Approve outbound actions before they fire.** Sending money, mass-emailing customers, or posting to a public Slack channel can be gated behind an admin OK.
+- **See who has access to what.** Per-app grants, request queue, and an audit log of who used which secret when.
+- **Route messages to the right specialist.** A Slack DM about analytics goes to the analytics agent; one about email goes to the mail agent — Dispatch picks.
+
 ## Architecture at a glance {#architecture}
 
+_How it works under the hood (for developers)._
+
 - **Orchestrator agent.** The chat is set up as a router: it reads `AGENTS.md`, `LEARNINGS.md`, and routes to specialist sub-agents or remote A2A agents.
 - **Remote agent registry.** A2A manifests live in `remote-agents/*.json` — one per app. Dispatch calls them using the `call-agent` action.
 - **Vault schema.** Drizzle tables for secrets, grants, requests, approvals, and audit logs. See `server/db/schema.ts` in the template.

package/docs/content/template-forms.md

@@ -20,7 +20,7 @@ When you open the app, you'll see a list of your forms on the left and the edito
 
 ## Why it's interesting
 
-Forms is a clear example of the [ladder](/docs/what-is-agent-native#the-ladder) rung-3 payoff. The hard part of a form builder isn't the editor UI — it's everything around it: schema evolution, response analytics, conditional logic, publishing, notifications, integrations. Most of that is just prompting the agent, because every capability is an action the agent can call.
+The hard part of a form builder isn't the editor UI — it's everything around it: changing the questions after responses are already in, analyzing what people said, adding conditional logic, publishing, notifications, hooking it into Slack or your CRM. Most of that is just asking the agent. See [What is agent-native?](/docs/what-is-agent-native) for the bigger picture.
 
 ## For developers
 
@@ -38,13 +38,14 @@ pnpm dlx @agent-native/core create my-platform  # pick Forms + other templates
 
 ### Customize it
 
-Ask the agent:
+Ask the agent for the outcome you want:
 
-- "Add a new 'signature' field type that captures a drawn signature." It adds the schema entry, renders the component, handles storage.
-- "When someone submits a form, post the response to our #signups Slack channel." It wires the webhook.
-- "Add per-form access control — some are public, some require a login." It updates the publishing flow.
+- "Add a signature field where people can draw their name."
+- "When someone submits this form, post it in our #signups Slack channel." (Connect Slack first via [Messaging](/docs/messaging).)
+- "Make some forms public and others login-only."
+- "Send everyone who scored below 5 a follow-up email asking what we could do better."
 
-See [Cloneable SaaS](/docs/cloneable-saas) for the full clone → customize → deploy flow.
+The agent figures out the schema changes, components, and storage on its own — you just describe the result you want. See [Cloneable SaaS](/docs/cloneable-saas) for the full clone, customize, deploy flow.
 
 ## What's next