@conductor-oss/conductor-skills 1.4.2

package/skills/conductor/examples/llm-chat.md

@@ -0,0 +1,61 @@
+# Example: Minimum LLM Workflow
+
+The smallest useful AI workflow — one `LLM_CHAT_COMPLETE` task. Useful as a building block for prompts that don't need tools, retrieval, or loops.
+
+> Conductor auto-enables LLM providers when their API key is set in the server's environment (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, etc.). No separate provider registration needed in OSS.
+
+## Workflow
+
+See [workflows/llm-chat.json](workflows/llm-chat.json):
+
+```json
+{
+  "name": "summarize_text",
+  "tasks": [{
+    "name": "summarize",
+    "taskReferenceName": "summarize",
+    "type": "LLM_CHAT_COMPLETE",
+    "inputParameters": {
+      "llmProvider": "openai",
+      "model": "gpt-4o-mini",
+      "messages": [
+        {"role": "system", "message": "You summarize text in one sentence."},
+        {"role": "user", "message": "${workflow.input.text}"}
+      ],
+      "temperature": 0.3,
+      "maxTokens": 200
+    }
+  }],
+  "outputParameters": {
+    "summary": "${summarize.output.result}",
+    "tokensUsed": "${summarize.output.tokenUsed}"
+  }
+}
+```
+
+## Run
+
+```bash
+conductor workflow create examples/workflows/llm-chat.json
+conductor workflow start -w summarize_text -i '{"text": "Conductor is a workflow orchestration platform. It supports SIMPLE tasks, HTTP, SWITCH, FORK_JOIN, AI tasks, and more. Workflows are durable — they survive worker crashes by replaying from last completed task."}' --sync
+```
+
+The `--sync` flag waits for completion and returns the workflow result inline. For long-running prompts (large models, long outputs), drop `--sync` and poll via `conductor workflow get-execution`.
+
+## Output shape
+
+`LLM_CHAT_COMPLETE` returns:
+
+- `result` — the response text (string)
+- `finishReason` — `STOP`, `LENGTH`, or `TOOL_CALLS`
+- `tokenUsed`, `promptTokens`, `completionTokens` — token accounting
+- `toolCalls` — present if the model invoked a tool (see [ai-agent-mcp.md](ai-agent-mcp.md))
+
+Downstream tasks read `${summarize.output.result}` for the text and `${summarize.output.tokenUsed}` for cost tracking.
+
+## Patterns
+
+- **Provider per-task.** Mix providers in one workflow — `gpt-4o-mini` for cheap classification, `claude-opus-4-7` for the hard reasoning step. Each task picks its own `llmProvider` + `model`.
+- **Temperature near zero** for deterministic / classification work; **0.7+** for generative / creative.
+- **`maxTokens`** is a hard cap. If `finishReason == "LENGTH"`, the response was truncated — raise the cap.
+- **Don't put secrets in the prompt.** API keys, tokens, PII — keep them in `${workflow.secrets.X}` (Orkes) or worker env. Workflow inputs are visible in the execution view.

package/skills/conductor/examples/llm-rag.md

