@codemation/agent-skills 0.4.0 → 0.5.1

package/skills/builder/gmail/SKILL.md

@@ -0,0 +1,327 @@
+---
+name: gmail
+description: Builds a Codemation workflow that reacts to Gmail and acts on it — trigger on a label, reply, modify labels, and hand attachment bytes to the document scanner. Use whenever a workflow reads from or writes to a Gmail mailbox.
+compatibility: Requires @codemation/core-nodes-gmail. A Gmail OAuth credential binds on slot "auth".
+tags: gmail, email, label, reply, attachment, trigger, integration
+uses: "@codemation/core-nodes-gmail, @codemation/core-nodes, @codemation/core"
+---
+
+# Codemation Gmail
+
+Four building blocks, imported from `@codemation/core-nodes-gmail`:
+
+- **`OnNewGmailTrigger`** — fires one item per new message (optionally on a label).
+- **`ReplyToGmailMessage`** — reply to a message by id.
+- **`ModifyGmailLabels`** — add/remove labels on a message or thread.
+- **`SendGmailMessage`** — send a fresh message (not a reply).
+
+Every node binds a Gmail OAuth credential on slot **`"auth"`** (accepted type `oauth.google.gmail`). You
+declare the slot by adding the node; the concierge binds the credential (separate skill).
+
+**Discipline:** author straight from this file, then run `verify_workflow` and fix only what it flags.
+Use `workflow-dsl` for the surrounding builder, trigger, and flow-control surface.
+
+## The default flow: trigger on a label → reply → mark processed
+
+The trigger's `labelIds` filters to messages carrying a Gmail label. `messageId` from each item targets
+the reply and the label change. Both action nodes take **config expressions** resolved per item — read
+the trigger payload with `item.json` cast to `OnNewGmailTriggerItemJson` (the class nodes' expression
+slots are item-untyped, so cast inside the `itemExpr`).
+
+```typescript
+import { createWorkflowBuilder } from "@codemation/core-nodes";
+import { itemExpr } from "@codemation/core";
+import { OnNewGmailTrigger, ReplyToGmailMessage, ModifyGmailLabels } from "@codemation/core-nodes-gmail";
+import type { OnNewGmailTriggerItemJson } from "@codemation/core-nodes-gmail";
+
+export default createWorkflowBuilder({ id: "wf.gmail.acknowledge", name: "Acknowledge inbound mail" })
+  .trigger(
+    // One item per new message carrying the "to-process" label. Slot "auth" must be bound.
+    new OnNewGmailTrigger("New email", { mailbox: "me", labelIds: ["to-process"] }),
+  )
+  .then(
+    new ReplyToGmailMessage("Acknowledge", {
+      messageId: itemExpr(({ item }) => (item.json as OnNewGmailTriggerItemJson).messageId),
+      text: itemExpr(
+        ({ item }) => `Thanks — we received "${(item.json as OnNewGmailTriggerItemJson).subject ?? "your email"}".`,
+      ),
+    }),
+  )
+  .then(
+    new ModifyGmailLabels(
+      "Mark processed",
+      {
+        target: "message", // or "thread" to label the whole conversation
+        messageId: itemExpr(({ item }) => (item.json as OnNewGmailTriggerItemJson).messageId),
+        addLabels: ["Processed"], // display name — resolved to the real label ID at runtime
+        removeLabelIds: ["UNREAD"], // system label IDs (UNREAD, INBOX, SENT, …) use addLabelIds/removeLabelIds
+      },
+      "mark-processed",
+    ),
+  )
+  .build();
+```
+
+## Trigger item shape
+
+`OnNewGmailTrigger` emits `OnNewGmailTriggerItemJson` — import the type, do not redefine it:
+
+```text
+OnNewGmailTriggerItemJson = {
+  mailbox: string;
+  historyId: string;
+  messageId: string;        // target for ReplyToGmailMessage / ModifyGmailLabels (target: "message")
+  threadId?: string;
+  subject?: string;
+  from?: string;
+  to?: string;
+  deliveredTo?: string;
+  snippet?: string;
+  internalDate?: string;
+  labelIds: readonly string[];
+  headers: Record<string, string>;
+  textPlain?: string;       // inline plain-text body — prefer this for an LLM step
+  textHtml?: string;        // inline HTML body
+  attachments: readonly GmailMessageAttachmentRecord[];  // metadata only — see below
+}
+```
+
+Trigger options: `{ mailbox: string; labelIds?: string[]; query?: string; downloadAttachments?: boolean }`.
+Set `query` for a raw Gmail search; set `downloadAttachments: true` to fetch attachment bytes.
+
+## Attachments → binary → document scanner (the important one)
+
+`item.json.attachments` is **metadata only** — bytes never ride on `item.json` (binary always goes
+through `ctx.binary`). Each record:
+
+```text
+GmailMessageAttachmentRecord = {
+  attachmentId: string;
+  filename?: string;
+  mimeType: string;         // e.g. "application/pdf"
+  size?: number;
+  binaryName: string;       // ← the KEY the bytes live under in ctx.binary
+}
+```
+
+Construct the trigger with `downloadAttachments: true` so the bytes are fetched. Then feed the **record's
+`binaryName`** to the scanner's `binaryField` — never hardcode `"data"`. The scanner node is a
+`defineNode` (`.create(config, label, id)`), and its config is item-typed, so use a typed `itemExpr` to
+pick the first PDF's `binaryName`:
+
+```typescript
+import { createWorkflowBuilder, codemationDocumentScannerNode } from "@codemation/core-nodes";
+import { itemExpr } from "@codemation/core";
+import { OnNewGmailTrigger } from "@codemation/core-nodes-gmail";
+import type { OnNewGmailTriggerItemJson } from "@codemation/core-nodes-gmail";
+
+export default createWorkflowBuilder({ id: "wf.gmail.scan-invoice", name: "Scan emailed invoice" })
+  .trigger(
+    new OnNewGmailTrigger("New invoice email", {
+      mailbox: "me",
+      labelIds: ["invoices"],
+      downloadAttachments: true, // required — fetches the bytes into ctx.binary
+    }),
+  )
+  .then(
+    codemationDocumentScannerNode.create<OnNewGmailTriggerItemJson>(
+      {
+        // Pick the first PDF attachment's binary key; fall back to "data" when none.
+        binaryField: itemExpr<string, OnNewGmailTriggerItemJson>(
+          ({ item }) => item.json.attachments.find((a) => a.mimeType === "application/pdf")?.binaryName ?? "data",
+        ),
+        analyzerType: "invoice",
+      },
+      "Scan invoice",
+      "scan-invoice",
+    ),
+  )
+  .build();
+```
+
+When there is no attachment, `attachments` is empty — branch on that (an `If` on
+`item.json.attachments.length`) rather than assuming a PDF. The scanner replaces `item.json` with
+`{ markdown, fields }`; see `document-ai`.
+
+## Gotchas
+
+- **Bind slot `"auth"`.** Every Gmail node requires a `oauth.google.gmail` credential on `"auth"`. The
+  trigger and each action node each declare their own slot — bind them all before activation.
+- **Use display names; don't fabricate IDs.** `addLabels`/`removeLabels` (on `ModifyGmailLabels`)
+  and `labelIds` (on `OnNewGmailTrigger`) accept display name strings — the plugin resolves them to
+  real Gmail label IDs at runtime via `GmailConfiguredLabelService`. **Prefer these over raw IDs**:
+  display names work across accounts; a hard-coded `"Label_123"` only works on one specific account.
+  Use `addLabelIds`/`removeLabelIds` only for system labels that have stable IDs: `"UNREAD"`,
+  `"INBOX"`, `"SENT"`, `"IMPORTANT"`, etc.
+  Never invent a Gmail label ID (`"Label_orders"`, `"Label_processed"`) — those will not exist in a
+  real account and will throw at runtime. If you don't know the real label name, use a named
+  `// TODO(setup): <description>` placeholder and call `record_decision` to surface the gap
+  (see `connect-external-systems` → "Build what works; report what's missing").
+- **Cast inside the `itemExpr` for class nodes.** `ReplyToGmailMessage` / `ModifyGmailLabels` expression
+  slots are item-untyped, so cast inside: `itemExpr(({ item }) => (item.json as OnNewGmailTriggerItemJson).messageId)`.
+- **`ItemExpr<T>` is invariant — return type must match `T` exactly.** Prefer bare `itemExpr(...)` (no explicit generics) and let TypeScript infer. When the field is typed `ItemExpr<string>` but your access is `string | undefined`, narrow it: add `?? ""` so the return is `string`. Do NOT annotate `itemExpr<string, SomeType>` and then return `string | undefined` — it looks like it should work but `ItemExpr<T>` is invariant in `T` and TypeScript will reject it. Example: `messageId: itemExpr(({ item }) => (item.json as OnNewGmailTriggerItemJson).messageId ?? "")`. For the scanner's `binaryField` (also `ItemExpr<string>`), the `?.binaryName ?? "data"` fallback already returns `string` — the explicit `itemExpr<string, T>` annotation there is fine because the return is concrete.
+- **Attachment bytes need `downloadAttachments: true`.** Without it `attachments` carries metadata but
+  `ctx.binary[binaryName]` is empty and the scanner throws.
+- **Remove `UNREAD` (or add a processed label) to avoid retriggering.** The trigger re-emits matching
+  unprocessed mail each poll.
+
+## Testing a Gmail workflow on real mail (not fabricated fixtures)
+
+Use `GmailLabelTestSource` (a `TestTriggerNodeConfig`) to run the persistent Tests-tab suite on
+real emails from a **designated test label** in the same mailbox. Each message becomes one test
+case and yields items in the **identical `OnNewGmailTriggerItemJson` shape** the live trigger emits
+— so OCR, extraction, and matching all run downstream in tests too.
+
+**The designated test label is communicated to the builder by the concierge as part of the build
+task.** If the label name is absent from the task, call `report_flag({ kind: "gap" })` and note
+that the test label must be provided. Prefer declaring the label name as a named constant or config
+the owner fills (e.g. `const TEST_LABEL = "TODO(setup): paste the test label name here"`) rather
+than leaving an unexplained placeholder string buried inside the node config. NEVER fabricate a
+label name or fall back to hard-coded fixture data.
+
+The topology that matters:
+
+```
+trigger → [shared processing: OCR / extraction / matching] → IsTestRun → {
+  true  (test):  Assertion   — checks the EXTRACTION OUTCOME, not the raw email
+  false (live):  ALL side-effects — reply + label change + ERP write, all gated together
+}
+```
+
+`IsTestRun` must go **after** the shared processing and **just before** the side-effects. If it
+forks before the extraction, the test path asserts raw trigger bytes and proves nothing.
+
+```typescript
+import { z } from "zod";
+import {
+  createWorkflowBuilder,
+  AIAgent,
+  IsTestRun,
+  Assertion,
+  CodemationChatModelConfig,
+} from "@codemation/core-nodes";
+import { itemExpr } from "@codemation/core";
+import {
+  OnNewGmailTrigger,
+  GmailLabelTestSource,
+  ModifyGmailLabels,
+  ReplyToGmailMessage,
+} from "@codemation/core-nodes-gmail";
+import type { OnNewGmailTriggerItemJson } from "@codemation/core-nodes-gmail";
+
+// ── output schema for the extraction step ─────────────────────────────────
+// messageId is passed through so the side-effect nodes can access it after extraction.
+const ExtractionSchema = z.object({
+  messageId: z.string(), // pass-through from trigger — needed by reply/label nodes
+  customer: z.string(), // recognised company/customer name; empty string when unrecognised
+  lineItems: z.array(z.object({ description: z.string(), amount: z.number() })),
+});
+type ExtractionOutput = z.infer<typeof ExtractionSchema>;
+
+// ── test label ────────────────────────────────────────────────────────────
+// Declare the label as a named constant the owner fills.
+// If the concierge did not provide it → call report_flag({ kind: "gap" }) instead.
+const TEST_LABEL = "TODO(setup): paste the test label name here";
+
+// SEPARATE top-level export — the Tests tab discovers it. NOT a second .trigger().
+export const testSource = new GmailLabelTestSource(
+  "Gmail test cases",
+  { mailbox: "me", labelIds: [TEST_LABEL], maxResults: 20 },
+  "gmail-test-source",
+);
+
+export default createWorkflowBuilder({ id: "wf.gmail.procurement", name: "Procurement intake" })
+  .trigger(new OnNewGmailTrigger("New email", { mailbox: "me", labelIds: ["procurement/inbox"] }))
+  // ── shared processing (runs in BOTH test and live paths) ────────────────
+  // Extract structured fields from the email body. Include messageId so
+  // downstream side-effect nodes (reply, label, ERP) can address the message.
+  .then(
+    new AIAgent<OnNewGmailTriggerItemJson, ExtractionOutput>({
+      name: "Extract procurement data",
+      id: "extract-procurement-data",
+      messages: [
+        {
+          role: "system",
+          content:
+            "Extract the supplier/customer name and line items from the email. " +
+            "Include the messageId field verbatim from the input. " +
+            'Reply with strict JSON matching {"messageId","customer","lineItems":[{"description","amount"}]}.',
+        },
+        {
+          role: "user",
+          content: ({ item }) =>
+            `messageId: ${item.json.messageId}\n\n${item.json.textPlain ?? item.json.snippet ?? ""}`,
+        },
+      ],
+      chatModel: new CodemationChatModelConfig("Managed AI", "low"),
+      outputSchema: ExtractionSchema,
+      guardrails: { maxTurns: 1 },
+    }),
+  )
+  // ── IsTestRun: AFTER all shared processing, JUST BEFORE side-effects ───
+  .then(new IsTestRun<ExtractionOutput>("Is this a test run?", "is-test-run"))
+  .when({
+    // true = test path: assert the EXTRACTION OUTCOME, not the raw email fields
+    true: [
+      new Assertion<ExtractionOutput>({
+        name: "Extraction outcome",
+        id: "assert-extraction-outcome",
+        assertions: (item) => [
+          {
+            // Did the model recognise a company/customer?
+            name: "customer recognised",
+            score: item.json.customer.trim().length > 0 ? 1 : 0,
+            actual: item.json.customer,
+          },
+          {
+            // Did the model extract at least one line item?
+            name: "line items extracted",
+            score: item.json.lineItems.length > 0 ? 1 : 0,
+            actual: item.json.lineItems.length,
+          },
+        ],
+      }),
+    ],
+    // false = live path: EVERY side-effect is gated here together
+    // (ERP write / create-order call belongs here too — never outside this branch)
+    false: [
+      new ReplyToGmailMessage("Acknowledge receipt", {
+        messageId: itemExpr(({ item }) => (item.json as ExtractionOutput).messageId ?? ""),
+        text: itemExpr(
+          ({ item }) =>
+            `Thank you — we received your procurement request and are processing it.` +
+            ((item.json as ExtractionOutput).customer ? ` Customer: ${(item.json as ExtractionOutput).customer}.` : ""),
+        ),
+      }),
+      new ModifyGmailLabels(
+        "Mark processed",
+        {
+          target: "message",
+          messageId: itemExpr(({ item }) => (item.json as ExtractionOutput).messageId ?? ""),
+          addLabels: ["Processed"],
+          removeLabelIds: ["UNREAD"],
+        },
+        "mark-processed",
+      ),
+      // → Add the ERP write node here (e.g. odooCreateSaleOrderNode) before marking processed.
+    ],
+  })
+  .build();
+```
+
+**Key rules:**
+
+- `GmailLabelTestSource` is a **separate `export const`**, never a second `.trigger(...)` on the chain.
+- **Place `IsTestRun` after all shared processing and just before the side-effects.** Processing steps (OCR, extraction, matching) must be upstream of `IsTestRun` so both the test path and the live path exercise the same logic. An `IsTestRun` placed right after the trigger asserts nothing useful.
+- **Assert the processing outcome, not the raw email.** The `Assertion` on the `true` branch must check the extractor's structured output (recognised customer, extracted line items) — not `subject`, `from`, or other raw trigger fields. Asserting `subject.length > 0` proves only that an email arrived; asserting `lineItems.length > 0` proves the extraction worked.
+- **Gate EVERY side-effect on the `false` branch.** Reply, label change, and ERP writes all belong on the `false` branch — together. A single gated label change while the reply or ERP write runs unconditionally defeats the purpose. If you add a node that writes to an external system, it must live on the `false` branch.
+- **Absent test label → `report_flag` + declare a required input, never a silent placeholder.** If the concierge did not provide the test label, call `report_flag({ kind: "gap" })`. When a placeholder is unavoidable, declare it as a named constant at the top of the file (as `TEST_LABEL` above) so the owner knows exactly what to fill in — never bury an opaque string inside a node config.
+- `GmailLabelTestSource` yields items in the same raw `OnNewGmailTriggerItemJson` shape as the live `OnNewGmailTrigger` — no pre-processing, no canonicalization. That's what makes the test meaningful.
+- The `caseLabel` on `GmailLabelTestSource` defaults to the email subject so each test-case row in the Tests tab is human-readable.
+
+## Read next when needed
+
+- `workflow-dsl` — builder, triggers, flow control, the per-item contract.
+- `document-ai` — the attachment → `{ markdown, fields }` handoff in full.
+- `ai-agent` — summarize or triage `item.json.textPlain` with an LLM before replying.
+- `testing` — the full `IsTestRun` + `Assertion` + `TestTrigger` pattern (trigger-agnostic).

