commit ffea2aeff75fee65eb38c7926f6f5247fc49280a Author: agent-native Date: Sat Jul 25 17:10:38 2026 +0000 Initial commit from agent-native create diff --git a/.agents/skills/actions/SKILL.md b/.agents/skills/actions/SKILL.md new file mode 100644 index 0000000..1347ac6 --- /dev/null +++ b/.agents/skills/actions/SKILL.md @@ -0,0 +1,512 @@ +--- +name: actions +description: >- + How to create and run agent actions. Actions are the single source of truth + for app operations — the agent calls them as tools and frontend code calls + them through client hooks. Use when creating a new action, adding an API + integration, or wiring up frontend data fetching. +scope: dev +metadata: + internal: true +--- + +# Agent Actions + +## Rule + +Actions in `actions/` are the **single source of truth** for app operations. The agent calls them as tools, and the frontend calls them through `useActionQuery` / `useActionMutation`. The framework owns the HTTP transport behind those hooks. No duplicate `/api/` routes needed. + +Before creating any custom REST/API route for app data, inspect `actions/` and the action table in `AGENTS.md`. If an action already exists, call it directly from the agent or with `useActionQuery` / `useActionMutation` from the UI. If the capability is missing, create or update a `defineAction`. Do not add `/api/*`, `server/routes/*`, or other pass-through endpoints whose main job is to call, repackage, or re-export an action. + +## Why + +Actions give the agent callable tools with structured input/output, AND they give the frontend a typed client contract through hooks. One implementation serves both the agent and the UI. They keep the agent's chat context clean, they're reusable, and they can be tested independently. + +## Keep the Action Surface Small and Orthogonal + +Every agent-exposed action is a tool in the model's context window. There is a real cost to each one: more tools means more for the model to read, disambiguate, and choose between, which degrades tool-selection quality. Treat the action list like an API you have to maintain — add the fewest, most orthogonal actions that cover the capability, not one per UI affordance. + +- **Prefer one CRUD-style `update` over N per-field actions.** A single `update-` that takes a patch of optional fields beats `update--name`, `update--order`, `update--color`, … The agent (and the UI) pass only the fields that change. Same for `create`/`delete` — one orthogonal action per resource, not one per code path. +- **Reach for a generic query / escape hatch before minting a new read action.** If the agent needs more or different data, do not add `get--by-x`, `list--filtered-by-y`, etc. For provider data, expose the shared `provider-api-catalog` / `provider-api-docs` / `provider-api-request` trio (see `templates/dispatch/actions/`) so the agent can hit any endpoint or filter without a new action each time. For app data in dev, the `db-query` tool already answers arbitrary read questions. +- **Hide UI-only or purely programmatic actions from the model with `agentTool: false`.** An action that only the frontend or an HTTP/cron caller needs should not spend a slot in the model's tool list. `agentTool: false` keeps it callable from `useActionMutation` / `callAction` / `/_agent-native/actions/` while removing it from every agent tool surface (in-app assistant, MCP, A2A). +- **`agentTool: false` is NOT `toolCallable: false`.** They are different switches: + - `agentTool: false` → hidden from the **model entirely** (it is no longer a tool the agent can see or call). Still frontend/HTTP-callable. + - `toolCallable: false` → only blocks the **sandboxed extension ("tools") iframe bridge** (`appAction(...)`). The action stays fully visible to the model, the UI, the CLI, MCP, and A2A. Use it for high-blast-radius operations (account/org/auth changes), not for trimming the tool list. +- **Remove or hide stale actions.** When the UI stops using an action, delete it or set `agentTool: false` — do not leave it exposed to the model as dead tool weight. The advisory audit below helps you spot these. + +### Audit Script (Advisory) + +`pnpm actions:audit [template ...]` (or `node scripts/audit-template-actions.mjs`) statically scans a template's `actions/` and prints two kinds of suggestions: + +1. **Likely UI-dead** — HTTP-exposed mutating actions whose name is never referenced under `app/` (candidates to delete or mark `agentTool: false`). +2. **Likely redundant clusters** — groups like `update-foo-name` / `update-foo-order` that could collapse into one orthogonal `update-foo`. + +It is **advisory only**: it always exits 0, never fails CI, and uses conservative heuristics, so expect some false positives (e.g. an action the agent calls but the UI doesn't). Use it as a prompt to review, not a gate. + +## How to Create an Action + +Use `defineAction` with a Zod schema (required for new actions): + +```ts +// actions/list-meals.ts +import { z } from "zod"; +import { defineAction } from "@agent-native/core/action"; +import { getDb } from "../server/db/index.js"; +import { meals } from "../server/db/schema.js"; + +export default defineAction({ + description: "List all meals", + schema: z.object({ + date: z.string().describe("Filter by date (YYYY-MM-DD)"), + }), + http: { method: "GET" }, + run: async (args) => { + // args is fully typed: { date: string } + const db = getDb(); + const rows = await db.select().from(meals); + return rows; // Return objects/arrays, NOT JSON.stringify() + }, +}); +``` + +The `schema` field accepts a Zod schema (or any Standard Schema-compatible library). It provides runtime validation with clear error messages (400 for HTTP, error result for agent), full TypeScript type inference for `run()` args, and auto-generated JSON Schema for the agent's tool definition. `zod` is a dependency of all templates. + +When an action reads or writes app data, use Drizzle's query builder and portable operators from `drizzle-orm`. Do not use raw SQL, `getDbExec()`, or dialect-specific schema imports in normal actions unless there is a documented reason Drizzle cannot express the query. + +When an action calls an external service, never hardcode API keys, bearer +tokens, webhook URLs, signing secrets, OAuth refresh tokens, private +Builder/internal data, or customer data. Read user/org/workspace credentials +from `readAppSecret`, `resolveCredential`, OAuth token helpers, or the provider +API credential adapter. Use `process.env` only for explicitly deploy-level +configuration, and keep examples to obvious placeholders. + +Tips: +- Use `.describe()` for parameter descriptions +- Use `.optional()` for optional params +- Use `z.coerce.number()` for numeric params that arrive as strings from HTTP. + For booleans, use an explicit string parser/helper instead of + `z.coerce.boolean()` because JavaScript treats any non-empty string, + including `"false"`, as truthy. +- Use `z.enum(["draft", "published"])` for constrained values + +The legacy `parameters` field (plain JSON Schema object) still works as a fallback but does not provide runtime validation or type inference. + +## Decision Order + +When you need app data or a mutation: + +1. **Use an existing action** if one already performs the operation. +2. **Create or extend a `defineAction`** when the agent and UI both need a new operation. +3. **Create a custom route only for route-only concerns** such as uploads, streaming, webhooks, OAuth callbacks, or a non-JSON protocol. + +Do not build an umbrella REST API to make actions "easier" to call. Actions are already callable by agents, CLIs, React hooks, HTTP, MCP/A2A exposure, and external hosts through the framework. + +## Flexible Provider APIs + +For provider integrations used in ad hoc analysis, querying, reporting, or +cross-source research, do not hardcode every provider endpoint as a separate +rigid action and do not encode one lookback window, filter shape, or pagination +strategy as the only path the agent can take. Expose the shared provider API +action trio instead: + +- `provider-api-catalog`: lists provider base URLs, auth style, credential keys, + docs/spec URLs, placeholders, and examples without exposing secrets. +- `provider-api-docs`: fetches public provider docs/spec/changelog URLs when + the exact endpoint, filter operator, payload shape, or pagination contract is + uncertain. Registered docs URLs are curated starting points. Use + `responseMode: "markdown"` for clean readable docs, or + `responseMode: "matches"` with `search: { query | terms | regex }` for + compact snippets instead of flooding context with raw HTML. +- `provider-api-request`: makes a constrained authenticated HTTP request to the + provider host, injects configured credentials, blocks private/internal URLs, + and redacts secrets. + +Use `@agent-native/core/provider-api` as the shared substrate, and build these +actions as thin factory imports rather than copying `defineAction` schemas and +handlers into each template: + +```ts +import { + createProviderApiCatalogAction, + createProviderApiDocsAction, + createProviderApiRequestAction, +} from "@agent-native/core/provider-api/actions/provider-api"; +import { + createDeleteStagedDatasetAction, + createListStagedDatasetsAction, + createQueryStagedDatasetAction, +} from "@agent-native/core/provider-api/actions/staged-datasets"; +``` + +Pass the app's existing provider runtime to the provider factories, and pass +its app id to the staged-dataset factories. Keep app-specific descriptions, +provider allow-lists, HTTP/tool-callability settings, and credential adapters +as factory options. Only add a thin credential adapter when the app has +app-specific credential lookup rules. If the app stores a built-in provider's +OAuth grant under a narrower local provider id, use the runtime's +`oauthProviderOverrides` instead of duplicating provider config. If credentials +are stored on shareable/resource rows rather than in the shared credential or +OAuth-token stores, build a resolver that enforces those access checks before +exposing raw provider requests. Keep `provider-api-request` `http: false` +unless a separate UI permission model authorizes arbitrary provider writes. +Specific actions such as `search-records`, `search-emails`, or `sync-source` +are convenience shortcuts, not capability limits; agents should fall back to +the provider API trio when a question requires an endpoint or filter that the +shortcut does not model. + +This is a framework tenet. The safety boundary should be provider host +allow-listing, credential scoping, auth injection, private-network blocking, +secret redaction, and user/org access checks, not an artificially small set of +hand-authored read actions. If the upstream provider API supports a capability, +the agent should normally be able to reach it through `provider-api-request` +with the user's configured credentials. For large responses, expose staging +(`stageAs`, `itemsPath`, pagination, and `query-staged-dataset`) or sandboxed +code execution so the agent can reduce data without flooding context. + +For broad provider questions, cross-source joins, corpus-wide mention/search +work, classification, or any answer where absence matters, design the action +surface for full coverage instead of convenience-only samples. The agent should +be able to fetch every relevant page or an explicitly bounded cohort, stage or +save the raw provider response outside chat, and then use +`query-staged-dataset`, `run-code`, or provider-side search to count, join, +grep, classify, and aggregate. Tool descriptions and AGENTS.md guidance should +teach agents to report source, filters, time window, row/record counts, +pagination status, truncation, failed pages, and uncovered gaps. They must not +turn default limits, sampled rows, truncated excerpts, or aborted calls into a +confident "none found", "all records", or exhaustive conclusion. + +For public web pages and docs, prefer the token-efficient path: `web-search` +to find likely URLs, `web-request` or `provider-api-docs` with clean +`responseMode` output to read a page, and `run-code` with `webRead()` / +`webFetch()` when you need to grep, aggregate, or compare many pages before +returning a small result. + +For LONG compute, `run-code` supports durable background executions: pass +`background: true` and the code is enqueued to a `sandbox_executions` row and +executed out-of-band with a generous budget (default 10 min), surviving the +hosted agent run's ~40s soft timeout. The call returns +`{ executionId, status: "queued" }` immediately with polling guidance; check +progress with `run-code` `{ executionId }` (or the `get-code-execution` tool +where registered) — results persist after completion. Use background for big +cross-source joins, multi-page provider sweeps, and heavy analysis scripts; +keep quick scripts in the default foreground mode. Agents should continue +other work between polls, and on `failed`/`timed_out` split the computation or +persist intermediate progress with `workspaceWrite` and re-run. + +### The `http` Option + +Controls how the action is exposed as an HTTP endpoint: + +| Value | Behavior | Use for | +| ------------------------- | ----------------------------------------------------------- | -------------------------------- | +| _(omitted)_ | Auto-exposed as `POST /_agent-native/actions/:name` | Write operations (default) | +| `{ method: "GET" }` | Auto-exposed as `GET /_agent-native/actions/:name` | Read-only queries | +| `{ method: "PUT" }` | Auto-exposed as `PUT /_agent-native/actions/:name` | Update operations | +| `{ method: "DELETE" }` | Auto-exposed as `DELETE /_agent-native/actions/:name` | Delete operations | +| `{ method: "GET", path: "custom" }` | Auto-exposed as `GET /_agent-native/actions/custom` | Custom route path | +| `false` | Agent-only, never exposed as HTTP | `navigate`, `view-screen`, internal actions | + +### Screen Refresh (automatic) + +The framework auto-refreshes the UI after any successful mutating action. On completion of a non-`GET` action, the framework emits a change event with `source: "action"` that the client's `useDbSync` picks up and uses to invalidate `["action"]` React Query keys — so `list-*` / `get-*` hooks refetch without a full page reload. In-process calls emit directly; dev-mode `pnpm action ...` calls also write a durable marker so the web server sees child-process action changes. + +Rules: + +- `http: { method: "GET" }` → read-only, does NOT trigger a refresh (inferred automatically). +- Any other action (default `POST`, `PUT`, `DELETE`, or `http: false`) → treated as mutating, triggers a refresh on success. +- To override the inference on an unusual action (e.g. a `POST` that only reads), pass `readOnly: true` on the action definition. +- To let a mutating action run concurrently with other same-turn tool calls, pass `parallelSafe: true`. Only do this when the action is internally concurrency-safe and order-independent (for example, it uses an app-level lock or idempotent upsert semantics). Mutating actions remain serialized by default. + +Agents do NOT need to call `refresh-screen` after a normal action — it's already handled. `refresh-screen` is only needed when the agent mutates data via a path the framework can't see (e.g. writing to an external system the app mirrors) or when the agent wants to pass a `scope` hint for narrower invalidation. + +### Return Values + +Actions should return **structured data** (objects, arrays) — not `JSON.stringify()`. The framework serializes the response automatically. If you return a string, the framework tries to parse it as JSON for a clean response. + +```ts +// Good — return structured data +run: async (args) => { + const events = await fetchEvents(args.from, args.to); + return events; +} + +// Bad — don't stringify +run: async (args) => { + const events = await fetchEvents(args.from, args.to); + return JSON.stringify(events, null, 2); +} +``` + +### Returning Images the Agent Can See (`_agentImages`) + +An action's return object may include the well-known optional field +`_agentImages` to attach vision images (screenshots, chart previews, rendered +designs) to the tool result. The agent literally sees them — enabling visual +self-review loops — while the field itself is stripped from the JSON text the +model reads. + +```ts +run: async ({ dashboardId }) => { + const shot = await renderDashboardPng(dashboardId); // Buffer + return { + dashboardId, + panelCount: 6, + _agentImages: [ + // Either a public https URL (preferred — the provider fetches it)… + { url: "https://cdn.example.com/previews/dash-1.png", label: "overview" }, + // …or base64 without a data: prefix (mediaType required; a full + // data:image/png;base64,… URL in `data` is also accepted and parsed). + { data: shot.toString("base64"), mediaType: "image/png" }, + ], + }; +}, +``` + +Rules and limits: + +- Shape: `Array<{ url?: string; data?: string; mediaType?: string; label?: string }>`. + Each entry needs `url` (https only) **or** `data`. Supported media types: + `image/jpeg`, `image/png`, `image/gif`, `image/webp`. +- Caps: max **4 images** per result; max **~2MB of base64** per image. + Over-cap or invalid entries never fail the call — they become text notes in + the result telling the model what was dropped and why. +- Persistence: the run ledger stores only the string result plus compact + `[image: …]` notes (URLs verbatim; base64 as a byte-count placeholder) — + never the payload. Images are re-attached only for the live turn; replayed + history is text-only, so prefer stable `url` images the model can re-request. +- Engine support: native Anthropic and vision-capable AI-SDK providers + (anthropic, openai, google, openrouter) receive real image blocks; other + paths (Builder gateway, non-vision providers) degrade to the text notes. +- External MCP tools need no changes — standard MCP `image` content parts are + converted automatically under the same caps. + +### Validating Return Values (`outputSchema`) + +`schema` validates inputs; `outputSchema` validates what the action **returns**. Pass any Standard Schema-compatible schema (Zod, Valibot, ArkType) and the framework validates the result _after_ `run()` resolves — input validated before `run`, output after. + +```ts +export default defineAction({ + description: "Summarize a thread.", + schema: z.object({ threadId: z.string() }), + outputSchema: z.object({ summary: z.string(), messageCount: z.number() }), + outputErrorStrategy: "warn", // default; "strict" | "fallback" + // outputFallback: { summary: "", messageCount: 0 }, // used only by "fallback" + run: async ({ threadId }) => { + /* ... */ + }, +}); +``` + +- `"warn"` (default) — `console.warn` the issues and return the **original** result unchanged. Non-breaking. +- `"strict"` — throw a clear error so a buggy action surfaces loudly. +- `"fallback"` — return `outputFallback` in place of the invalid result. + +On success the validated value is returned, so coercion/defaults on `outputSchema` apply. Omit `outputSchema` and behavior is byte-for-byte unchanged (no wrapping). + +### Human-in-the-Loop Approval (`needsApproval`) + +For high-consequence, outward-facing, hard-to-undo actions (sending an email, charging a card, deleting an account), set `needsApproval` so the agent **cannot** run the action without a human approving the specific call: + +```ts +export default defineAction({ + description: "Send an email via Gmail.", + schema: z.object({ to: z.string(), subject: z.string(), body: z.string() }), + needsApproval: true, // boolean, or (args, ctx) => boolean | Promise + run: async (args) => { + /* ...actually send... */ + }, +}); +``` + +When the gate is truthy and the call isn't yet approved, the loop emits an `approval_required` event and **stops the turn — `run()` never executes**. A predicate gates conditionally (e.g. only external recipients) and **fails closed**: a throw is treated as "approval required". The human approves via the chat UI's Approve affordance, which re-issues the turn with the call's `approvalKey`, and only then does the action run. + +**Keep approvals rare** — the default is off and almost every action should leave it off. The canonical example is Mail's `send-email` (`needsApproval: true`). See the `security` skill and the Human Approval doc. + +## Frontend Hooks + +The frontend calls actions using React Query hooks from `@agent-native/core/client`. Components should not hand-write `fetch("/_agent-native/actions/...")`; add or reuse a client hook/helper instead. Use `callAction` from the same package for imperative cases that do not fit a hook, such as debounced search, prefetching, or non-React event handlers. + +### `useActionQuery` — for GET actions + +```ts +import { useActionQuery } from "@agent-native/core/client/hooks"; + +function MealList() { + // Types are auto-inferred from the action's schema + return type — no manual generic needed + const { data: meals } = useActionQuery("list-meals", { + date: "2025-01-01", + }); + return
    {meals?.map((m) =>
  • {m.name}
  • )}
