@trigger.dev/sdk 0.0.0-python-preview-20250226140121 → 0.0.0-rc-4-8-0-20261021151928

package/skills/trigger-authoring-chat-agent/SKILL.md

@@ -0,0 +1,308 @@
+---
+name: trigger-authoring-chat-agent
+description: >
+  Author and run a durable AI chat agent with chat.agent from @trigger.dev/sdk/ai: the per-turn
+  run loop, why you MUST take streamText from the run argument rather than importing it from ai,
+  returning a StreamTextResult vs calling chat.pipe(), the two server actions (chat.createStartSessionAction +
+  auth.createPublicToken), and wiring useChat to useTriggerChatTransport. Load this when building,
+  modifying, or debugging a chat backend (the agent task or its lifecycle hooks) or its React
+  transport, when declaring typed tools or custom data parts, or when migrating a plain AI SDK
+  streamText route to chat.agent.
+type: core
+library: trigger.dev
+sources:
+  - docs/ai-chat/overview.mdx
+  - docs/ai-chat/quick-start.mdx
+  - docs/ai-chat/how-it-works.mdx
+  - docs/ai-chat/backend.mdx
+  - docs/ai-chat/frontend.mdx
+  - docs/ai-chat/reference.mdx
+  - docs/ai-chat/types.mdx
+  - docs/ai-chat/tools.mdx
+  - docs/ai-chat/lifecycle-hooks.mdx
+  - docs/ai-chat/error-handling.mdx
+---
+
+# Authoring a chat agent
+
+A `chat.agent` runs an entire conversation as one long-lived Trigger.dev task. It wakes when a
+message arrives, freezes when none do, and in-memory state survives page refreshes, deploys, idle
+gaps, and crashes. Your code is the loop you would write anyway: messages in, `streamText` out.
+There are no API routes. The frontend talks to the agent through a `TriggerChatTransport`, so
+history accumulates server-side and the client ships only the new message each turn.
+
+Works with Vercel AI SDK v5, v6, or v7. On v7 also install `@ai-sdk/otel` so model calls are traced
+(the SDK registers it for you).
+
+## Setup
+
+Three pieces: the agent task, two server actions, and the frontend transport.
+
+### 1. Define the agent
+
+```ts trigger/chat.ts
+import { chat } from "@trigger.dev/sdk/ai";
+import { streamText, stepCountIs } from "ai";
+import { anthropic } from "@ai-sdk/anthropic";
+
+export const myChat = chat.agent({
+  id: "my-chat",
+  // `streamText` below is the SDK's, from the run argument. See "Common mistakes".
+  run: async ({ messages, signal, streamText }) =>
+    streamText({
+      model: anthropic("claude-sonnet-4-5"),
+      messages,
+      abortSignal: signal,
+      stopWhen: stepCountIs(15),
+    }),
+});
+```
+
+`run` receives `messages` already converted to `ModelMessage[]` (the SDK converts the frontend's
+`UIMessage[]` for you) plus a `signal` that aborts on stop or cancel. Returning the
+`StreamTextResult` auto-pipes it to the frontend.
+
+### 2. Add two server actions
+
+Both run on your server, so the browser never holds your environment secret key. This is also
+where per-user / per-plan authorization and any paired DB writes live.
+
+```ts app/actions.ts
+"use server";
+import { auth } from "@trigger.dev/sdk";
+import { chat } from "@trigger.dev/sdk/ai";
+
+// Creates the Session + first run, returns a session PAT. Idempotent on (env, chatId).
+export const startChatSession = chat.createStartSessionAction("my-chat");
+
+// Pure mint. The transport calls this on 401/403 to refresh an expired token.
+export async function mintChatAccessToken(chatId: string) {
+  return auth.createPublicToken({
+    scopes: { read: { sessions: chatId }, write: { sessions: chatId } },
+    expirationTime: "1h",
+  });
+}
+```
+
+### 3. Wire the frontend
+
+```tsx app/components/chat.tsx
+"use client";
+import { useState } from "react";
+import { useChat } from "@ai-sdk/react";
+import { useTriggerChatTransport } from "@trigger.dev/sdk/chat/react";
+import type { myChat } from "@/trigger/chat";
+import { mintChatAccessToken, startChatSession } from "@/app/actions";
+
+export function Chat() {
+  const transport = useTriggerChatTransport<typeof myChat>({
+    task: "my-chat", // typeof myChat gives compile-time task-id validation
+    accessToken: ({ chatId }) => mintChatAccessToken(chatId),
+    startSession: ({ chatId, clientData }) => startChatSession({ chatId, clientData }),
+  });
+
+  const { messages, sendMessage, stop, status } = useChat({ transport });
+  const [input, setInput] = useState("");
+  // render messages, a form that calls sendMessage({ text: input }),
+  // and a Stop button (onClick={stop}) while status === "streaming".
+}
+```
+
+The transport is memoized (created once, reused across renders). Passing `typeof myChat` flows the
+agent's message type through `useChat`.
+
+## Core patterns
+
+### 1. Return vs pipe
+
+Return the `streamText` result from `run` for the simple case. When `streamText` is called deep
+inside nested helpers, call `await chat.pipe(result)` from anywhere in the task instead, and let
+`run` resolve `void`.
+
+```ts
+import { chat, type ChatStreamText } from "@trigger.dev/sdk/ai";
+import { anthropic } from "@ai-sdk/anthropic";
+import type { ModelMessage } from "ai";
+
+export const agentChat = chat.agent({
+  id: "agent-chat",
+  run: async ({ messages, streamText }) => {
+    await runAgentLoop(messages, streamText); // don't return; pipe inside
+  },
+});
+
+// A loop factored out of `run` takes `streamText` as an argument, so it keeps the
+// managed options. `ChatStreamText` (from `@trigger.dev/sdk/ai`) types the parameter.
+// `chat.toStreamTextOptions()` is the alternative when threading it down is impractical.
+async function runAgentLoop(messages: ModelMessage[], streamText: ChatStreamText) {
+  const result = streamText({
+    model: anthropic("claude-sonnet-4-5"),
+    messages,
+  });
+  await chat.pipe(result); // works from anywhere in the task
+}
+```
+
+### 2. Typed tools (declare on config AND pass back)
+
+Declare tools on `chat.agent({ tools })`, read them back typed from the `run()` payload, and pass
+that set as `tools`. One declaration flows everywhere.
+
+```ts
+import { tool, stepCountIs } from "ai";
+import { z } from "zod";
+
+const tools = {
+  searchDocs: tool({
+    description: "Search the docs.",
+    inputSchema: z.object({ query: z.string() }),
+    execute: async ({ query }) => searchIndex(query),
+  }),
+};
+
+export const myChat = chat.agent({
+  id: "my-chat",
+  tools, // so toModelOutput survives across turns
+  run: async ({ messages, tools, signal, streamText }) =>
+    streamText({
+      model: anthropic("claude-sonnet-4-5"),
+      messages,
+      tools, // same set, handed back typed
+      abortSignal: signal,
+      stopWhen: stepCountIs(15),
+    }),
+});
+```
+
+`tools` also accepts a function `(event) => ToolSet` resolved per turn, where `event` carries
+`chatId`, `turn`, `continuation`, and `clientData`.
+
+### 3. Custom data parts (persisted vs transient)
+
+`data-*` parts written via `chat.response.write()` in `run()` (or `writer.write()` in hooks)
+persist into `responseMessage.parts` and surface in `onTurnComplete`. Add `transient: true` to
+stream them without persisting. Writes via `chat.stream` are always ephemeral.
+
+```ts
+// In run() - persists, surfaces in onTurnComplete's responseMessage
+chat.response.write({ type: "data-context", data: { searchResults } });
+
+// In a hook via writer - streams but does NOT persist
+writer.write({ type: "data-progress", id: "search", data: { percent: 50 }, transient: true });
+```
+
+### 4. Custom UIMessage type, client data, and builder hooks
+
+For typed `data-*` parts or a tool map, build the agent through `chat.withUIMessage<T>()` and
+`chat.withClientData({ schema })`. Builder methods chain in any order; builder hooks run before the
+matching task hook. `streamOptions` becomes the default `uiMessageStreamOptions` (shallow-merged,
+agent wins).
+
+```ts
+export const myChat = chat
+  .withUIMessage<MyChatUIMessage>({ streamOptions: { sendReasoning: true } })
+  .withClientData({ schema: z.object({ userId: z.string() }) })
+  .agent({
+    id: "my-chat",
+    tools: myTools,
+    onTurnStart: async ({ uiMessages, writer }) => {
+      writer.write({ type: "data-turn-status", data: { status: "preparing" } });
+    },
+    run: async ({ messages, tools, signal, streamText }) =>
+      streamText({ model, messages, tools, abortSignal: signal }),
+  });
+```
+
+Build `MyChatUIMessage` as `UIMessage<unknown, MyDataTypes, InferUITools<typeof tools>>` (or, for
+tools only, `InferChatUIMessageFromTools<typeof tools>` from `@trigger.dev/sdk/ai`). On the
+frontend, narrow `useChat` with `InferChatUIMessage<typeof myChat>` from `@trigger.dev/sdk/chat/react`.
+
+### 5. Lifecycle hooks and stop
+
+`chat.agent` accepts hooks that fire in a fixed per-turn order:
+
+```text
+onValidateMessages -> storage.loadContext (or the deprecated hydrateMessages)
+  -> onChatStart (chat's first message only)
+  -> onTurnStart -> run() -> onBeforeTurnComplete -> onTurnComplete -> storage.save
+```
+
+`onBoot` fires once per worker process (every fresh boot, including continuation runs) and is where
+`chat.local`, DB connections, and per-process state belong. `onChatStart` fires only on the chat's
+first message. Suspend/resume use `onChatSuspend` / `onChatResume`. Config options include
+`tools`, `clientDataSchema`, `maxTurns` (100), `turnTimeout` ("1h"), `idleTimeoutInSeconds` (30),
+`uiMessageStreamOptions`, and `exitAfterPreloadIdle`. There is no generic `retry`; `chat.agent`
+runs with `maxAttempts: 1` internally.
+
+Stop depends on it: the `signal` passed to `run` aborts on stop or cancel. Forward it as
+`abortSignal` to `streamText`, or the Stop button updates the UI while the model keeps generating
+server-side.
+
+```ts
+run: async ({ messages, signal, streamText }) =>
+  streamText({ model, messages, abortSignal: signal, stopWhen: stepCountIs(15) });
+```
+
+### 6. Migrating from a plain AI SDK `streamText` route
+
+There is no API route in this model. The transport replaces the route round-trip, so:
+
+- Delete the route handler. Move per-request auth into the two server actions from Setup step 2.
+- Move the `streamText` call into `run`. It already receives pre-converted `ModelMessage[]`.
+- Return the `StreamTextResult` (it auto-pipes) and take `streamText` from `run`'s argument, not from `ai`.
+- On the client, swap the `api` URL for `useTriggerChatTransport`; `useChat` stays the same shape.
+
+## Common mistakes
+
+- **CRITICAL: calling the `streamText` imported from `ai`.**
+  ```ts
+  // Wrong - compaction / steering / background injection silently no-op
+  import { streamText } from "ai";
+  run: async ({ messages, signal }) => streamText({ model, messages, abortSignal: signal });
+  // Correct - the run argument's streamText carries the managed options
+  run: async ({ messages, signal, streamText }) => streamText({ model, messages, abortSignal: signal });
+  ```
+  The SDK's one carries the `prepareStep` behind compaction, mid-turn steering and background
+  injection, the system prompt from `chat.prompt()` or `chat.agent({ system })`, the registry-resolved
+  model, and telemetry. The imported one carries none of it, with no error.
+  `...chat.toStreamTextOptions()` does the same job by hand, and is what a custom agent has to use,
+  since it has no `run` argument. A `chat.headStart` route gets a bound `streamText` too, and there it
+  also owns `messages`, `prompt`, `stopWhen` and `abortSignal`. Spreading it and then re-setting
+  `tools` or `prepareStep` replaces the managed ones; the run argument's `streamText` merges `tools`
+  and composes `prepareStep` instead.
+
+- **Declaring tools only on `streamText`.** Also declare them on `chat.agent({ tools })`, read them
+  back from `run`, and pass that set as `tools`. Otherwise each tool's
+  `toModelOutput` runs on turn 1 but is dropped when history is re-converted on later turns.
+
+- **Not forwarding `signal` for stop.** Without `abortSignal: signal`, Stop updates the UI but the
+  model keeps generating server-side.
+
+- **Initializing `chat.local` in `onChatStart`.** Initialize it in `onBoot`. `onChatStart` fires
+  once per chat, so continuation runs skip it and crash with
+  `chat.local can only be modified after initialization`. `onBoot` fires on every fresh worker.
+
+- **Minting tokens in the browser.** Never expose the environment secret key client-side. Mint via
+  the two server actions; the transport calls them.
+
+- **Clearing `lastEventId` on `chat.endRun()`.** Keep the cursor for the Session lifetime; clear it
+  only when the Session itself closes. It is sessionId-keyed, so clearing forces a resubscribe from
+  `seq_num=0` that can hit the prior turn's stale `turn-complete` and close the stream empty.
+
+- **Returning the raw error from `uiMessageStreamOptions.onError`.** It leaks internals (keys,
+  stack traces). Return a sanitized string instead.
+
+## References
+
+- `trigger-chat-agent-advanced` skill - lifecycle hooks in depth, sessions, raw-task primitives
+  (`chat.createSession`, `chat.customAgent`, `chat.stream`), compaction, HITL approvals, recovery.
+- `trigger-realtime-and-frontend` skill - Realtime hooks and frontend streaming beyond the chat transport.
+- `trigger-authoring-tasks` skill - base `task()` semantics, `ctx`, and standard lifecycle hooks.
+
+Reference docs ship beside this skill in the same package, read them locally (no network), pinned to your installed version. The `sources:` frontmatter above lists every doc this skill draws from, all under `@trigger.dev/sdk/docs/ai-chat/`. Start with `quick-start.mdx`, `backend.mdx`, `tools.mdx`, `types.mdx`, `frontend.mdx`.
+
+A `chat.agent` is a Trigger.dev task, so it builds and deploys like any other. For `trigger.config.ts` and build extensions (Prisma, Playwright, Python, FFmpeg, etc. — e.g. when a tool needs them), read the bundled config docs under `@trigger.dev/sdk/docs/config/` (extensions are in `config/extensions/`, starting with `overview.mdx`).
+
+## Version
+
+This skill is bundled inside `@trigger.dev/sdk` and read directly from `node_modules`, so it always matches your installed SDK version (see the adjacent `package.json`). The full documentation for these APIs ships alongside it under `@trigger.dev/sdk/docs/`.

