@keystrokehq/skills 0.0.3 → 0.0.6

package/{keystroke-trigger-authoring → src/keystroke-trigger-authoring}/references/patterns.md

@@ -13,11 +13,9 @@ File layout reminder:
 ## Shared advanced fields
 
 ```ts
-import type { ExecutionIdentityPolicy } from '@keystrokehq/core/types';
-
-const executionIdentityPolicy: ExecutionIdentityPolicy = {
+const executionIdentityPolicy = {
   subjectMode: 'requiredWhenUserProvidedCredential',
-};
+} as const;
 ```
 
 Use `executionIdentityPolicy` when the trigger should require a subject only in specific credential cases. Use `modeDefault` when the trigger should default to a specific trigger mode such as `'subscribable'`.
@@ -29,7 +27,7 @@ import { cronTrigger } from '@keystrokehq/core';
 import { z } from 'zod';
 
 export const nightlyDigestTrigger = cronTrigger({
-  name: 'Nightly Digest Trigger',
+  id: 'nightly-digest-trigger',
   description: 'Runs every night.',
   enabled: true,
   modeDefault: 'subscribable',
@@ -67,37 +65,49 @@ import { webhookTrigger } from '@keystrokehq/core';
 import { z } from 'zod';
 
 export const paymentWebhook = webhookTrigger({
-  name: 'Payment Webhook',
+  id: 'payment-webhook',
   description: 'Handles payment events.',
   enabled: true,
   modeDefault: 'subscribable',
   source: {
     type: 'custom',
-    method: 'POST',
-    path: '/payments',
-    verify: async (request) => {
-      if (!request.headers['x-signature']) {
-        throw new Error('Missing signature header');
-      }
-    },
-    response: {
-      successStatus: 202,
-      successBody: {
-        accepted: true,
-      },
-    },
   },
   payload: z.object({
     id: z.string(),
     type: z.string(),
     amount: z.number(),
   }),
-  filter: (payload) => payload.type === 'payment.completed',
-  idempotencyKey: (payload) => payload.id,
+  filter: z.object({
+    type: z.literal('payment.completed'),
+  }),
+  idempotencyKey: {
+    from: 'payload',
+    path: 'id',
+  },
+});
+```
+
+Use `source: { type: 'custom' }` when the platform should create a Keystroke-owned webhook surface. The platform owns HTTP authentication and response handling for custom webhooks; do not add `method`, `path`, `verify`, or `response`.
+
+Use `source: { type: 'app', appRef }` when a Keystroke-managed provider app fans events out centrally:
+
+```ts
+export const slackMessageWebhook = webhookTrigger({
+  id: 'slack-message',
+  description: 'Receives Slack message events from the platform Slack app.',
+  source: {
+    type: 'app',
+    appRef: 'slack',
+  },
+  payload: z.object({
+    type: z.literal('message'),
+    channel: z.string(),
+    text: z.string(),
+  }),
 });
 ```
 
-Use `request.rawBody` in `verify` when a provider expects raw request verification. To parse a webhook body, use `trigger.payload.parse(JSON.parse(request.rawBody))`.
+To parse a webhook body in tests or local checks, use `trigger.payload.parse(JSON.parse(request.rawBody))`.
 
 ## Binding a webhook trigger to a workflow with `transform`
 
@@ -128,7 +138,7 @@ import { pollingTrigger } from '@keystrokehq/core';
 import { z } from 'zod';
 
 export const orderPolling = pollingTrigger({
-  name: 'Order Polling',
+  id: 'order-polling',
   description: 'Polls for the newest order.',
   enabled: true,
   schedule: '*/15 * * * *',
@@ -144,12 +154,14 @@ export const orderPolling = pollingTrigger({
       status: 'created',
     };
   },
-  filter: (payload) => payload.status === 'created',
-  idempotencyKey: (payload) => payload.orderId,
+  filter: z.object({
+    status: z.literal('created'),
+  }),
 });
 ```
 
 Use this when the workflow should be entered from periodic remote-state checks.
+Polling filters are pure Zod schemas. Polling triggers do not support idempotency config.
 
 ## `pollingTrigger.parseResponse(...)`
 
@@ -162,23 +174,6 @@ const parsedResponse = orderPolling.parseResponse({
 
 Use `parseResponse(...)` when you want the trigger's response schema validation without running polling logic.
 
-## `providerTrigger`
-
-```ts
-import { providerTrigger } from '@keystrokehq/core';
-
-export const githubIssueTrigger = providerTrigger({
-  name: 'GitHub Issue Trigger',
-  description: 'Receives GitHub provider events for issue activity.',
-  provider: 'github',
-  eventTypes: ['issues.opened', 'issues.edited'],
-  filter: async (event) => event.type === 'issues.opened',
-  idempotencyKey: async (event) => event.id,
-});
-```
-
-Use a provider trigger when the user is authoring around normalized provider events instead of a raw webhook or polling loop.
-
 ## Bare trigger in workflow (no transform)
 
 ```ts
@@ -202,12 +197,16 @@ triggers: [
 
 Call the trigger as a function with `{ transform }` when the trigger payload and workflow input are different shapes. This returns a `BoundTrigger`.
 
-## Bound trigger with additional `filter`
+## Narrow a trigger for per-workflow filtering
 
 ```ts
+const largePayments = paymentWebhook.narrow({
+  id: 'large-payments',
+  filter: z.object({ amount: z.number().gt(100) }),
+});
+
 triggers: [
-  paymentWebhook({
-    filter: (payload) => payload.amount > 100,
+  largePayments({
     transform: (payload) => ({
       eventId: payload.id,
       amount: payload.amount,
@@ -216,7 +215,7 @@ triggers: [
 ]
 ```
 
-An additional filter on the binding composes with the trigger's own filter.
+Filtering and idempotency live on the trigger or its `.narrow()` derivatives — never on the attachment. Bindings accept only `transform`. Use `.narrow()` to produce a filtered child trigger and attach that to the workflow.
 
 ## Task trigger note
 
@@ -227,36 +226,33 @@ Use the task skill when the user needs prompt templating, task lifecycle, or foc
 ## Trigger credentials
 
 ```ts
-import { CredentialSet, webhookTrigger } from '@keystrokehq/core';
+import { CredentialSet, pollingTrigger } from '@keystrokehq/core';
 import { z } from 'zod';
 
-const signingCredentials = new CredentialSet({
-  id: 'webhookSigning',
+const crmCredentials = new CredentialSet({
+  id: 'crmApi',
   auth: z.object({
-    secret: z.string(),
+    apiKey: z.string(),
   }),
 });
 
-const signedWebhook = webhookTrigger({
-  name: 'Signed Webhook',
-  description: 'Verifies a signed webhook.',
-  source: {
-    type: 'custom',
-    method: 'POST',
-    path: '/signed',
-    credentialSets: [signingCredentials],
-    verify: async (_request, ctx) => {
-      if (!ctx.credentials.webhookSigning.secret) {
-        throw new Error('Missing signing secret');
-      }
-    },
-  },
-  payload: z.object({
-    id: z.string(),
+const recentCustomers = pollingTrigger({
+  id: 'recent-customers',
+  description: 'Polls for recently updated customers.',
+  credentialSets: [crmCredentials],
+  schedule: '5m',
+  response: z.object({
+    customers: z.array(z.object({ id: z.string() })),
   }),
+  poll: async (ctx) => {
+    const apiKey = ctx.credentials.crmApi.apiKey;
+    return { customers: [{ id: `customer-for-${apiKey}` }] };
+  },
 });
 ```
 
+Polling triggers can attach credential sets and read credentials in `poll(ctx)`. Webhook triggers do not attach per-trigger credential sets in the current custom/app source model.
+
 ## `describe()` and `toManifest()`
 
 ```ts

package/src/keystroke-trigger-authoring/references/source-map.md

@@ -0,0 +1,166 @@
+# Trigger Feature Map
+
+Use only the public imports a user repo can rely on:
+
+```ts
+import {
+  cronTrigger,
+  pollingTrigger,
+  webhookTrigger,
+} from '@keystrokehq/core';
+import type {
+  BoundTrigger,
+  CallableTrigger,
+  IdempotencyKeyConfig,
+  TriggerBindOptions,
+  TriggerManifest,
+  WebhookRequest,
+} from '@keystrokehq/core/trigger';
+```
+
+When a trigger explanation also needs to talk about workflow steps or agent tools, use the terminology from the other Keystroke skills:
+
+- `Step`, `Tool`, and `Operation` are aliases for the same `Operation` class
+- use the workflow skill for workflow-side operation guidance
+- use the agent skill for agent-side tool guidance
+
+## Common trigger fields
+
+- `id`
+- `description`
+- `enabled`
+- `credentialSets`
+- `executionIdentityPolicy`
+- `modeDefault`
+
+## Common trigger methods
+
+- `describe()`
+- `toManifest()`
+
+## `cronTrigger` fields
+
+- `input`
+- `payload`
+- `schedule`
+- `timezone`
+
+## `cronTrigger` instance properties
+
+- `.id`
+- `.payload`
+- `.schedule`
+- `.timezone`
+- `.toManifest()`
+- `.describe()`
+
+## `webhookTrigger` fields
+
+- `id`
+- `description`
+- `source`
+- `payload`
+- `filter`
+- `idempotencyKey`
+
+### `webhookTrigger.source`
+
+- `{ type: 'custom' }` — Keystroke owns the HTTP surface and authenticates with a Keystroke-issued secret
+- `{ type: 'app', appRef: string }` — a Keystroke-managed provider app fans out events centrally
+
+Do not teach `method`, `path`, `verify`, or `response` on webhook triggers. Those are not part of the current public config.
+
+## `webhookTrigger` instance properties and methods
+
+- `.id`
+- `.source`
+- `.payload`
+- `.payload.parse(data)` — validate parsed body against the payload schema
+- `.filter` — pure Zod schema metadata, not a callback
+- `.idempotencyKey` — declarative `IdempotencyKeyConfig`, not a callback
+- `.toManifest()`
+- `.describe()`
+
+## `pollingTrigger` fields
+
+- `id`
+- `description`
+- `schedule`
+- `response`
+- `poll`
+- `filter`
+
+## `pollingTrigger` instance properties and methods
+
+- `.id`
+- `.poll(ctx)`
+- `.parseResponse(response)`
+- `.filter` — pure Zod schema metadata, not a callback
+
+Polling triggers do not support idempotency config.
+
+## Filter schemas
+
+Webhook and polling triggers accept `filter` as a pure Zod schema. The runtime converts it to JSON Schema for server-side evaluation before a VM hop.
+
+Allowed filter schemas are structural schemas such as:
+
+```ts
+z.object({
+  type: z.literal('payment.completed'),
+  amount: z.number().min(100),
+})
+```
+
+Do not use effectful Zod features in filters:
+
+- `.refine()`
+- `.superRefine()`
+- `.transform()`
+- `.preprocess()`
+- `.pipe()`
+- `z.custom()`
+
+For conditional logic that cannot be expressed as a pure schema, do the check at the start of the workflow body or use an integration `mapPayload` helper.
+
+## Webhook idempotency config
+
+Webhook triggers accept declarative `IdempotencyKeyConfig`:
+
+- `{ from: 'payload', path: 'eventId' }`
+- `{ from: 'payload', strategy: 'hash' }`
+- `{ from: 'header', name: 'x-event-id' }`
+- `{ from: 'header', strategy: 'hash' }`
+
+There is no function-style idempotency callback.
+
+## Calling a trigger (creating a bound trigger)
+
+All factory-created triggers are callable. Calling one returns a `BoundTrigger`:
+
+- `trigger()` — bare binding (no transform)
+- `trigger({ transform })` — bound with payload-to-input mapping
+
+Bindings carry only `transform`. To filter events for a specific workflow, derive a child with `trigger.narrow({ id, filter })` and attach that. Binding-level `filter` and `idempotencyKey` are intentionally not part of the API.
+
+## `BoundTrigger`
+
+- `.isBoundTrigger` — always `true`
+- `.trigger` — reference to the underlying trigger instance
+- `.transform?` — payload-to-workflow-input mapping function
+
+## Workflow `triggers` array
+
+`Workflow({ triggers: [...] })` accepts trigger entries:
+- a bare `CallableTrigger` (trigger payload passes through as workflow input)
+- a `BoundTrigger` (returned by calling the trigger with options)
+
+## Task note
+
+- task triggers are declared inline in `Task.triggers`
+- messaging gateways belong to agent authoring, not trigger authoring
+
+## Where to read next
+
+- `patterns.md` for trigger field examples
+- `testing.md` for trigger metadata, polling, and bound trigger tests

package/{keystroke-trigger-authoring → src/keystroke-trigger-authoring}/references/testing.md

@@ -10,14 +10,14 @@ Assume `paymentWebhook`, `orderPolling`, and `paymentWorkflow` are the public tr
 
 ```ts
 import { defineConfig } from 'vitest/config';
-import { keystrokeTestPlugin } from '@keystrokehq/testing/vitest';
+import { keystrokeTestPlugin } from '@keystrokehq/testing';
 
 export default defineConfig({
   plugins: [keystrokeTestPlugin()],
 });
 ```
 
-## Test webhook verification and filtering
+## Test webhook parsing and declarative metadata
 
 ```ts
 const request = {
@@ -34,28 +34,36 @@ const request = {
   path: '/payments',
 };
 
-await paymentWebhook.verify?.(request, {
-  credentials: {},
-  triggerName: paymentWebhook.name,
-  triggerType: 'webhook',
+const payload = paymentWebhook.payload.parse(JSON.parse(request.rawBody));
+
+expect(payload).toEqual({
+  id: 'evt_123',
+  type: 'payment.completed',
+  amount: 5000,
 });
 
-const payload = paymentWebhook.payload.parse(JSON.parse(request.rawBody));
-const shouldRun = paymentWebhook.filter?.(payload, request);
+const runtime = paymentWebhook.toManifest().runtime;
+expect(runtime.filterSchema).toBeDefined();
+expect(runtime.idempotencyConfig).toEqual({
+  from: 'payload',
+  path: 'id',
+});
 ```
 
 This isolates the webhook-only concerns:
 
-- authenticity checks in `verify`
 - parsing via `trigger.payload.parse(JSON.parse(request.rawBody))`
-- event gating in `filter`
+- declarative event gating metadata in `runtime.filterSchema`
+- declarative dedupe metadata in `runtime.idempotencyConfig`
+
+Custom webhook HTTP authentication and responses are platform-owned in the current surface. Do not test `verify`, `method`, `path`, or `response` callbacks on authored webhook triggers.
 
 ## Test polling behavior
 
 ```ts
 const response = await orderPolling.poll({
   credentials: {},
-  triggerName: orderPolling.name,
+  triggerId: orderPolling.id,
   triggerType: 'polling',
   lastPolledAt: new Date().toISOString(),
   lastResponse: {
@@ -65,6 +73,7 @@ const response = await orderPolling.poll({
 });
 
 const payload = orderPolling.parseResponse(response);
+expect(orderPolling.toManifest().runtime.filterSchema).toBeDefined();
 ```
 
 This isolates the polling-only concerns:
@@ -72,6 +81,7 @@ This isolates the polling-only concerns:
 - what `poll(...)` returns
 - how prior state affects the next poll
 - whether the response matches the trigger schema
+- declarative filter metadata when the polling trigger has a filter schema
 
 ## Test bound trigger transform
 
@@ -110,26 +120,19 @@ const workflowInput = bound.transform?.(
 );
 ```
 
-Pass the optional second argument when the transform depends on webhook request data (headers, query params, etc.). Note that only `verify` receives credentials — `transform`, `filter`, and `idempotencyKey` do not.
+Pass the optional second argument when the transform depends on webhook request data such as headers or query params. `transform` does not receive credentials. Filters and idempotency are declarative metadata, not callbacks.
 
 ## Full webhook-to-workflow test
 
 ```ts
 it('maps a valid webhook event into workflow input', async () => {
-  const request = mockRequest({
-    headers: { 'x-signature': 'signed' },
-    rawBody: JSON.stringify({ id: 'evt_123', type: 'payment.completed', amount: 5000 }),
-  });
-
-  await paymentWebhook.verify?.(request, {
-    credentials: {},
-    triggerName: paymentWebhook.name,
-    triggerType: 'webhook',
+  const payload = paymentWebhook.payload.parse({
+    id: 'evt_123',
+    type: 'payment.completed',
+    amount: 5000,
   });
 
-  const payload = paymentWebhook.payload.parse(JSON.parse(request.rawBody));
-  const passed = paymentWebhook.filter?.(payload, request);
-  expect(passed).toBe(true);
+  expect(paymentWebhook.toManifest().runtime.filterSchema).toBeDefined();
 
   const bound = paymentWebhook({
     transform: (p) => ({ eventId: p.id, amount: p.amount }),
@@ -141,8 +144,8 @@ it('maps a valid webhook event into workflow input', async () => {
 
 ## What to validate
 
-- webhook verification success and failure
-- filter behavior
-- idempotency key behavior when defined
+- webhook payload parsing
+- declarative filter metadata
+- webhook idempotency config when defined
 - polling response shape
 - transform correctness from trigger payload to workflow input

package/{keystroke-workflow-authoring → src/keystroke-workflow-authoring}/SKILL.md

@@ -93,6 +93,7 @@ Teach this mental model clearly:
 - `Workflow.run(...)` coordinates steps, child workflows, waits, hooks, and agents
 - `Step.run(...)` does low-level operational work and returns typed output
 - triggers are listed in `Workflow({ triggers: [...] })`; call a trigger with `{ transform }` to bind payload mapping
+- trigger filters are declarative Zod schemas on the trigger or on `.narrow({ id, filter })`, not workflow attachment callbacks
 - tasks are different: use `Task` when the job is “trigger -> prompt -> agent run”
 
 `Step`, `Tool`, and `Operation` are the same class. In this skill, default to `Step` because that matches workflow author language.
@@ -123,7 +124,7 @@ Teach these rules:
    - waits and hooks
 5. Put operational work in steps, shared operations, or agents.
 6. Keep each exported primitive in its own typed file.
-7. Finish with tests using `@keystrokehq/testing/vitest`.
+7. Finish with tests using `@keystrokehq/testing`.
 
 ## Workflow rules
 
@@ -136,7 +137,7 @@ Teach these rules:
 - Use `workflowGlobals` for typed workflow-wide runtime values.
 - Use `CredentialSet` for secrets and integration auth.
 - Do not use `process.env` in authored workflow or step code.
-- Follow Zod v4 syntax in examples and authored code. See `../../../.agents/rules/zod-v4-requirements.md`.
+- Follow Zod v4 syntax in examples and authored code. See `../../../.agents/skills/zod-4/SKILL.md` for deep schema guidance.
 - Workflows can be registered as agent tools. Sync workflows return inline results; suspending workflows yield and resume later.
 - Add `largeResultMode: 'ref'` when a workflow tool may return large data; agents inspect refs with `describe_ref`, `read_ref`, and `slice_ref`.
 - Add `midSessionSnapshot: true` only for workflow tools that have measured benefit from preserving mid-tool-call reasoning state. The default turn-boundary yield path is simpler and should remain the default.
@@ -202,7 +203,7 @@ keystroke workflows run <authoredWorkflowId> --input '{}' --wait
 keystroke workflows run <authoredWorkflowId> --input '{}' --follow
 ```
 
-`workflows run` executes the current deployed snapshot. It is different from `workflows try-deploy`, which builds local code and runs a temporary artifact.
+`workflows run` executes the current deployed snapshot. It is different from `workflows test`, which builds local code and runs a temporary artifact.
 
 To explicitly start a workflow via API:
 - **Endpoint**: `POST /api/v1/workflows/execute`

package/{keystroke-workflow-authoring → src/keystroke-workflow-authoring}/references/patterns.md

@@ -48,21 +48,21 @@ import { z } from 'zod';
 const PayloadSchema = z.object({ accountId: z.string() });
 
 const accountCron = cronTrigger({
-  name: 'Nightly Account Sync',
+  id: 'nightly-account-sync',
+  description: 'Runs the account sync every night.',
   schedule: '0 0 * * *',
   input: PayloadSchema,
   payload: { accountId: 'default' },
 });
 
 const accountWebhook = webhookTrigger({
-  name: 'Account Webhook',
+  id: 'account-webhook',
+  description: 'Receives account sync webhook events.',
   source: {
     type: 'custom',
-    method: 'POST',
-    path: '/accounts',
   },
   payload: z.object({ id: z.string(), action: z.string() }),
-  filter: (p) => p.action === 'sync',
+  filter: z.object({ action: z.literal('sync') }),
 });
 
 export const accountSyncWorkflow = new Workflow({
@@ -80,7 +80,7 @@ export const accountSyncWorkflow = new Workflow({
 });
 ```
 
-Bare triggers (like `accountCron` above) pass their payload directly as workflow input. Call the trigger with `{ transform }` when the payload shape differs from the workflow input.
+Bare triggers (like `accountCron` above) pass their payload directly as workflow input. Call the trigger with `{ transform }` when the payload shape differs from the workflow input. Put filtering on the trigger as a pure Zod schema, or use `.narrow({ id, filter })` for workflow-specific filtering.
 
 ## Workflow metadata fields
 

package/{keystroke-workflow-authoring → src/keystroke-workflow-authoring}/references/prebuilt-integrations.md

@@ -249,7 +249,7 @@ Common operation groups:
 - search: `searchCode`, `searchIssues`, `searchRepositories`
 - users and orgs: `getAuthenticatedUser`, `getUser`, `listOrganizations`, `listOrgMembers`
 
-Messaging-specific credential surfaces also exist in this package, but workflow trigger and conversation entry guidance belongs in the trigger and agent skills.
+Messaging-specific credential helpers also exist in this package, but workflow trigger and conversation entry guidance belongs in the trigger and agent skills.
 
 ## `@keystrokehq/google`
 

package/{keystroke-workflow-authoring → src/keystroke-workflow-authoring}/references/runtime-helpers.md

@@ -239,7 +239,7 @@ Use these when operation behavior depends on retry state or when you want the st
 
 ## Public testing helpers
 
-Import these from `@keystrokehq/testing/vitest`:
+Import these from `@keystrokehq/testing`:
 
 - `keystrokeTestPlugin`
 - `createTestRuntime`
@@ -256,7 +256,7 @@ Import these from `@keystrokehq/testing/vitest`:
 Example:
 
 ```ts
-import { createMockHook } from '@keystrokehq/testing/vitest';
+import { createMockHook } from '@keystrokehq/testing';
 
 const hook = createMockHook();
 await hook;

package/{keystroke-workflow-authoring → src/keystroke-workflow-authoring}/references/source-map.md

@@ -9,7 +9,7 @@ import {
   createTestRuntime,
   createTestStepContext,
   keystrokeTestPlugin,
-} from '@keystrokehq/testing/vitest';
+} from '@keystrokehq/testing';
 ```
 
 `Operation`, `Step`, and `Tool` are aliases for the same class. In this workflow skill, prefer `Step` for examples and explanations, but `Operation` is equally valid for shared or integration-oriented code.

package/{keystroke-workflow-authoring → src/keystroke-workflow-authoring}/references/testing.md

@@ -10,7 +10,7 @@ Assume `helloWorkflow`, `accountSyncWorkflow`, `loadCustomer`, `paymentWebhook`,
 
 ```ts
 import { defineConfig } from 'vitest/config';
-import { keystrokeTestPlugin } from '@keystrokehq/testing/vitest';
+import { keystrokeTestPlugin } from '@keystrokehq/testing';
 
 export default defineConfig({
   plugins: [keystrokeTestPlugin()],
@@ -40,7 +40,7 @@ Use it when a workflow test needs more than plain input data.
 
 ```ts
 import { createTestRuntime } from '@keystrokehq/testing';
-import { createMockHook } from '@keystrokehq/testing/vitest';
+import { createMockHook } from '@keystrokehq/testing';
 
 const runtime = createTestRuntime({
   workflowGlobals: {

package/keystroke-agent-authoring/evals/evals.json

@@ -1,29 +0,0 @@
-{
-  "skill_name": "keystroke-agent-authoring",
-  "evals": [
-    {
-      "id": 1,
-      "prompt": "I need a Keystroke agent that can look up Slack users and DM one of them. What fields should I set up, and where do tools and credentials go?",
-      "expected_output": "Explains the canonical Keystroke agent path, the important agent fields, tool configuration, and the credential relationship between the agent and its tools.",
-      "files": []
-    },
-    {
-      "id": 2,
-      "prompt": "Should this be a Step or an agent? The task is to inspect some repo files, decide what changed, and then call a couple of tools depending on what it finds.",
-      "expected_output": "Explains when an agent is appropriate, when a normal step would be better, and how workflow orchestration relates to agent scope.",
-      "files": []
-    },
-    {
-      "id": 3,
-      "prompt": "Show me how to build a sandboxed Keystroke coding agent that can work in a checked-out repo and maybe use MCP later if needed.",
-      "expected_output": "Uses the public sandbox and MCP patterns, points to MCP references when needed, and keeps workflow orchestration separate.",
-      "files": []
-    },
-    {
-      "id": 4,
-      "prompt": "I want my Keystroke agent to answer messages from GitHub conversations. Should I use a trigger or something else?",
-      "expected_output": "Explains that conversational entry belongs on Agent.messaging with a MessagingGateway, not on workflow triggers, and keeps the distinction between tasks, triggers, and conversations clear.",
-      "files": []
-    }
-  ]
-}