package/skills/builder/human-in-the-loop/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: human-in-the-loop
+description: Pause a workflow for a person to approve, reject, or note before it continues, using the inboxApproval node and the builder's .humanApproval() step. The gate sits ON the live path and the run resumes on the human decision. Read this to gate any step that is expensive or irreversible to undo.
+compatibility: Designed for Codemation workflows authored with @codemation/core-nodes.
+tags: hitl, approval, inbox, review, gate
+uses: "@codemation/core-nodes, @codemation/core"
+---
+
+# Codemation Human-in-the-loop
+
+Gate a step that's expensive to undo — a payment, an external write, a customer reply — by suspending the run and waiting for a person to decide (approve / reject). Use `inboxApproval` with the builder's `.humanApproval(...)` step so the gate sits **on the live path**: a real node the items flow through, not a dangling node next to a `NoOp`. The run resumes when the reviewer decides; **rejected items never reach the downstream nodes** (the engine discards them at the gate). The same node auto-routes to the managed control-plane inbox in managed mode and the local `/dev/inbox` otherwise — no per-deployment wiring.
+
+## The gate — one step on the chain
+
+`inboxApproval` is a `defineHumanApprovalNode` node imported from `@codemation/core-nodes`. Place it with `.humanApproval(inboxApproval, config)`. The `title`/`body` fields are a static string or a callback `({ item }) => string`; the callback receives an **untyped `Item`**, so cast `item.json` to your type inside it. After the gate, the item json is `Input & { decision }` — downstream reads `item.json.decision.status`.
+
+```typescript
+import { inboxApproval } from "@codemation/core-nodes";
+
+type Invoice = { vendor: string; amount: number; currency: string };
+
+const approvalConfig = {
+  title: ({ item }: { item: { json: unknown } }) => `Approve invoice from ${(item.json as Invoice).vendor}`,
+  body: ({ item }: { item: { json: unknown } }) => {
+    const inv = item.json as Invoice;
+    return `Amount: ${inv.amount} ${inv.currency}`;
+  },
+  priority: "normal" as const, // "low" | "normal" | "high"
+  timeout: "24h",
+  onTimeout: "halt" as const, // "halt" stops the run on timeout; "auto-accept" continues
+};
+```
+
+The decision shape merged into the item: `decision.status` is `"approved" | "rejected" | "timed-out" | "auto-accepted"`, plus optional `decision.actor`, `decision.decidedAt`, and `decision.note`.
+
+## One realistic complete example
+
+Webhook receives an invoice → `.humanApproval` suspends for a reviewer → on approval the run continues and posts to accounting. The gate is the live path; rejected items stop here. This folds in the former `hitl-cp-inbox-approval` example.
+
+```typescript
+import { createWorkflowBuilder, WebhookTrigger, inboxApproval, HttpRequest } from "@codemation/core-nodes";
+import type { Item } from "@codemation/core";
+
+type Invoice = { messageId: string; vendor: string; amount: number; currency: string };
+
+export default createWorkflowBuilder({ id: "wf.invoice-approval", name: "Invoice approval (HITL)" })
+  .trigger(new WebhookTrigger("Receive invoice", { endpointKey: "invoices", methods: ["POST"] }))
+  // Suspend for a human. inboxApproval auto-routes to the CP inbox (managed) or /dev/inbox (local).
+  // title/body callbacks read the item at runtime — cast item.json to your type.
+  .humanApproval(inboxApproval, {
+    title: ({ item }: { item: Item }) => `Approve invoice from ${(item.json as Invoice).vendor}`,
+    body: ({ item }: { item: Item }) => {
+      const inv = item.json as Invoice;
+      return `Amount: ${inv.amount} ${inv.currency}\nMessage ID: ${inv.messageId}`;
+    },
+    priority: "normal",
+    timeout: "24h",
+    onTimeout: "halt",
+  })
+  // Reached only on approval — rejected items were discarded at the gate.
+  // After .humanApproval the json is Invoice & { decision }, so item.json.decision.status is typed.
+  .then(
+    new HttpRequest<Invoice & { decision: { status: string } }>("Post to accounting", {
+      method: "POST",
+      url: "https://accounting.example.com/api/invoices",
+      body: { kind: "json", data: { vendor: "${item.json.vendor}", amount: "${item.json.amount}" } },
+      id: "post-to-accounting",
+    }),
+  )
+  .build();
+```
+
+## Gate inside an agent (one line)
+
+To let an `AIAgent` request approval as a tool instead of as a fixed step, bind the same node config with `AgentToolFactory.asTool(inboxApproval.create(config, "Inbox approval"), { name, onRejected, inputSchema, outputSchema, mapInput, mapOutput })`. `onRejected: "halt"` stops the run on rejection; `onRejected: "return"` feeds the rejection back to the agent so it can adapt. Use the fixed `.humanApproval` step for a single mandatory gate; use the tool form when the agent decides whether to escalate.
+
+## Gotchas
+
+- **Gate the irreversible step.** Put `.humanApproval` immediately before the expensive write, not after it.
+- **On the live path, not beside it.** `.humanApproval` returns the cursor for the next step — chain the downstream node off it. Don't approve next to a `NoOp` and continue regardless.
+- **Cast `item.json` in title/body callbacks.** They receive an untyped `Item`; `item.json as YourType` keeps the gate compiling.
+- **Rejected items stop at the gate.** Downstream nodes only see approved (and, with `onTimeout: "auto-accept"`, auto-accepted) items — read `item.json.decision.status` if you need to branch on the outcome.