package/skills/trigger-authoring-tasks/SKILL.md

@@ -0,0 +1,254 @@
+---
+name: trigger-authoring-tasks
+description: >
+  Covers writing backend Trigger.dev tasks with @trigger.dev/sdk: defining task() and
+  schemaTask(), the run function and its ctx, retries, waits, queues and concurrency,
+  idempotency keys, run metadata, logging, triggering other tasks (and the Result shape),
+  scheduled/cron tasks, and the essentials of trigger.config.ts. Load this whenever you are
+  authoring or editing code inside a /trigger directory, defining a task, or writing backend
+  code that triggers tasks. Realtime/React hooks and AI chat are covered by separate skills.
+type: core
+library: trigger.dev
+sources:
+  - docs/tasks/overview.mdx
+  - docs/tasks/schemaTask.mdx
+  - docs/tasks/scheduled.mdx
+  - docs/triggering.mdx
+  - docs/queue-concurrency.mdx
+  - docs/idempotency.mdx
+  - docs/runs/metadata.mdx
+  - docs/logging.mdx
+  - docs/errors-retrying.mdx
+  - docs/wait.mdx
+  - docs/wait-for.mdx
+  - docs/wait-until.mdx
+  - docs/wait-for-token.mdx
+  - docs/context.mdx
+  - docs/config/config-file.mdx
+---
+
+# Authoring Trigger.dev Tasks
+
+Tasks are functions that can run for a long time with strong resilience to failure. Define them in files under your `/trigger` directory. Always import from `@trigger.dev/sdk`. Never import from `@trigger.dev/sdk/v3` (deprecated alias) or `@trigger.dev/core`.
+
+## Setup
+
+```ts
+// /trigger/hello-world.ts
+import { task } from "@trigger.dev/sdk";
+
+export const helloWorld = task({
+  id: "hello-world", // unique within the project
+  run: async (payload: { message: string }, { ctx }) => {
+    console.log(payload.message, "attempt", ctx.attempt.number);
+    return { ok: true }; // must be JSON serializable
+  },
+});
+```
+
+The `run` function receives the payload and a second argument with `ctx` (run context), an abort `signal`, and a deprecated `init` output. The return value is the task output and must be JSON serializable.
+
+## Core patterns
+
+### 1. Validate the payload with `schemaTask`
+
+`schema` accepts a Zod / Yup / Superstruct / ArkType / valibot / typebox parser or a custom `(data: unknown) => T` function. A validation failure throws `TaskPayloadParsedError` and skips retrying.
+
+```ts
+import { schemaTask } from "@trigger.dev/sdk";
+import { z } from "zod";
+
+export const createUser = schemaTask({
+  id: "create-user",
+  schema: z.object({ name: z.string(), age: z.number() }),
+  run: async (payload) => ({ greeting: `Hi ${payload.name}` }),
+});
+```
+
+### 2. Configure retries and abort early
+
+The default `maxAttempts` is 3. Throw `AbortTaskRunError` to stop retrying immediately. Task-level `retry` overrides the config-file defaults.
+
+```ts
+import { task, AbortTaskRunError } from "@trigger.dev/sdk";
+
+export const charge = task({
+  id: "charge",
+  retry: { maxAttempts: 5, factor: 1.8, minTimeoutInMs: 500, maxTimeoutInMs: 30_000, randomize: true },
+  run: async (payload: { amount: number }) => {
+    if (payload.amount <= 0) throw new AbortTaskRunError("Invalid amount"); // no retry
+    // work that may throw and retry
+  },
+});
+```
+
+For finer control, `catchError: async ({ payload, error, ctx, retryAt }) => {...}` can return `{ skipRetrying: true }`, `{ retryAt: Date }`, or `undefined` (use normal logic). `retry.onThrow`, `retry.fetch`, also exist for in-task retrying.
+
+### 3. Trigger another task and handle the Result
+
+From inside a task use `yourTask.triggerAndWait(payload)`. The result is a Result object that you must check (`ok`), or `.unwrap()` to throw on failure.
+
+```ts
+export const parentTask = task({
+  id: "parent-task",
+  run: async () => {
+    const result = await childTask.triggerAndWait({ data: "x" });
+    if (result.ok) return result.output; // typed child output
+    console.error("child failed", result.error);
+    // or: const output = await childTask.triggerAndWait({ data: "x" }).unwrap();
+  },
+});
+```
+
+`SubtaskUnwrapError` carries `runId`, `taskId`, and `cause`. For fan-out use `childTask.batchTriggerAndWait([{ payload: a }, { payload: b }])`; the result has a `.runs` array, each entry `{ ok, id, output?, error?, taskIdentifier }`.
+
+### 4. Trigger from backend code with a type-only import
+
+Outside a task, import the task type only and trigger by id. Do not import the task instance into backend bundles.
+
+```ts
+import { tasks } from "@trigger.dev/sdk";
+import type { emailSequence } from "~/trigger/emails";
+
+const handle = await tasks.trigger<typeof emailSequence>(
+  "email-sequence",
+  { to: "a@b.com", name: "Ada" },
+  { delay: "1h" }
+);
+```
+
+`tasks.batchTrigger` and `batch.trigger([{ id, payload }])` cover batches. Trigger options include `delay`, `ttl`, `idempotencyKey`, `idempotencyKeyTTL`, `debounce`, `queue`, `concurrencyKey`, `maxAttempts`, `tags`, `metadata`, `priority`, `region`, and `machine`. Inspect runs with `runs.retrieve`, `runs.cancel`, and `runs.reschedule`.
+
+### 5. Idempotency keys
+
+`idempotencyKeys.create(key, { scope })` returns a 64-char hashed key. A raw string key defaults to `"run"` scope (v4.3.1+); for once-ever behavior use `scope: "global"`.
+
+```ts
+import { idempotencyKeys, task } from "@trigger.dev/sdk";
+
+export const processOrder = task({
+  id: "process-order",
+  run: async (payload: { orderId: string; email: string }) => {
+    const key = await idempotencyKeys.create(`confirm-${payload.orderId}`);
+    await sendEmail.trigger({ to: payload.email }, { idempotencyKey: key });
+  },
+});
+```
+
+### 6. Waits and run metadata
+
+`wait.for({ seconds })` and `wait.until({ date })` durably pause the run. `metadata.*` is readable and writable only inside `run()`; updates are synchronous and chainable (`set`, `del`, `replace`, `append`, `remove`, `increment`, `decrement`).
+
+```ts
+import { task, metadata, wait } from "@trigger.dev/sdk";
+
+export const importer = task({
+  id: "importer",
+  run: async (payload: { rows: unknown[] }) => {
+    metadata.set("status", "processing").set("total", payload.rows.length);
+    await wait.for({ seconds: 5 });
+    metadata.set("status", "complete");
+  },
+});
+```
+
+For human-in-the-loop, `wait.createToken({ timeout, tags })` returns `{ id, url, publicAccessToken, ... }`; resume with `wait.forToken<T>(token: string | { id: string })` which returns `{ ok, output?, error? }` (or `.unwrap()`), and complete it elsewhere with `wait.completeToken(tokenId, output)`. Metadata max is 256KB and is not propagated to child tasks; push values to a parent with `metadata.parent.*` / `metadata.root.*`. (`metadata.stream` is deprecated since 4.1.0 in favor of `streams.pipe()`.)
+
+### 7. Scheduled (cron) tasks
+
+```ts
+import { schedules } from "@trigger.dev/sdk";
+
+export const dailyReport = schedules.task({
+  id: "daily-report",
+  cron: { pattern: "0 5 * * *", timezone: "Asia/Tokyo" },
+  run: async (payload) => {
+    console.log("scheduled at", payload.timestamp, "next", payload.upcoming);
+  },
+});
+```
+
+The payload includes `timestamp`, `lastTimestamp`, `timezone`, `scheduleId`, `externalId`, and `upcoming`. Attach schedules dynamically with `schedules.create({ task, cron, timezone?, externalId?, deduplicationKey })` (the dedup key is required and per-project), plus `retrieve / list / update / activate / deactivate / del / timezones`.
+
+### 8. Queues and concurrency
+
+Set `queue: { concurrencyLimit }` on a task, or share a queue across tasks:
+
+```ts
+import { queue, task } from "@trigger.dev/sdk";
+
+export const emails = queue({ name: "emails", concurrencyLimit: 5 });
+
+export const sendEmail = task({ id: "send-email", queue: emails, run: async () => {} });
+```
+
+At trigger time override with `{ queue: "queue-name" }` and add `concurrencyKey` for per-tenant queues. Manage queues with `queues.list / retrieve / pause / resume / overrideConcurrencyLimit / resetConcurrencyLimit`.
+
+### 9. `trigger.config.ts` essentials
+
+```ts
+import { defineConfig } from "@trigger.dev/sdk";
+
+export default defineConfig({
+  project: "<project ref>",
+  dirs: ["./trigger"],
+  machine: "small-1x",
+  retries: {
+    enabledInDev: false,
+    default: { maxAttempts: 3, factor: 2, minTimeoutInMs: 1000, maxTimeoutInMs: 10000, randomize: true },
+  },
+});
+```
+
+`build.external` controls which packages stay out of the bundle. Build extensions (`additionalFiles`, `prismaExtension`, `puppeteer`, `playwright`, `ffmpeg`, `pythonExtension`, `aptGet`, `syncEnvVars`, etc.) come from `@trigger.dev/build`. `telemetry` configures instrumentations and exporters. Each extension has its own setup doc, all bundled under `@trigger.dev/sdk/docs/config/extensions/` (start with `overview.mdx`); read the one you need before wiring it up rather than guessing the API.
+
+### Logging
+
+`logger.debug / log / info / warn / error(message, dataRecord?)` write structured logs; `logger.trace(name, async (span) => {...})` adds a span. Module-level metrics use `otel.metrics.getMeter(name)`.
+
+## Common mistakes
+
+1. **CRITICAL: Treating the wait result as the output.** `triggerAndWait` and `wait.forToken` return a Result object, not the raw output.
+   - Wrong: `const out = await childTask.triggerAndWait(p); use(out.foo);`
+   - Correct: `const r = await childTask.triggerAndWait(p); if (r.ok) use(r.output.foo);` (or `.unwrap()`).
+
+2. **Wrapping `triggerAndWait` / `batchTriggerAndWait` / `wait` in `Promise.all`.**
+   - Wrong: `await Promise.all([childTask.triggerAndWait(a), childTask.triggerAndWait(b)]);`
+   - Correct: `await childTask.batchTriggerAndWait([{ payload: a }, { payload: b }]);` (or a sequential for-loop).
+
+3. **Importing the task instance into backend code.**
+   - Wrong: `import { emailSequence } from "~/trigger/emails";` in a route handler.
+   - Correct: `import type { emailSequence }` plus `tasks.trigger<typeof emailSequence>("email-sequence", payload)`.
+
+4. **Calling `metadata.set/get` outside `run()`.**
+   - Wrong: setting metadata at module scope or in unrelated backend code (a no-op; `get` returns `undefined`).
+   - Correct: call inside `run()` or a task lifecycle hook.
+
+5. **Assuming child tasks inherit the parent's queue or metadata.**
+   - Wrong: expecting a subtask to share the parent's `concurrencyLimit` or see its metadata.
+   - Correct: subtasks run on their own queue; pass metadata explicitly via `{ metadata: metadata.current() }`, or push up with `metadata.parent.*`.
+
+6. **Bundling native/WASM packages.**
+   - Wrong: leaving `sharp`, `re2`, `sqlite3`, or WASM packages in the default bundle.
+   - Correct: add them to `build.external` in `trigger.config.ts`.
+
+7. **Relying on a raw string idempotency key being global.**
+   - Wrong: `trigger(p, { idempotencyKey: "welcome-email" })` expecting once-ever (true only in v4.3.0 and earlier).
+   - Correct: `await idempotencyKeys.create("welcome-email", { scope: "global" })`.
+
+## References
+
+Sibling skills:
+
+- **trigger-realtime-and-frontend** for subscribing to runs and triggering from the frontend with React hooks.
+- **trigger-authoring-chat-agent** and **trigger-chat-agent-advanced** for building AI chat agents.
+
+Reference docs ship beside this skill in the same package, read them locally (no network), pinned to your installed version. The `sources:` frontmatter above lists every doc this skill draws from, all under `@trigger.dev/sdk/docs/`. Start with:
+
+- `@trigger.dev/sdk/docs/tasks/overview.mdx`
+- `@trigger.dev/sdk/docs/triggering.mdx`
+- `@trigger.dev/sdk/docs/config/config-file.mdx`
+
+## Version
+
+This skill is bundled inside `@trigger.dev/sdk` and read directly from `node_modules`, so it always matches your installed SDK version (see the adjacent `package.json`). The full documentation for these APIs ships alongside it under `@trigger.dev/sdk/docs/`.