@@ -0,0 +1,115 @@
+# Example: RAG — Retrieval-Augmented Generation
+
+Classic RAG pattern: search a vector database for context, then ask an LLM to answer using only that context. Two tasks, one workflow.
+
+> **⚠️ The single most important RAG rule:** the **embedding model** you use at **query time** in `LLM_SEARCH_INDEX` **MUST exactly match** the embedding model used at **index time** in `LLM_INDEX_TEXT`. Different models produce incompatible vector spaces — a mismatch returns nonsense matches without any error. State this explicitly when generating RAG workflows.
+
+## Pipeline
+
+```
+LLM_SEARCH_INDEX (vector search) → LLM_CHAT_COMPLETE (answer with context)
+```
+
+The search task auto-embeds the user's question, queries the vector DB, and returns the top-k matching chunks. The chat task receives those chunks as system-prompt context and grounds its answer in them.
+
+## Prerequisites
+
+1. **A vector database** registered with Conductor — Pinecone, Postgres pgvector, or MongoDB Atlas. The example uses `postgres-prod` (configured server-side; see your Conductor admin).
+2. **Documents already indexed.** Use [`LLM_INDEX_TEXT`](../references/workflow-definition.md#llm_index_text) in a separate ingestion workflow to populate the index.
+3. **An LLM provider** with its API key set (`OPENAI_API_KEY`, `ANTHROPIC_API_KEY`, etc.) — Conductor auto-enables providers when their API key is present.
+
+## Workflow
+
+See [workflows/llm-rag.json](workflows/llm-rag.json):
+
+```json
+{
+  "name": "rag_qa",
+  "tasks": [
+    {
+      "name": "search_knowledge_base",
+      "taskReferenceName": "search",
+      "type": "LLM_SEARCH_INDEX",
+      "inputParameters": {
+        "vectorDB": "postgres-prod",
+        "namespace": "kb",
+        "index": "articles",
+        "embeddingModelProvider": "openai",
+        "embeddingModel": "text-embedding-3-small",
+        "query": "${workflow.input.question}",
+        "llmMaxResults": 3
+      }
+    },
+    {
+      "name": "generate_answer",
+      "taskReferenceName": "answer",
+      "type": "LLM_CHAT_COMPLETE",
+      "inputParameters": {
+        "llmProvider": "anthropic",
+        "model": "claude-sonnet-4-6",
+        "messages": [
+          {"role": "system", "message": "Answer using only the context below. If the answer isn't in the context, say \"I don't know.\"\n\nContext:\n${search.output.result}"},
+          {"role": "user", "message": "${workflow.input.question}"}
+        ],
+        "temperature": 0.2,
+        "maxTokens": 500
+      }
+    }
+  ],
+  "outputParameters": {
+    "answer": "${answer.output.result}",
+    "sources": "${search.output.result}",
+    "tokensUsed": "${answer.output.tokenUsed}"
+  }
+}
+```
+
+## Run
+
+```bash
+conductor workflow create examples/workflows/llm-rag.json
+conductor workflow start -w rag_qa -i '{"question": "How does Conductor handle worker failures?"}' --sync
+```
+
+The `--sync` flag waits for both tasks (search + chat) to complete and returns the final answer plus the source chunks for citation.
+
+## Output
+
+- `answer` — the grounded response (string)
+- `sources` — the retrieved chunks, with their metadata (use to render citations)
+- `tokensUsed` — for cost tracking
+
+## Variant: pre-computed embeddings
+
+If you already have the query embedding (e.g., computed by an upstream worker), use `LLM_SEARCH_EMBEDDINGS` instead — same shape, but takes `embeddings` (a float array) instead of `query` (text). Saves one embedding call per request.
+
+## Patterns
+
+- **System prompt does the grounding.** "Answer only from the context below" is the difference between a real RAG system and a thin wrapper that pretends. State it explicitly. Tell the model what to do when the context doesn't cover the question — "say I don't know" beats hallucination.
+- **Low temperature for QA.** `0.2` keeps answers grounded; higher temperatures invent facts.
+- **`llmMaxResults` is the recall knob.** 3 chunks → tight answer, low cost. 10 chunks → broader recall, higher token spend, risk of off-topic context diluting the signal.
+- **Different providers per task is fine.** Cheap small model for embedding (`text-embedding-3-small`), a strong reasoning model for the answer (`claude-sonnet-4-6`). Each task picks its own provider/model.
+- **Return sources.** Always return `${search.output.result}` so the caller can cite or display sources. RAG without sources is just expensive Q&A.
+
+## Ingesting documents (separate workflow)
+
+For the search to find anything, an ingestion workflow needs to populate the index. Sketch:
+
+```json
+{
+  "name": "ingest_doc",
+  "type": "LLM_INDEX_TEXT",
+  "inputParameters": {
+    "vectorDB": "postgres-prod",
+    "namespace": "kb",
+    "index": "articles",
+    "embeddingModelProvider": "openai",
+    "embeddingModel": "text-embedding-3-small",
+    "text": "${workflow.input.document}",
+    "docId": "${workflow.input.docId}",
+    "metadata": {"source": "${workflow.input.source}"}
+  }
+}
+```
+
+Run this once per document. The embedding model **must** match the one used at query time in `rag_qa` — different models produce incompatible vector spaces.

package/skills/conductor/examples/monitor-and-retry.md

@@ -0,0 +1,54 @@
+# Example: Monitor and Retry Failed Workflows
+
+> "Show me failed workflows from today and retry the timeout failures."
+
+## Steps
+
+```bash
+# 1. Find failed workflows in the time range
+conductor workflow search -s FAILED --start-time-after "2024-01-15" -c 20
+
+# 2. Inspect each one to identify the failed task and reason
+conductor workflow get-execution {workflowId} -c
+```
+
+Look at the failed task's `status` and `reasonForIncompletion`:
+
+| Status | Action |
+|--------|--------|
+| `TIMED_OUT` | Retryable — `conductor workflow retry {id}` |
+| `FAILED` (transient) | Retryable — `conductor workflow retry {id}` |
+| `FAILED_WITH_TERMINAL_ERROR` | **Not** retryable. Surface root cause to the user before retrying. |
+
+## Retry batch
+
+```bash
+conductor workflow retry {id1}
+conductor workflow retry {id2}
+conductor workflow retry {id3}
+# verify
+conductor workflow status {id1}   # → RUNNING
+```
+
+## Reporting back
+
+Group results in your reply to the user:
+
+```
+Found 4 failed workflows.
+
+Retried (3):
+  - order_processing  ...111  → RUNNING
+  - data_pipeline     ...222  → RUNNING
+  - order_processing  ...444  → RUNNING
+
+Skipped — terminal failure (1):
+  - email_campaign    ...333  "Invalid email template" — needs template fix
+```
+
+## Patterns demonstrated
+
+- Time-range search with `--start-time-after` / `--start-time-before`.
+- Distinguishing retryable from terminal failures.
+- Batch retry with post-retry verification.
+- Recommending root-cause fixes when timeouts persist (raise `responseTimeoutSeconds` on the task definition).

package/skills/conductor/examples/review-workflow.md

@@ -0,0 +1,67 @@
+# Example: Review and Optimize a Workflow
+
+> "Review my `order_processing` workflow and tell me what to fix."
+
+## Steps
+
+```bash
+# 1. Load the definition
+conductor workflow get order_processing > /tmp/wf.json
+
+# 2. For each SIMPLE task, load the task definition
+conductor taskDef get charge_card
+conductor taskDef get send_email
+conductor taskDef get update_inventory
+```
+
+Walk the checklist in [../references/optimization.md](../references/optimization.md). Group findings by severity.
+
+## Sample report
+
+```
+Workflow: order_processing v3 (12 tasks)
+
+CRITICAL (2)
+  ✗ B1  SIMPLE task `charge_card` (taskDef): responseTimeoutSeconds=0, timeoutSeconds=0
+        A hung payment worker hangs the workflow. Set responseTimeoutSeconds=30,
+        pollTimeoutSeconds=60, timeoutSeconds=300 on the task definition.
+  ✗ D1  Workflow input `stripeApiKey` is a secret being passed in plaintext.
+        Move to ${workflow.secrets.STRIPE_KEY} or to the worker's environment.
+
+WARN (3)
+  ⚠ A1  description is empty
+  ⚠ B2  No workflow timeoutSeconds — a stuck workflow can run forever.
+        Suggest 1800s with timeoutPolicy=TIME_OUT_WF.
+  ⚠ B3  SIMPLE task `send_email` has retryCount=0. Email is transient by nature —
+        set retryCount=3, retryLogic=EXPONENTIAL_BACKOFF, retryDelaySeconds=30.
+
+INFO
+  • A4  12 tasks — well within the 100-task limit
+  • B4  No failureWorkflow. This workflow mutates inventory and charges cards;
+        consider a failureWorkflow that releases the inventory hold and notifies ops.
+
+Recommended Changes (priority order)
+  [ ] task_def_charge_card.json     set responseTimeoutSeconds=30, pollTimeoutSeconds=60, timeoutSeconds=300
+  [ ] order_processing.json         move stripeApiKey to ${workflow.secrets.STRIPE_KEY}
+  [ ] order_processing.json         add description, timeoutSeconds=1800, timeoutPolicy=TIME_OUT_WF
+  [ ] task_def_send_email.json      set retryCount=3, retryLogic=EXPONENTIAL_BACKOFF, retryDelaySeconds=30
+  [ ] order_processing.json         (discussion) add failureWorkflow for inventory rollback + ops alert
+```
+
+## Offer to fix
+
+> Want me to apply any of these? I can:
+> - update the `charge_card` and `send_email` task definitions and re-register them
+> - rewrite the workflow to add `timeoutSeconds`, `timeoutPolicy`, `description`
+> - move `stripeApiKey` out of inputs (need to know where you want it: secrets or worker env)
+>
+> The `failureWorkflow` and the inventory-rollback design are bigger calls — I'd want to know your retry/refund policy before scaffolding that.
+
+Don't apply silently. Each fix gets confirmed.
+
+## What this example demonstrates
+
+- Loading definition + each SIMPLE task's taskDef before reporting (timeouts and retry config live on the task def, not the workflow task).
+- Grading findings (CRITICAL / WARN / INFO) so the user knows what's urgent.
+- Offering targeted fixes, not a wholesale rewrite.
+- Drawing the line at design decisions that need user input (failureWorkflow design, retry semantics).

package/skills/conductor/examples/signal-wait-task.md

@@ -0,0 +1,36 @@
+# Example: Signal a WAIT Task
+
+> "Workflow `order-wf-789` is waiting for payment confirmation. Approve it."
+
+## Steps
+
+```bash
+# 1. Find the blocking task
+conductor workflow get-execution order-wf-789 -c
+```
+
+Look for a task with `type: WAIT` and `status: IN_PROGRESS`. That's the one to signal. In this example: `wait_for_payment`.
+
+```bash
+# 2. Signal it (use signal-sync to get the updated workflow back in one round-trip)
+conductor task signal-sync \
+  --workflow-id order-wf-789 \
+  --task-ref wait_for_payment \
+  --status COMPLETED \
+  --output '{"paymentId": "pay-456", "amount": 149.99, "method": "credit_card"}'
+```
+
+## signal vs signal-sync
+
+- `signal` — async, fire-and-forget. Returns immediately; workflow advances in the background.
+- `signal-sync` — returns the updated workflow object in the same response. Use when you need to confirm the next task is now running, or to chain follow-up logic.
+
+## Statuses you can signal
+
+`COMPLETED`, `FAILED`, `FAILED_WITH_TERMINAL_ERROR`. Use `FAILED_WITH_TERMINAL_ERROR` to reject the WAIT permanently (no retry).
+
+## Patterns demonstrated
+
+- Reading execution state to find the blocking WAIT task.
+- Passing structured `output` data with the signal — that data becomes `${wait_for_payment.output.x}` for downstream tasks.
+- Sync signaling for human-in-the-loop confirmations.

package/skills/conductor/examples/sub-workflow.md

@@ -0,0 +1,52 @@
+# Example: Composing Workflows with SUB_WORKFLOW
+
+Run another registered workflow as a single task. The parent waits for the child to complete and reads its output. Useful for splitting large workflows into reusable units.
+
+> If you want fire-and-forget instead — parent does not wait — use `START_WORKFLOW`.
+
+## Pattern
+
+Two registered workflows: `child_normalize` (reusable) and `parent_pipeline` (composes the child).
+
+### Child — `child_normalize`
+
+See [workflows/child-normalize.json](workflows/child-normalize.json). Takes a raw payload, returns a normalized object.
+
+### Parent — `parent_pipeline`
+
+See [workflows/parent-pipeline.json](workflows/parent-pipeline.json):
+
+```json
+{
+  "name": "normalize",
+  "taskReferenceName": "normalize",
+  "type": "SUB_WORKFLOW",
+  "subWorkflowParam": { "name": "child_normalize", "version": 1 },
+  "inputParameters": {
+    "payload": "${workflow.input.raw}"
+  }
+}
+```
+
+The child's `outputParameters` become the SUB_WORKFLOW task's output:
+
+```
+${normalize.output.normalized}
+```
+
+## Run
+
+```bash
+# Register both — child first
+conductor workflow create examples/workflows/child-normalize.json
+conductor workflow create examples/workflows/parent-pipeline.json
+
+conductor workflow start -w parent_pipeline -i '{"raw": {"name": "ALICE", "email": "ALICE@EX.COM"}}'
+```
+
+## Notes
+
+- The child must be registered before the parent runs (not before the parent is created — Conductor doesn't validate references at definition time).
+- Pin `version` in `subWorkflowParam` for stability. Omitting it picks the latest, which can break parents silently when the child is updated.
+- Child failure surfaces as a SUB_WORKFLOW task failure on the parent.
+- For dynamic-named children, set `subWorkflowParam.name` from input or use `START_WORKFLOW`.

package/skills/conductor/examples/workflows/ai-agent-loop.json

@@ -0,0 +1,88 @@
+{
+  "name": "autonomous_agent",
+  "description": "ReAct-pattern agent loop: think → act → observe until done",
+  "version": 1,
+  "schemaVersion": 2,
+  "inputParameters": ["task", "mcpServer", "tools"],
+  "tasks": [
+    {
+      "name": "agent_loop",
+      "taskReferenceName": "loop",
+      "type": "DO_WHILE",
+      "loopCondition": "if ($.loop['iteration'] < 10 && $.loop[$.loop['iteration']].think.output.result.done != true) { true; } else { false; }",
+      "loopOver": [
+        {
+          "name": "think",
+          "taskReferenceName": "think",
+          "type": "LLM_CHAT_COMPLETE",
+          "inputParameters": {
+            "llmProvider": "openai",
+            "model": "gpt-4o-mini",
+            "messages": [
+              {
+                "role": "system",
+                "message": "You are an agent. Tools: ${workflow.input.tools}. Previous results: ${loop.output}. Decide next step. Respond as JSON: { done: bool, method?: string, arguments?: object, answer?: string }."
+              },
+              {
+                "role": "user",
+                "message": "${workflow.input.task}"
+              }
+            ],
+            "temperature": 0.1,
+            "maxTokens": 500
+          }
+        },
+        {
+          "name": "act",
+          "taskReferenceName": "act",
+          "type": "SWITCH",
+          "evaluatorType": "javascript",
+          "expression": "$.done ? 'finish' : 'call_tool'",
+          "inputParameters": {
+            "done": "${think.output.result.done}"
+          },
+          "decisionCases": {
+            "call_tool": [
+              {
+                "name": "execute",
+                "taskReferenceName": "execute",
+                "type": "CALL_MCP_TOOL",
+                "inputParameters": {
+                  "mcpServer": "${workflow.input.mcpServer}",
+                  "method": "${think.output.result.method}",
+                  "arguments": "${think.output.result.arguments}"
+                }
+              }
+            ],
+            "finish": [
+              {
+                "name": "done",
+                "taskReferenceName": "done",
+                "type": "NOOP"
+              }
+            ]
+          }
+        }
+      ],
+      "inputParameters": {
+        "loop": "${loop.output}"
+      }
+    },
+    {
+      "name": "final_answer",
+      "taskReferenceName": "final",
+      "type": "INLINE",
+      "inputParameters": {
+        "evaluatorType": "graaljs",
+        "expression": "function e() { var i = $.loop_output['iteration']; return { answer: $.loop_output[i].think.output.result.answer }; } e();",
+        "loop_output": "${loop.output}"
+      }
+    }
+  ],
+  "outputParameters": {
+    "iterations": "${loop.output.iteration}",
+    "answer": "${final.output.result.answer}"
+  },
+  "timeoutSeconds": 600,
+  "timeoutPolicy": "TIME_OUT_WF"
+}

package/skills/conductor/examples/workflows/ai-agent-mcp.json

@@ -0,0 +1,69 @@
+{
+  "name": "my_first_agent",
+  "description": "AI agent that discovers MCP tools, plans, executes, and summarizes",
+  "version": 1,
+  "schemaVersion": 2,
+  "inputParameters": ["task"],
+  "tasks": [
+    {
+      "name": "discover_tools",
+      "taskReferenceName": "discover",
+      "type": "LIST_MCP_TOOLS",
+      "inputParameters": {
+        "mcpServer": "http://localhost:3001/mcp"
+      }
+    },
+    {
+      "name": "plan_action",
+      "taskReferenceName": "plan",
+      "type": "LLM_CHAT_COMPLETE",
+      "inputParameters": {
+        "llmProvider": "openai",
+        "model": "gpt-4o-mini",
+        "messages": [
+          {
+            "role": "system",
+            "message": "You are an AI agent. Available tools: ${discover.output.tools}. Pick exactly one tool and respond as JSON with fields `method` and `arguments`."
+          },
+          {
+            "role": "user",
+            "message": "${workflow.input.task}"
+          }
+        ],
+        "temperature": 0.1,
+        "maxTokens": 500
+      }
+    },
+    {
+      "name": "execute_tool",
+      "taskReferenceName": "execute",
+      "type": "CALL_MCP_TOOL",
+      "inputParameters": {
+        "mcpServer": "http://localhost:3001/mcp",
+        "method": "${plan.output.result.method}",
+        "arguments": "${plan.output.result.arguments}"
+      }
+    },
+    {
+      "name": "summarize_result",
+      "taskReferenceName": "summarize",
+      "type": "LLM_CHAT_COMPLETE",
+      "inputParameters": {
+        "llmProvider": "openai",
+        "model": "gpt-4o-mini",
+        "messages": [
+          {
+            "role": "user",
+            "message": "The user asked: \"${workflow.input.task}\". Tool returned: ${execute.output.content}. Reply in one short paragraph."
+          }
+        ],
+        "maxTokens": 500
+      }
+    }
+  ],
+  "outputParameters": {
+    "plan": "${plan.output.result}",
+    "toolResult": "${execute.output.content}",
+    "summary": "${summarize.output.result}"
+  }
+}

package/skills/conductor/examples/workflows/child-normalize.json

@@ -0,0 +1,21 @@
+{
+  "name": "child_normalize",
+  "description": "Normalize a user payload (lowercase email, trim name)",
+  "version": 1,
+  "schemaVersion": 2,
+  "inputParameters": ["payload"],
+  "tasks": [
+    {
+      "name": "transform",
+      "taskReferenceName": "transform",
+      "type": "JSON_JQ_TRANSFORM",
+      "inputParameters": {
+        "data": "${workflow.input.payload}",
+        "queryExpression": "{name: (.name | ascii_downcase | gsub(\"^\\\\s+|\\\\s+$\"; \"\")), email: (.email | ascii_downcase)}"
+      }
+    }
+  ],
+  "outputParameters": {
+    "normalized": "${transform.output.result}"
+  }
+}

package/skills/conductor/examples/workflows/do-while-loop.json

@@ -0,0 +1,35 @@
+{
+  "name": "paginated_fetch",
+  "description": "Fetch N pages from an endpoint via DO_WHILE",
+  "version": 1,
+  "schemaVersion": 2,
+  "inputParameters": ["endpoint", "count"],
+  "tasks": [
+    {
+      "name": "loop",
+      "taskReferenceName": "loop_ref",
+      "type": "DO_WHILE",
+      "loopCondition": "if ($.loop_ref['iteration'] < $.value) { true; } else { false; }",
+      "loopOver": [
+        {
+          "name": "do_work",
+          "taskReferenceName": "do_work",
+          "type": "HTTP",
+          "inputParameters": {
+            "http_request": {
+              "uri": "${workflow.input.endpoint}?page=${loop_ref.output.iteration}",
+              "method": "GET"
+            }
+          }
+        }
+      ],
+      "inputParameters": {
+        "value": "${workflow.input.count}",
+        "loop_ref": "${loop_ref.output}"
+      }
+    }
+  ],
+  "outputParameters": {
+    "iterations": "${loop_ref.output.iteration}"
+  }
+}

package/skills/conductor/examples/workflows/fork-join.json

@@ -0,0 +1,61 @@
+{
+  "name": "parallel_fetch",
+  "description": "Fetch inventory and pricing in parallel, then merge",
+  "version": 1,
+  "schemaVersion": 2,
+  "inputParameters": ["inventoryUrl", "pricingUrl"],
+  "tasks": [
+    {
+      "name": "fork",
+      "taskReferenceName": "fork",
+      "type": "FORK_JOIN",
+      "forkTasks": [
+        [
+          {
+            "name": "fetch_inventory",
+            "taskReferenceName": "inventory",
+            "type": "HTTP",
+            "inputParameters": {
+              "http_request": {
+                "uri": "${workflow.input.inventoryUrl}",
+                "method": "GET"
+              }
+            }
+          }
+        ],
+        [
+          {
+            "name": "fetch_pricing",
+            "taskReferenceName": "pricing",
+            "type": "HTTP",
+            "inputParameters": {
+              "http_request": {
+                "uri": "${workflow.input.pricingUrl}",
+                "method": "GET"
+              }
+            }
+          }
+        ]
+      ]
+    },
+    {
+      "name": "join",
+      "taskReferenceName": "join",
+      "type": "JOIN",
+      "joinOn": ["inventory", "pricing"]
+    },
+    {
+      "name": "merge",
+      "taskReferenceName": "merge",
+      "type": "JSON_JQ_TRANSFORM",
+      "inputParameters": {
+        "inventory": "${inventory.output.response.body}",
+        "pricing": "${pricing.output.response.body}",
+        "queryExpression": "{items: .inventory.items, prices: .pricing.prices}"
+      }
+    }
+  ],
+  "outputParameters": {
+    "merged": "${merge.output.result}"
+  }
+}