package/skills/{codemation-mcp-capabilities → builder/mcp-capabilities}/SKILL.md

@@ -1,20 +1,13 @@
 ---
-name: codemation-mcp-capabilities
+name: mcp-capabilities
 description: Discover MCP servers registered on the Codemation control plane. Use before authoring agent workflows that reference mcpServers to find available server ids and their credential requirements.
-compatibility: Requires an installation paired with a connected control plane (Sprint 2+).
+compatibility: Requires an installation paired with a connected control plane.
 tags: mcp, agent, tool
 ---
 
 # Codemation MCP Capabilities
 
-## Mental model
-
-MCP servers extend `AIAgent` with tool access to external services (Gmail, Sheets, etc.). Server ids and credential requirements come from the control-plane registry — they are not hard-coded in framework code. The agent's `mcpServers` array contains stable server id slugs; each declared server surfaces a credential slot the operator must bind in the canvas before activation.
-
-## When to use / when NOT
-
-Use this skill before writing `agent({ mcpServers: ["..."] })` to discover available server ids and their credential types.
-Do not use for general AIAgent authoring — read `codemation-ai-agent-node` for that.
+MCP servers extend `AIAgent` with tool access to external services (Gmail, Sheets, etc.). Server ids and credential requirements come from the control-plane registry — they are not hard-coded in framework code. The agent's `mcpServers` array contains stable server id slugs; each declared server surfaces a credential slot the operator must bind in the canvas before activation. Use this skill before writing `agent({ mcpServers: ["..."] })` to discover available server ids and their credential types.
 
 ## Managed mode: CP-loaded MCP servers (default path)
 