; +} +``` + +### `useActionMutation` — for POST/PUT/DELETE actions + +```ts +import { useActionMutation } from "@agent-native/core/client/hooks"; + +function AddMealButton() { + // Types are auto-inferred — no manual generic needed + const { mutate } = useActionMutation("log-meal"); + return ( + + ); +} +``` + +**Do NOT use manual type generics** like `useActionQuery(...)`. Types are inferred automatically from `.generated/action-types.d.ts`, which is auto-generated by a Vite plugin. + +Mutations automatically invalidate all `["action"]` query keys on success, so GET queries refetch. + +### `callAction` — for imperative client code + +```ts +import { callAction } from "@agent-native/core/client/hooks"; + +const people = await callAction("search-people", { query }, { method: "GET" }); +``` + +Prefer hooks in React data flows. Use `callAction` when a hook would be awkward; +do not hand-write action route fetches in components. + +## How to Run (Agent) + +```bash +pnpm action my-action --input data/source.json --output data/result.json +``` + +## Action Dispatcher + +The default template uses core's `runScript()` in `actions/run.ts`: + +```ts +import { runScript } from "@agent-native/core"; +runScript(); +``` + +This is the canonical approach for new apps. Action names must be lowercase with hyphens only (e.g., `my-action`). + +## When You Still Need Custom `/api/` Routes + +Most operations should be actions. You only need custom routes in `server/routes/api/` for: + +- **File uploads** — actions receive JSON params, not multipart form data +- **Streaming responses** — SSE or chunked responses that need direct H3 control +- **Webhooks** — external services POST to a specific URL +- **OAuth callbacks** — redirect-based flows that need specific URL patterns + +When the agent needs a durable image or file URL, call the core `upload-image` +action or use `uploadFile()` in server code. Do not write base64 into SQL, +markdown, deck/design JSON, or action results. `_agentImages` on action results +is for ephemeral vision previews only, not persistence. + +If it's a standard CRUD operation, data query, or a wrapper around an action, use the action instead. + +## Legacy Pattern (bare export) + +Older actions use a bare async function export with `parseArgs`: + +```ts +import { parseArgs, loadEnv, fail } from "@agent-native/core"; + +export default async function myAction(args: string[]) { + loadEnv(); + const parsed = parseArgs(args); + // ... +} +``` + +This still works but is not auto-exposed as HTTP. Prefer `defineAction` for all new actions. + +## Guidelines + +- **One action, one job.** Keep actions focused on a single operation. The agent composes multiple action calls for complex operations. +- **Return structured data.** Return objects/arrays, not `JSON.stringify()`. +- **Use `http: { method: "GET" }`** for read-only actions. Default is POST. +- **Use `http: false`** for agent-only actions (`navigate`, `view-screen`). +- **Use `agentTool: false`** for UI-only / programmatic actions that should NOT be a tool in the model's context window. It stays frontend/HTTP-callable but is hidden from the agent. Distinct from `toolCallable: false`, which only blocks the sandboxed extension iframe bridge. +- **Document reusable actions.** If a new action should be called by agents outside one narrow screen, update `AGENTS.md` with when to use it, important args, and which return fields to preserve. +- **Promote workflow-heavy actions to skills.** If the action is part of a provider-backed, cross-app, MCP/A2A, or multi-step workflow, create or update a skill in `.agents/skills/` and add app-skill visibility (`internal`, `exported`, or `both`) when it should ship through a marketplace. +- **Use `loadEnv()`** only for deploy-level configuration. User/org/workspace + credentials belong in the encrypted secrets/credential/OAuth stores, never as + hardcoded literals or shared env fallbacks. +- **Use `fail()`** for user-friendly error messages (exits with message, no stack trace). +- **Import action primitives from `@agent-native/core/action`** and CLI helpers such as `parseArgs()` from `@agent-native/core` — do not redefine framework utilities locally. +- **Do not re-export actions as REST.** The mounted `/_agent-native/actions/:name` endpoint is the REST surface; duplicating it under `/api/*` creates drift and hides the operation from agents. + +## Common Patterns + +**Read action (GET):** + +```ts +import { z } from "zod"; +import { defineAction } from "@agent-native/core/action"; + +export default defineAction({ + description: "List calendar events", + schema: z.object({ + from: z.string().describe("Start date"), + to: z.string().describe("End date"), + }), + http: { method: "GET" }, + run: async (args) => { + return await fetchEvents(args.from, args.to); + }, +}); +``` + +**Write action (POST, default):** + +```ts +import { z } from "zod"; +import { defineAction } from "@agent-native/core/action"; + +export default defineAction({ + description: "Log a meal", + schema: z.object({ + name: z.string().describe("Meal name"), + calories: z.coerce.number().describe("Calorie count"), + }), + run: async (args) => { + // args.calories is a number — z.coerce.number() handles string-to-number conversion from HTTP + const meal = await insertMeal(args); + return meal; + }, +}); +``` + +**Agent-only action:** + +```ts +import { z } from "zod"; +import { defineAction } from "@agent-native/core/action"; + +export default defineAction({ + description: "Navigate the UI to a view", + schema: z.object({ + view: z.string().describe("Target view"), + }), + http: false, + run: async (args) => { + await writeAppState("navigate", { command: "go", view: args.view }); + return "Navigated"; + }, +}); +``` + +## Troubleshooting + +- **Action not found** — Check that the filename matches the command name exactly. `pnpm action foo-bar` looks for `actions/foo-bar.ts`. +- **Args not parsing** — Ensure args use `--key value` or `--key=value` format. Boolean flags use `--flag` (sets value to `"true"`). +- **Frontend getting 405** — The action's `http.method` doesn't match the hook. Use `useActionQuery` for GET actions, `useActionMutation` for POST/PUT/DELETE. +- **Frontend getting undefined** — Make sure the action returns structured data, not `JSON.stringify()`. + +## Related Skills + +- **storing-data** — Actions read/write data in SQL +- **delegate-to-agent** — The agent invokes actions via `pnpm action ` +- **real-time-sync** — Database writes from actions trigger change events to update the UI +- **adding-a-feature** — Actions are area 2 of the four-area checklist +- **client-methods** — Client code uses named helpers/hooks instead of raw REST calls diff --git a/.agents/skills/adding-a-feature/SKILL.md b/.agents/skills/adding-a-feature/SKILL.md new file mode 100644 index 0000000..dd546f9 --- /dev/null +++ b/.agents/skills/adding-a-feature/SKILL.md @@ -0,0 +1,189 @@ +--- +name: adding-a-feature +description: >- + The four-area checklist every new feature must complete. Use when adding any + feature, integration, or capability to ensure the agent and UI stay in parity. +scope: dev +metadata: + internal: true +--- + +# Adding a Feature — The Four-Area Checklist + +## Rule + +Every new feature MUST update all four areas. Skipping any one breaks the agent-native contract — the agent and UI must always be equal partners. + +## Why + +Agent-native apps are defined by parity: everything the UI can do, the agent can do, and vice versa. A feature that only has UI is invisible to the agent. A feature that only has scripts is invisible to the user. A feature without app-state sync means the agent is blind to what the user is doing. + +## The Checklist + +When you add a new feature, work through these four areas in order: + +### 1. UI Component + +Build the user-facing interface — a page, component, dialog, or route. Use `useActionQuery` and `useActionMutation` from `@agent-native/core/client` to call actions for data fetching and mutations. Do not create a custom REST endpoint just so React can call action-backed data; the action endpoint already exists. + +**Auto-refresh on agent writes is non-negotiable** — when the agent mutates data, the UI must reflect the change without a manual refresh. There are two paths, and you must pick the right one: + +- **`useActionQuery` / `useActionMutation`** — covered automatically. The framework's `useDbSync` invalidates `["action"]` on every change event, so every `useActionQuery` hook refetches on agent activity. No extra wiring required. **Prefer this path.** +- **Raw `useQuery` with custom keys** — needs explicit wiring. Fold `useChangeVersions([, "action"])` from `@agent-native/core/client` into the `queryKey` and set `placeholderData: (prev) => prev`. The `action` source is the reliable signal (the agent runner emits it after every successful tool call); the resource-specific source (`"dashboards"`, `"analyses"`, `"settings"`, etc.) is bonus when emitted. Without this wiring, agent writes will be invisible until manual refresh — that breaks the framework's #1 promise. + + ```tsx + import { useChangeVersions } from "@agent-native/core/client/hooks"; + import { useQuery } from "@tanstack/react-query"; + + const v = useChangeVersions(["dashboards", "action"]); + useQuery({ + queryKey: ["dashboard", id, v], + queryFn: () => fetchDashboard(id), + placeholderData: (prev) => prev, // no flicker on refetch + }); + ``` + + See the `real-time-sync` skill for the full pattern and source catalog. + +### 2. Action + +Create an action in `actions/` using `defineAction`. This serves double duty: the agent calls it as a tool, and the UI calls it through `useActionQuery` / `useActionMutation` while the framework owns the HTTP transport. Set `http: { method: "GET" }` for read actions, leave default for writes, or set `http: false` for agent-only actions like `navigate` and `view-screen`. + +Before adding a new route or endpoint, inspect the existing actions. Reuse an +action if it already covers the business operation, extend it if the shared +contract is incomplete, or create a new `defineAction` if the agent and UI both +need the capability. Do not add pass-through `/api/*` routes that re-export +actions. If client code needs a new framework/app route, expose a named helper +or hook first and use that helper from components and docs. + +For provider-backed analysis/query/reporting integrations, do not turn every +provider endpoint or filter into a rigid action. Prefer the shared +`provider-api-catalog` / `provider-api-docs` / `provider-api-request` pattern +from `@agent-native/core/provider-api`, then add narrow convenience actions only +for workflows that truly deserve a first-class shortcut. Treat this as a +capability requirement, not a nice-to-have: convenience actions must not become +the ceiling of what the agent can ask the provider to do. Pair broad provider +access with staging or sandboxed code execution when responses may be too large +for chat context. If provider credentials live on resource/share rows, add the +scoped resolver first so broad access preserves the same ownership boundary as +the app UI. + +If the feature needs credentials, design the credential path in the same change. +Never hardcode API keys, tokens, webhook URLs, signing secrets, private +Builder/internal data, or customer data in the action, UI, seed data, fixtures, +docs, prompts, or generated extension/app content. Register required secrets, +use OAuth helpers, or read scoped values from the vault/credential store. + +If the feature involves attachments, images, recordings, screenshots, exports, +or other file-like payloads, design the upload path in the same change: +provider upload first, then URL/id/blob handle in SQL. Do not add base64/binary +columns or stuff files into `application_state`. + +**If the action produces or lists a navigable resource**, add a `link` builder that returns `{ url: buildDeepLink({ app, view, params }), label }`. External coding agents and MCP hosts (Claude / ChatGPT / Claude Code / Cowork / Codex, over MCP/A2A) then surface an "Open in … →" deep link that drops the user back into the running UI focused on the record — for free. If a compatible MCP host should render an inline review/edit surface, also add `mcpApp` with `embedApp()` so the action embeds the real React app route instead of a one-off HTML UI. The `link` builder and `mcpApp` metadata must be pure and synchronous (no I/O). Any external-agent read/ingest action must be `http: { method: "GET" }` + `readOnly: true` + `publicAgent: { expose: true, readOnly: true, requiresAuth: true }`. See the `external-agents` skill. + +### 3. Skills / Instructions + +Update `AGENTS.md` and/or create a skill in `.agents/skills/` if the feature introduces patterns the agent needs to know. At minimum, add the new actions to the action table in the template's `AGENTS.md`. + +Reusable actions are part of the app contract, not just implementation detail. When an action is useful outside one screen, update agent instructions in the same change so app agents know when to call it, which arguments matter, and what output to preserve. If the capability is workflow-heavy, cross-app, provider-backed, or has a non-obvious sequence of actions, add or update a skill instead of burying the behavior in one long `AGENTS.md` paragraph. + +Instruction examples may name secret keys like `SLACK_WEBHOOK`, but must use +placeholders such as `${keys.SLACK_WEBHOOK}` or ``. Do not paste +real keys, internal data, or customer data into instructions as examples. + +If the feature adds or changes visible UI copy, prompts, toasts, labels, empty +states, or formatting, read `internationalization` and update the app's i18n +catalogs in the same change. + +For app-backed skills, declare skill visibility in the app-skill manifest: + +- `internal` — only the app's own agents should use it. +- `exported` — marketplace installs receive it, but the app does not need it loaded internally. +- `both` — shared between the app's internal agents and exported marketplace bundles. + +### 4. Application State Sync + +Expose navigation and selection state so the agent knows what the user is looking at. Write to the `navigation` app-state key on route changes. Update the `view-screen` action to fetch relevant data for the new feature. Add a `navigate` command if the agent needs to open the new view. + +## Examples + +### Adding "compose email" to a mail app + +| Area | What to build | +| --------------- | ---------------------------------------------------------------------------------------- | +| UI | Compose panel with tabs, to/cc/bcc fields, body editor. Use `useActionQuery`/`useActionMutation` for data. | +| Action | `manage-draft` action (create/update/delete drafts), `send-email` action | +| Skills/AGENTS | Document compose state shape, draft lifecycle, action args in AGENTS.md | +| App-state sync | `compose-{id}` keys for each draft tab, `navigation` includes compose state | + +### Adding "create form" to a forms app + +| Area | What to build | +| --------------- | ---------------------------------------------------------------------------------------- | +| UI | Form builder page with drag-and-drop fields, preview, settings. Use `useActionQuery` for lists. | +| Action | `create-form` action, `update-form` action, `list-forms` action (GET) | +| Skills/AGENTS | Document form schema shape, field types, validation rules in AGENTS.md | +| App-state sync | `navigation` includes `{ view: "form-builder", formId: "..." }`, `view-screen` fetches form data | + +### Adding "chart type" to an analytics app + +| Area | What to build | +| --------------- | ---------------------------------------------------------------------------------------- | +| UI | New chart component, chart type selector in dashboard | +| Action | `create-chart` or `update-dashboard` action that sets chart type and config | +| Skills/AGENTS | Document supported chart types, config options, data requirements | +| App-state sync | `navigation` includes selected chart/dashboard, `view-screen` returns chart config | + +## Adding a new route + +Templates are single-page apps with client-side routing. The app shell (AgentSidebar + top-level nav) MUST persist across navigation — it is mounted once, either in `root.tsx` around `` or via a pathless `_app.tsx` layout route that all authed routes nest under. + +**Never wrap each new route in its own `` / ``.** That causes React to unmount the entire app shell on every navigation, reloading the agent sidebar and destroying in-progress work. + +- If the template has `` in `root.tsx` — just render page content in your new route file, nothing else. +- If the template has `app/routes/_app.tsx` (pathless layout) — name your new route `_app..tsx` to inherit the shell, or bare `.tsx` for public routes that should NOT have the shell. +- If a page needs per-route data (e.g. highlighting the active item in the sidebar), read it in the layout from `useParams()` / `useLocation()`. Don't pass it as a prop through every route file. + +See the "Client-Side Routing" section in the root `CLAUDE.md` for full details. + +## Anti-Patterns + +- **Per-route `` wrappers** — Every route file wraps its content in `` or ``. React sees a different component at the outlet on each nav and unmounts the whole shell, causing the agent sidebar to reload on every click. Mount the shell once above `` (root.tsx or `_app.tsx` pathless layout). +- **UI without actions** — The user can create forms but the agent cannot. The agent says "I don't have access to that" when it should be able to do it. +- **Actions without AGENTS.md** — The actions exist but the agent doesn't know about them because they're not documented. The agent reinvents solutions instead of using the actions. +- **Duplicate API routes** — Creating `/api/` routes for operations that actions already handle, including pass-through routes that just call or repackage an action. Use `useActionQuery`/`useActionMutation` instead. +- **Raw client route calls** — Teaching or adding `fetch("/_agent-native/...")`, + `fetch(agentNativePath(...))`, or template `/api/*` calls in components for + normal app work. Add a named client helper/hook and call that instead. +- **Features without app-state** — The agent cannot see that the user is looking at a specific form, email, or chart. It asks "which one?" instead of acting on the current selection. +- **Actions without UI** — The agent can do something the user cannot. This is less common but still breaks parity. + +## Verification + +After completing all four areas, verify: + +1. Can the user perform the operation from the UI? +2. Can the agent perform the same operation via actions? +3. Does `pnpm action view-screen` show the relevant state when the user is using the feature? +4. Can the agent navigate to the feature view via the `navigate` action? +5. Is the feature documented in AGENTS.md with action names and args? +6. Are credentials and sensitive data supplied only through approved runtime + channels, with no hardcoded real keys, tokens, webhook URLs, Builder/internal + data, or customer data? + +## One more area — sharing + +If the feature stores **user-authored resources** (documents, dashboards, forms, decks, etc.), make them ownable so they get private-by-default semantics and a share dialog for free. See the `sharing` skill. + +TL;DR: spread `ownableColumns()` into the resource table, pair it with `createSharesTable(...)`, call `registerShareableResource(...)`, wrap list/read queries with `accessFilter`, guard writes with `assertAccess`, and drop `` in the resource header. The `share-resource`, `unshare-resource`, `list-resource-shares`, and `set-resource-visibility` actions are auto-mounted framework-wide. + +## Related Skills + +- **sharing** — How to make a new resource ownable (private by default, share with users/orgs/public) +- **context-awareness** — How to expose UI state to the agent (area 4 in detail) +- **actions** — How to create actions with `defineAction` and the `http` option (area 2 in detail) +- **external-agents** — Add a `link` builder so external agents (MCP/A2A) get an "Open in … →" deep link +- **create-skill** — How to create skills for new patterns (area 3 in detail) +- **storing-data** — Where to store the feature's data +- **real-time-sync** — How the UI stays in sync when the agent writes data +- **internationalization** — How to update localized UI copy and catalogs diff --git a/.agents/skills/agent-native-docs/SKILL.md b/.agents/skills/agent-native-docs/SKILL.md new file mode 100644 index 0000000..9f085cd --- /dev/null +++ b/.agents/skills/agent-native-docs/SKILL.md @@ -0,0 +1,115 @@ +--- +name: agent-native-docs +description: >- + How to find version-matched Agent Native framework docs and source bundled in + node_modules. Use before implementing or answering questions about + @agent-native/core APIs, generated apps, workspaces, templates, or advanced + features. +scope: dev +metadata: + internal: true +--- + +# Agent Native Docs Lookup + +## Rule + +Before implementing or explaining non-trivial Agent Native behavior, read the +version-matched docs installed with `@agent-native/core`. When examples, +imports, or implementation details matter, inspect the packaged source corpus +too. + +## Why + +Generated apps and workspaces may be on a different framework version than the +public docs or model memory. The installed package is the source that matches +the app in front of you. It also includes a source-only corpus of core and +first-party templates so agents can replicate current best-practice patterns +without needing the framework monorepo checkout. + +## How + +From a generated app directory: + +```bash +pnpm action docs-search --query "" +pnpm action docs-search --slug +pnpm action docs-search --list +pnpm action source-search --query "" +pnpm action source-search --path templates/plan/AGENTS.md +pnpm action source-search --path toolkit/src/index.ts +pnpm action source-search --list +``` + +The headless `pnpm agent` loop and built-in app agent also expose a read-only +`docs-search` tool with the same `query`, `slug`, and `list` options, plus a +read-only `source-search` tool with `query`, `path`, and `list`. + +If the action runner is unavailable, search the package directly: + +```bash +rg -n "actions|automations|a2a|sharing" node_modules/@agent-native/core/docs +rg -n "defineAction|useActionQuery" node_modules/@agent-native/core/corpus +``` + +Then read `node_modules/@agent-native/core/docs/AGENTS.md` or the matching file +under `node_modules/@agent-native/core/docs/content/`. For source examples, +read files under `node_modules/@agent-native/core/corpus/core/` or +`node_modules/@agent-native/core/corpus/templates/`. + +Toolkit source is searchable at `toolkit/` in the Core corpus and also ships as +readable TypeScript under `node_modules/@agent-native/toolkit/src/`. Read +`customizing-agent-native` before taking ownership of a shared component: inspect package +source as a read-only reference, then configure, compose, or eject the smallest +supported unit into app-owned source. Preserve public actions, application +state, auth, and agent-chat runtime contracts. Never edit `node_modules` or +deep-import its private source. Manual copying is only the fallback described by +an unknown third-party package's add-style blueprint. + +## Reuse Proven Patterns (rg + cp) + +Version-matched installed source outranks web docs or memory: it is the exact +code shipping with this app. `node_modules/@agent-native/core/corpus/templates/` +holds source for every first-party template, not just the one this app started +from, so a pattern from the mail template is fair game for a tasks app. Grep +across it, then copy a whole file as a starting point instead of writing the +pattern from scratch: + +```bash +# Find how other templates solved a similar problem +rg -n "drag.*drop|reorder" node_modules/@agent-native/core/corpus/templates + +# Grab a proven action file as a starting point, then adapt names/schema +cp node_modules/@agent-native/core/corpus/templates/mail/actions/archive-email.ts \ + actions/archive-item.ts + +# Read the full framework source behind an API, not just the corpus copy +rg -n "defineAction" node_modules/@agent-native/core/src/action.ts +``` + +Copying template-level app code (actions, components, skill files) is the +expected reuse path — templates exist to be forked. This is different from +copying `core`/`toolkit` **runtime internals**: for those, follow +`customizing-agent-native`'s configure/compose/eject ladder instead of +hand-duplicating framework logic. + +## Useful Slugs + +| Need | Slugs | +| ------------------------------ | ------------------------------------------------------------- | +| Actions and typed client calls | `actions`, `client` | +| SQL, auth, access, sharing | `database`, `authentication`, `security`, `sharing` | +| UI state visible to the agent | `context-awareness` | +| Headless and chat-first apps | `pure-agent-apps`, `agent-surfaces`, `using-your-agent` | +| Automations and schedules | `automations`, `recurring-jobs` | +| Cross-app and external agents | `a2a-protocol`, `external-agents`, `mcp-protocol`, `mcp-apps` | +| Skills and instructions | `skills-guide`, `writing-agent-instructions` | + +## Don't + +- Do not rely on memory for framework APIs when package docs are present. +- Do not add custom REST wrappers for app data before reading `actions`. +- Do not add inline LLM calls before reading `using-your-agent` and + `agent-surfaces`. +- Do not copy framework runtime internals when a public API or narrow UI copy + will do; read `customizing-agent-native` for the supported override ladder. diff --git a/.agents/skills/agent-native-toolkit/SKILL.md b/.agents/skills/agent-native-toolkit/SKILL.md new file mode 100644 index 0000000..2b6444b --- /dev/null +++ b/.agents/skills/agent-native-toolkit/SKILL.md @@ -0,0 +1,177 @@ +--- +name: agent-native-toolkit +description: >- + Inventory and ownership rules for shared Agent Native workspace UI. Use + before building app chrome, settings, navigation, sharing, collaboration, + setup, history, comments, chat rails, agent UX, or repeated workspace behavior. +scope: dev +metadata: + internal: true +--- + +# Agent-Native Toolkit + +Use this skill when deciding whether app chrome, settings, collaboration, +sharing, navigation, organization, setup, history, comments, or agent UX should +be built app-locally or moved into reusable framework/toolkit pieces. + +## Core Rule + +Apps own domain models, domain actions, and product-specific workflows. The +framework and `@agent-native/toolkit` own repeated workspace behavior users +expect to work the same everywhere. + +Move behavior into shared toolkit primitives when it is: + +- workspace-wide, such as settings, nav, search, org membership, or setup +- agent-visible, such as context, actions, run progress, or proof-of-done +- governed, such as secrets, permissions, sharing, audit, or billing +- repeated by two or more apps +- not tied to one domain model + +Keep behavior app-local when the abstraction would hide important domain +language or make a simple app-specific workflow harder to understand. + +## Discover Before Building + +Before creating an app-local version of repeated workspace or agent UI: + +1. Check the reusable kits below and the installed package documentation. +2. Search installed public components and source with `docs-search` and + `source-search`. +3. Run `agent-native eject --list` to see the version-matched units published + by the packages installed in this app. +4. Read `customizing-agent-native` and configure, compose, or eject the + smallest unit instead of recreating shared behavior from memory. + +Use public package exports at runtime. Published source and ejection manifests +are discovery and ownership-transfer mechanisms, not private runtime APIs. + +## Design-System Boundary + +Every app keeps an explicit design-system seam in `app/design-system.ts` using +`defineDesignSystem` from `@agent-native/toolkit/design-system`, and supplies it +to `ToolkitProvider`. The semantic contract contains: + +- nine leaf components: `ActionButton`, `IconButton`, `TextField`, `TextArea`, + `Spinner`, `Skeleton`, `Status`, `Surface`, and `Avatar` +- eight behavior components: `Tooltip`, `Menu`, `Popover`, `Dialog`, `Picker`, + `Checkbox`, `Switch`, and `Tabs` + +These are semantic contracts, not styling contracts. An adapter may use +Tailwind/shadcn, MUI-style theme providers, React Aria, CSS modules, CSS-in-JS, +or another React design system. Do not assume CVA, utility classes, or even a +`className`; behavior adapters may supply their overlay and focus +implementation wholesale while honoring portal, focus-restoration, keyboard, +dismissal, ARIA, and z-index interoperability. + +Pages, routes, and domain components import ordinary controls through the app's +local adapter layer, usually `@/components/ui/*`. They must not import +`@agent-native/toolkit/ui/*` directly. Toolkit feature exports are still the +right home for shared workspace behavior; their presentation flows through the +registered semantic components, feature controller, and product-level slots. + +Customer adapter packages are normal npm packages imported explicitly by the +app. Never auto-detect them or load React components from JSON. Run the adapter +against `@agent-native/toolkit/conformance` in customer CI before adopting it. + +## Settings Direction + +Durable settings belong in the Settings app or a registered settings route. The +agent sidebar should not become a second settings app. It can show contextual +quick controls and deep links such as: + +- `/settings/ai` +- `/settings/connections` +- `/settings/secrets` +- `/settings/usage` +- `/settings/apps/:appId` + +The shared Account section is the canonical profile surface at +`/settings#account`. It owns the editable display name and existing avatar +control through the authenticated `get-user-profile` and `update-user-profile` +actions. Shared workspace chrome such as `OrgSwitcher` should link to this +surface rather than creating an app-local profile page. + +When adding a new API key, OAuth grant, provider connection, model selector, app +preference, notification preference, or usage/billing surface, register it as a +settings tab or app settings panel first. Only add sidebar UI when it is needed +in the moment of agent use. + +## Reusable Kits + +- **Settings kit**: a searchable settings page with account, workspace, AI + models, LLM keys, connections, secrets, usage, notifications, changelog, and + app-specific panels. Search is on by default; register a `SettingsSearchEntry` + per control so users find settings by name across tabs. +- **Collaboration kit**: Yjs docs, presence, agent presence, live cursors, + remote selections, recent edit highlights, real-time sync indicators, and + undo/redo grouping. +- **Sharing kit**: private/workspace/org/public-link access, invites, roles, + expirations, agent-readable links, and resource registration. +- **Navigation and command kit**: app shell, side nav, breadcrumbs, app switcher, + command palette entries, recent resources, pinned resources, and global search. +- **Organization kit**: folders, tags, favorites, archive, trash, ownership, + membership, and common resource metadata. +- **Setup and connections kit**: declarative setup requirements, model readiness, + missing-secret states, OAuth grants, and provider connection health. +- **Agent UX kit**: sidebar, composer, staged context, mentions, voice, human + approval, generative UI, progress, and screen-state exposure. +- **Chat history kit**: presentational chat lists and recent-chat rails belong + in Toolkit; Core keeps thread persistence, agent execution, transport, and + page-to-sidebar handoff. Use Toolkit's `ChatHistoryRail` for the standard + five-item sidebar preview and a footer row with New chat followed by an + ellipsis disclosure up to fifteen. Apps inject routing, labels, and domain + actions. +- **Agent page kit**: the full-page `/agent` surface (`AgentTabsPage` from + `@agent-native/core/client`) with Context, Files, Connections, Jobs, and + Access tabs plus a Personal/Organization scope toggle. The canonical home + for context transparency, MCP servers, A2A remote agents, recurring + jobs/automations, and external-client connect flows. See the `agent-page` + skill. +- **History and recovery kit**: audit log, activity feed, version history, + checkpoints, undo, redo, restore, and proof-of-done. +- **Comments and review kit**: anchored comments, pins, mentions, review + requests, resolved threads, agent follow-up tasks, and notifications. +- **Workflow and observability kit**: notifications, approvals, scheduled work, + background runs, recurring jobs, traces, evals, feedback, and run timelines. + +## Implementation Checklist + +When adding or refactoring one of these areas: + +1. Search existing framework and template code for duplicated UI or actions. +2. Decide the shared contract: data shape, action API, feature-level headless + controller, default view, semantic components, and product-level render + slots. +3. Keep shared data provider-agnostic and scoped by auth/sharing rules. +4. Expose the same capability to the UI and agent through actions or documented + client helpers. +5. Register app-specific labels, routes, resource adapters, and settings panels + instead of hardcoding app names in core UI. +6. Update docs and relevant skills so future apps discover the shared path. +7. Keep the component easy to adopt piecemeal: expose props/slots first and + ship readable source plus a complete ejection unit so apps can take ownership + of the smallest feature when needed. See `customizing-agent-native` for the + configure → compose → eject → propose seam ladder. +8. Keep one controller as the source of truth for the default and custom render + paths. A custom design must not fork actions, analytics, async state, or + accessibility behavior. +9. Verify the default adapter and at least one non-Tailwind adapter with the + conformance kit, including focus and portal stacking across mixed overlay + implementations. + +## Related Skills + +Read these alongside this skill when the work touches the specific area: + +- `sharing` +- `real-time-collab` +- `real-time-sync` +- `client-side-routing` +- `context-awareness` +- `onboarding` +- `secrets` +- `audit-log` +- `observability` +- `frontend-design` diff --git a/.agents/skills/capture-learnings/SKILL.md b/.agents/skills/capture-learnings/SKILL.md new file mode 100644 index 0000000..f25f657 --- /dev/null +++ b/.agents/skills/capture-learnings/SKILL.md @@ -0,0 +1,89 @@ +--- +name: capture-learnings +description: >- + Capture and apply accumulated knowledge via structured memory. Use when the + user gives feedback, shares preferences, corrects a mistake, or when you + discover something worth remembering for future conversations. +user-invocable: false +metadata: + internal: true +--- + +# Capture Learnings + +This is background knowledge, not a slash command. **Organization learnings and your personal memory index are loaded at the start of every conversation, including Slack/integration turns.** Capture durable context proactively when you learn something worth remembering. + +## How to Read & Write Memories + +Memories are stored as **resources** in the SQL database, not as files on disk. + +- **Team/organization knowledge:** shared `LEARNINGS.md`. Read it first, merge the new fact, then write the full updated file with the `resources` tool using `scope: "shared"`. Shared scope resolves to the active organization; it must never leak to another organization in the same deployment. +- **Personal knowledge:** `memory/MEMORY.md` plus `memory/.md`, written with `save-memory`. + +- **Save a memory:** `save-memory --name --type --description "..." --content "..."` +- **Read a memory:** `resource-read --path memory/.md` +- **Delete a memory:** `delete-memory --name ` +- **List all memories:** `resource-list --prefix memory/` + +## Memory Types + +| Type | Use for | +|------|---------| +| `user` | Preferences, role, personal context, contacts | +| `feedback` | Corrections, confirmed approaches, things to avoid or repeat | +| `project` | Ongoing work context, decisions, deadlines, status | +| `reference` | Pointers to external systems, URLs, API details | + +## When to Capture + +### Team and organization knowledge (`LEARNINGS.md`, shared scope) +- Canonical destinations and workflows (for example, which Content database receives a type of Slack request) +- Required intake fields, ownership, prioritization conventions, metric definitions, and approved terminology +- Durable external references that the whole team needs, including the canonical page/database URL +- Corrections or decisions that should affect every organization member's future Slack and app conversations + +Store the fact and a concise provenance link when available. Do not paste full private conversations, customer data, credentials, or secrets into learnings. Put stable always-on policy in shared `AGENTS.md`; put learned facts and evolving conventions in shared `LEARNINGS.md`. + +### User Preferences & Memory (`user`) +- **Tone and style** — "I prefer casual tone", "don't use emojis", "keep replies short" +- **Personal context** — contacts, relationships, habits ("my wife's email is...", "I'm in PST timezone") +- **Workflow preferences** — "always CC my assistant", "I like to review before sending" +- **Role and expertise** — "I'm a data scientist", "new to React" + +### Feedback & Corrections (`feedback`) +- **Corrections** — user says "no, do it this way" → capture the right way +- **Confirmed approaches** — user validates a non-obvious choice ("yes, that's perfect") +- **Repeated friction** — you hit the same issue twice; save it + +### Project Context (`project`) +- **Ongoing work** — who is doing what, why, by when +- **Decisions** — why something is done a certain way +- **Status** — current state of initiatives + +### References (`reference`) +- **External systems** — "bugs are tracked in Linear project INGEST" +- **URLs** — dashboards, documentation, tools +- **API quirks** — undocumented behavior, version-specific gotchas + +### Don't Capture +- Things obvious from reading the code +- Standard language/framework behavior +- Temporary debugging notes +- Anything already in AGENTS.md, shared LEARNINGS.md, or skills +- Ephemeral task details (use tasks/plans instead) + +## Key Rules + +1. **Save proactively — don't ask permission.** When you learn something durable, save it immediately at the correct scope. +2. **Choose scope by audience.** Organization workflow or reference → shared `LEARNINGS.md`; one person's preference/context → personal memory. +3. **One memory per topic** — e.g. `coding-style`, `project-alpha`, not one giant dump +4. **Read before updating** — if a memory exists, read it first and merge, don't overwrite +5. **Keep descriptions concise** — the index is loaded every conversation +6. **Memories are SQL-backed** — they persist across sessions and are not in git; still minimize sensitive content + +## Graduation + +When a memory is referenced repeatedly, it may belong in AGENTS.md or a skill: +- Saving a personal memory is lightweight (auto-apply, personal scope) +- Shared LEARNINGS.md is the lightweight organization knowledge layer +- Updating AGENTS.md or a skill is heavier (affects all users/agents) diff --git a/.agents/skills/create-skill/SKILL.md b/.agents/skills/create-skill/SKILL.md new file mode 100644 index 0000000..4c063b4 --- /dev/null +++ b/.agents/skills/create-skill/SKILL.md @@ -0,0 +1,221 @@ +--- +name: create-skill +description: >- + How to create new skills for an agent-native app. Use when adding a new + skill, documenting a pattern the agent should follow, or creating reusable + guidance for the agent. +scope: dev +metadata: + internal: true +--- + +# Create a Skill + +## When to Use + +Create a new skill when: + +- There's a pattern the agent should follow repeatedly. +- A multi-step workflow needs reliable, step-by-step guidance. +- You want to scaffold files from a template. + +Don't create a skill when: + +- The guidance already exists in another skill — extend it instead. +- You're documenting something the agent already knows (e.g., how to write + TypeScript). +- It's a one-off — put it in `AGENTS.md` (for everyone) or `memory/MEMORY.md` + (personal, per-user). See **capture-learnings**. + +## Interview + +Before writing the skill, answer these: + +1. **What should this skill enable?** — The core purpose in one sentence. +2. **Which of the four areas does it serve?** — UI, actions, skills/instructions, + or application state (see the **adding-a-feature** skill). Most skills are + about how to touch one or more of these correctly. +3. **When should it trigger?** — Describe the situations in natural language. + Be slightly pushy — over-triggering is better than under-triggering. +4. **Does it involve context awareness?** — Does the agent need to know what the + user is looking at? If so, reference the `navigation` application-state key and + the `view-screen` action pattern. See the **context-awareness** skill. +5. **What type of skill?** — Pattern, Workflow, or Generator (see below). +6. **Does it need supporting files?** — References (read-only context) or none. + Keep it minimal; push depth into `references/`. + +## Skill Types and Templates + +### Pattern (architectural rule) + +For documenting how things should be done: + +```markdown +--- +name: my-pattern +description: >- + [Under 40 words. What it covers AND when it should trigger.] +--- + +# [Pattern Name] + +## Rule + +[One sentence: what must be true] + +## Why + +[Why this rule exists] + +## How + +[How to follow it, with code examples] + +## Don't + +[Common violations] + +## Related Skills + +[Which skills compose with this one] +``` + +### Workflow (step-by-step) + +For multi-step implementation tasks: + +```markdown +--- +name: my-workflow +description: >- + [Under 40 words. What it covers AND when it should trigger.] +--- + +# [Workflow Name] + +## Prerequisites + +[What must be in place first] + +## Steps + +[Numbered steps with code examples] + +## Verification + +[How to confirm it worked] + +## Troubleshooting + +[Common issues and fixes] + +## Related Skills +``` + +### Generator (scaffolding) + +For creating files from templates: + +```markdown +--- +name: my-generator +description: >- + [Under 40 words. What it covers AND when it should trigger.] +--- + +# [Generator Name] + +## Usage + +[How to invoke — what args/inputs are needed] + +## What Gets Created + +[List of files and their purpose] + +## Template + +[The template content with placeholders] + +## After Generation + +[What to do next — wire up sync, add routes, register the action, etc.] + +## Related Skills +``` + +## Naming Conventions + +- Hyphen-case only: `[a-z0-9-]`, max 64 characters. +- Pattern skills: descriptive names (`storing-data`, `delegate-to-agent`). +- Workflow/generator skills: verb-noun (`create-skill`, `capture-learnings`). +- The directory name must match the `name` in frontmatter. + +## Skill Scope (runtime vs dev) + +An optional `scope` frontmatter field controls which agent loads the skill: + +- `both` (default when omitted) — loaded by connected repo agents and the + in-app runtime agent. Use for any skill both audiences should follow. +- `runtime` — loaded only by the in-app runtime agent. +- `dev` — meant for the human's coding agent (e.g. Claude Code) only. **Excluded + from the runtime agent everywhere**: not in the system-prompt skills block and + not in `docs-search` results. + +Use `scope: dev` for internal-only skills that should guide connected repo +agents such as Codex or Claude Code, but should not affect the deployed +production agent. Do not use `metadata.internal` for runtime visibility; that +field is catalog/package metadata and is intentionally not treated as +production exclusion. + +```markdown +--- +name: release-checklist +description: >- + Steps for cutting a release. Use when preparing or publishing a new version. +scope: dev +--- +``` + +Leave `scope` off for normal skills — the default (`both`) keeps them loading at +runtime, so this is fully backward compatible. To make a dev-only skill visible +to your coding agent but hidden from the runtime agent, mark it `scope: dev` and +optionally mirror it under `.claude/skills//SKILL.md` (Claude Code reads +`.claude/skills/` independently of the runtime's `.agents/skills/`). + +## Tips + +- **Keep descriptions under 40 words** — they load into context on every + conversation. State what the skill does AND when to trigger it. +- **Keep SKILL.md lean (under ~500 lines)** — move detailed content to + `references/` files (progressive disclosure). +- **Use standard markdown headings** — no XML tags or custom formats. + +## Anti-Patterns + +- **Inline LLM calls** — skills must not call LLMs directly. All AI work goes + through the agent chat (see **delegate-to-agent**). +- **Introducing databases** — data lives in SQL via Drizzle (see **storing-data**). +- **Ignoring sync** — if a skill creates data, mention wiring `useDbSync` / + `useActionQuery` so the UI updates (see **real-time-sync**). +- **Vague descriptions** — "Helps with development" won't trigger. Be specific + about _when_. +- **Pure documentation** — skills should guide action, not just explain concepts. + +## File Structure + +``` +.agents/skills/my-skill/ +├── SKILL.md # Main skill (required) +└── references/ # Optional supporting context + └── detailed-guide.md +``` + +## Related Skills + +- **adding-a-feature** — The four-area model every skill ultimately serves. +- **writing-agent-instructions** — How to write AGENTS.md and skills well for + apps and templates you ship to others. +- **capture-learnings** — When a learning graduates to reusable guidance, create + a skill; one-offs go to `AGENTS.md` or `memory/MEMORY.md`. +- **self-modifying-code** — The agent can create new skills (Tier 2 modification). diff --git a/.agents/skills/customizing-agent-native/SKILL.md b/.agents/skills/customizing-agent-native/SKILL.md new file mode 100644 index 0000000..97d49c4 --- /dev/null +++ b/.agents/skills/customizing-agent-native/SKILL.md @@ -0,0 +1,220 @@ +--- +name: customizing-agent-native +description: >- + How to configure, compose, or eject Agent Native features into app-owned + code. Use when overriding shared components or integrations, customizing a + template, adding UI to chat or headless apps, or inspecting package source. +scope: dev +metadata: + internal: true +--- + +# Customizing Agent Native + +## Rule + +Start with the app's registered design system and local UI adapters, then use +the public feature's props, semantic components, controller, product slots, +and callbacks. If those seams are not enough, use the eject CLI to transfer +the smallest supported feature into the app and make that copy app-owned. +Never edit `node_modules`, deep-import a private source file at runtime, or +patch an `@agent-native/*` package. + +Use this order: + +1. Set brand tokens with the build-time theme configuration when tokens are + enough. +2. Register company components in `app/design-system.ts` with + `defineDesignSystem`, then pass that definition to `ToolkitProvider`. +3. Configure a public feature through its semantic components, headless + controller, and product-level render slots. +4. Compose app primitives behind the app's local UI adapter layer. +5. Eject the smallest feature into app-owned source. +6. Propose a new Toolkit seam when the same override is useful in two apps. + +Ejection is for intentional product customization, not for hiding an upgrade +failure or replacing Core runtime behavior. + +## Use A Company Design System + +Keep the explicit, typed registration seam in `app/design-system.ts`: + +```tsx +import { defineDesignSystem } from "@agent-native/toolkit/design-system"; +import { + AcmeActionButtonAdapter, + AcmeDialogAdapter, +} from "./design-system/acme-adapter"; + +export const designSystem = defineDesignSystem({ + name: "Acme", + components: { + ActionButton: AcmeActionButtonAdapter, + Dialog: AcmeDialogAdapter, + }, +}); +``` + +Adapters translate the semantic Toolkit contract into company component props. +They are ordinary React components and may use MUI-style providers, React Aria, +CSS modules, CSS-in-JS, or another styling runtime. `className` and `style` are +optional interoperability hooks, not Tailwind or CVA requirements. + +The contract has nine leaf components (`ActionButton`, `IconButton`, +`TextField`, `TextArea`, `Spinner`, `Skeleton`, `Status`, `Surface`, `Avatar`) +and eight behavior components (`Tooltip`, `Menu`, `Popover`, `Dialog`, +`Picker`, `Checkbox`, `Switch`, `Tabs`). `Picker` covers select and combobox +behavior, not date picking. Behavior adapters own their portal, focus, +keyboard, dismissal, and stacking implementation while honoring the semantic +props and `portalContainer` interop contract. + +App product code imports standard controls from its local adapter path, usually +`@/components/ui/*`. Do not import `@agent-native/toolkit/ui/*` directly from +pages, routes, or domain components. That bypasses the app seam and makes a +future design-system replacement incomplete. Toolkit feature packages remain +valid imports; configure their presentation through the registered semantic +components, controller, and product slots. + +Run the published conformance kit against a complete adapter in its own CI: + +```tsx +import { assertDesignSystemConformance } from "@agent-native/toolkit/conformance"; +import { DESIGN_SYSTEM_CONTRACT_VERSION } from "@agent-native/toolkit/design-system"; + +await assertDesignSystemConformance({ + adapterName: "Acme", + components, + contractVersion: DESIGN_SYSTEM_CONTRACT_VERSION, +}); +``` + +New components and optional props are minor contract changes. Required props, +removed APIs, or behavioral changes require a new contract major. + +## Customize A Shared Feature + +Prefer feature-level headless controllers over rebuilding individual widgets. +One controller must power both the Toolkit default view and every custom render +path so behavior, actions, analytics, accessibility state, and error handling +cannot drift. Use a product-level render slot to replace the view while keeping +that controller. Eject only when the controller and slots cannot express the +required product behavior. + +## Eject A Feature + +Discover and inspect the ejection units published by installed first-party +packages before changing source: + +```bash +agent-native eject --list +agent-native eject inspect +agent-native eject --app +agent-native eject --app --apply +``` + +The command is dry-run by default. It prints the file closure, consumer import +rewrites, protected package contracts, and verification commands before +writing. `--apply` copies the package-version-matched source into the app and +rewrites only imports covered by the unit manifest. + +Every first-party public ejection unit must have a complete manifest. If one is +missing, treat that as a framework coverage bug instead of inventing a copy +recipe. For an unknown third-party package, use the emitted add-style blueprint +as a starting point. Protected runtime behavior is never copied; follow the +reported configuration, adapter, or extension seam instead. + +Applied ejections are recorded in the committed +`agent-native.ejections.json`, including package version, manifest digest, +target hashes, and import rewrites. Use the recorded state to review drift or +undo an unchanged ejection: + +```bash +agent-native eject diff --app +agent-native eject restore --app +agent-native eject restore --app --apply +``` + +Restore is hash-gated. It refuses to remove locally edited files or reverse +changed imports and prints their diff instead. Keep an edited ejection as +app-owned code, or reconcile those edits before restoring it. + +## Find The Installed Implementation + +Use the source that matches the installed package version: + +```bash +pnpm action docs-search --query "" +pnpm action source-search --query "" +rg -n "" node_modules/@agent-native/toolkit/src +rg -n "" node_modules/@agent-native/core/corpus +``` + +- Toolkit publishes readable TypeScript under + `node_modules/@agent-native/toolkit/src/` for selective UI adoption. +- Core and first-party template source lives under + `node_modules/@agent-native/core/corpus/core/` and + `node_modules/@agent-native/core/corpus/templates/`. +- Treat those trees as read-only references. Prefer `agent-native eject` so the + package manifest selects the complete source closure and rewrites imports. + Manual inspection is still useful for deciding whether to configure, + compose, eject, or propose a shared seam. + +Do not manually guess at sibling dependencies. The ejection manifest owns the +required file closure and keeps protected contracts on public package imports. + +## Preserve The Agent-Native Contract + +UI ownership may change; product contracts should not: + +- Keep app operations in `defineAction` actions and call them through + `useActionQuery`, `useActionMutation`, or another named client helper. +- Keep navigation, selection, and focused-object state visible through the + existing application-state keys. +- Keep AI work in the shared agent chat instead of adding direct LLM calls. +- Keep auth, access checks, persistence, chat transport, and agent execution in + Core. Do not copy those runtimes into the app. +- Keep local adapters narrow so package upgrades still improve every surface + the app has not intentionally taken ownership of. +- Keep page, route, and domain code on local UI adapter imports. Never reach + around the registered design system with direct Toolkit UI primitive imports. + +## App Shapes + +- **Template app:** begin with `app/design-system.ts`, its local UI adapters, + and domain UI. Use Toolkit features for repeated workspace behavior; eject + only the unit being customized. +- **Chat app:** keep `AgentChatSurface`, thread state, and chat transport in + Core. Compose or eject Toolkit presentation such as chat-history UI around it. +- **Headless app:** stay action-first while no UI is needed. When adding a UI, + use the Chat template as the on-ramp or add Toolkit components without + replacing the existing actions. +- **Workspace:** put one-app overrides in that app. Promote a local component + to `packages/shared` only when multiple workspace apps use it. + +## After Ejecting + +- Commit `agent-native.ejections.json` with the app-owned files and rewrites. +- Remove unused dependencies and imports from the ejected files. +- Keep visible text in the app's localization catalogs. +- Run the manifest verification commands plus the app's formatter, typecheck, + and focused tests. +- Re-check the installed source during future package upgrades; the app-owned + ejection does not receive upstream fixes automatically. Use `eject diff` to + distinguish recorded output from subsequent local edits. + +## Don't + +- Don't edit or import from `node_modules/@agent-native/*/src` at runtime. +- Don't add `pnpm.overrides`, patches, or resolutions for Agent Native packages. +- Don't copy Core auth, DB, action, agent-loop, or transport internals. +- Don't manually copy a first-party unit with a missing recipe; fix its manifest. +- Don't eject a full package when a prop, slot, wrapper, or smaller unit works. +- Don't fork feature state into a custom view; consume the feature's controller. + +## Related Skills + +- `agent-native-docs` — version-matched docs and source lookup +- `agent-native-toolkit` — shared-vs-app-owned architecture boundary +- `self-modifying-code` — safe app source edits +- `upgrade-agent-native` — supported package upgrade path +- `adding-a-feature` — UI/action/instructions/application-state parity diff --git a/.agents/skills/delegate-to-agent/SKILL.md b/.agents/skills/delegate-to-agent/SKILL.md new file mode 100644 index 0000000..657d9d8 --- /dev/null +++ b/.agents/skills/delegate-to-agent/SKILL.md @@ -0,0 +1,263 @@ +--- +name: delegate-to-agent +description: >- + How to delegate all AI work to the agent chat. Use when delegating AI work + from UI or scripts to the agent, when a user asks for agent behavior or + LLM-powered features, when tempted to add inline LLM calls, or when sending + messages to the agent from application code. +scope: dev +metadata: + internal: true +--- + +# Delegate All AI to the Agent + +## Rule + +The UI never calls an LLM directly. Product workflows are delegated to the +agent through the chat bridge so users can see, steer, and audit the work. +Server-side one-shot model calls are an explicit escape hatch for narrow text +transforms only; use `completeText()` from `@agent-native/core/server` when the +work intentionally does not need tools, chat history, or run state. + +## Why + +The agent is the single AI interface. It has context about the full project, can read/write any file, and can run scripts. Inline LLM calls bypass this — they create a shadow AI that doesn't know what the agent knows and can't coordinate with it. + +## How + +**From the UI (client):** + +```ts +import { sendToAgentChat } from "@agent-native/core/client/agent-chat"; + +sendToAgentChat({ + message: "Generate a summary of this document", + context: documentContent, // optional hidden context (not shown in chat UI) + submit: true, // auto-submit to the agent +}); +``` + +**From the UI, in the background:** + +```ts +import { sendToAgentChat } from "@agent-native/core/client/agent-chat"; + +sendToAgentChat({ + message: "Analyze this import and create any missing records", + context: `Import batch id: ${batchId}`, + submit: true, + newTab: true, + background: true, + openSidebar: false, +}); +``` + +This is still a full agent run: tools, actions, thread state, and run tracking +all remain active. It simply does not focus or open the sidebar. + +**From scripts (Node):** + +```ts +import { agentChat } from "@agent-native/core"; + +agentChat.submit("Process the uploaded images and create thumbnails"); +``` + +**For narrow server-side text transforms:** + +```ts +import { completeText } from "@agent-native/core/server"; + +const result = await completeText({ + systemPrompt: "Return exactly one sentiment label.", + input: messageBody, + maxOutputTokens: 12, + temperature: 0, +}); +``` + +Wrap user-facing uses in actions so the UI and agent share the same operation. +Do not call provider SDKs directly. + +**From the UI, detecting when agent is done:** + +```ts +import { useAgentChatGenerating } from "@agent-native/core/client/agent-chat"; + +function MyComponent() { + const isGenerating = useAgentChatGenerating(); + // Show loading state while agent is working +} +``` + +## `submit` vs Prefill + +The `submit` option controls whether the message is sent automatically or placed in the chat input for user review: + +| `submit` value | Behavior | Use when | +| -------------- | --------------------------------------- | ----------------------------------------------------------------------------------- | +| `true` | Auto-submits to the agent immediately | Routine operations the user has already approved | +| `false` | Prefills the chat input for user review | High-stakes operations (deleting data, modifying code, API calls with side effects) | +| omitted | Uses the project's default setting | General-purpose delegation | + +```ts +// Auto-submit: routine operation +sendToAgentChat({ message: "Update the project summary", submit: true }); + +// Prefill: let user review before sending +sendToAgentChat({ + message: "Delete all projects older than 30 days", + submit: false, +}); +``` + +## Capture user input first when generating from a prompt + +Buttons that produce new content ("New Design", "Create Dashboard", "Make Deck", "Generate Form") need the user's prompt as input. **Never hardcode a generic message** — the result will be a generic generation the user didn't actually ask for. + +**Bad** — auto-submits a placeholder message; the user never said what they wanted: + +```tsx + +``` + +**Good** — Popover anchored to the button captures the prompt, then submits it: + +```tsx + + + + + +