@@ -30,7 +23,7 @@ For a full wired example — cron workflow + AIAgent + mcpServers — use your h
 
 ## Non-managed: plugin-declared MCP servers
 
-In self-hosted / non-managed deployments, MCP servers can also be declared via `mcpServers: [...]` in a `definePlugin(...)` call. This is a framework-author pattern — do not use it in managed-mode workflows. See `references/plugin-anatomy.md` in the `codemation-plugin-development` skill for the plugin declaration syntax.
+In self-hosted / non-managed deployments, MCP servers can also be declared via `mcpServers: [...]` in a `definePlugin(...)` call. This is a framework-author pattern — do not use it in managed-mode workflows. See `references/plugin-anatomy.md` in the `plugin-development` skill for the plugin declaration syntax.
 
 ## Decision branches & gotchas
 

package/skills/{codemation-mcp-capabilities → builder/mcp-capabilities}/references/agent-with-mcp.ts

@@ -6,7 +6,7 @@
  *
  * Cron / webhook workflows use createWorkflowBuilder({id, name}).trigger(new XxxTrigger(...))
  * and chain with .then(new SomeNodeConfig(...)). The fluent .map/.if/.agent helpers are
- * only available via workflow("id").manualTrigger(...). See codemation-workflow-dsl skill.
+ * only available via workflow("id").manualTrigger(...). See workflow-dsl skill.
  *
  * `mcpServers` is a plain array of server ids. Each declared server surfaces a credential
  * slot on the materialized MCP connection node (same shape as ChatModel/Tool connection