workflow-builder

Contributors

GitHub-linked commit authors for this SKILL.md at the saved revision. Co-authors and history before file renames are not included.

File history ↗

Load before calling build-workflow. Default path for all single-workflow work: new one-off workflows, existing-workflow edits, verification repairs, and workflow-local data tables. Write or edit a workspace source file, run workflow-sdk validate via workspace_execute_command, then call build-workflow with filePath. When the workflow creates or writes Data Tables, load data-table-manager first, then this skill. Do not load planning or create-tasks first. Load planning only when multiple coordinated workflows or shared cross-task data tables require a dependency-aware task graph.

packages/@n8n/instance-ai/skills/workflow-builder/SKILL.md

Download bundle ↓
master · 8bff5da3 bundle filesScanned 2026-09-15

references/compositional-workflows.md

520 tokens · o200k_base · 2,180 bytes

Source excerpt starting at line 1.
# Compositional Workflows For complex workflows, you may decompose work into supporting sub-workflows anda main workflow. This is part of an approved build task, not a reason to create a new plan. Use this pattern when a workflow is large, has reusable chunks, or benefits fromindependent testing. Simple workflows should stay in one workflow. 1. Write a source file for each supporting workflow, then build it with   `build-workflow` and `isSupportingWorkflow: true`.2. Give each supporting workflow an `executeWorkflowTrigger` (version 1.1) with   an explicit input schema.3. Use the returned supporting `workflowId` in the main workflow's   `executeWorkflow` node with `source: 'database'`.4. Create or edit the main workflow source file last, then save it with   `build-workflow` and without `isSupportingWorkflow`; this is the build task's   final deliverable outcome.5. Do not publish the main workflow automatically. Supporting workflows may be   published when the parent workflow needs them active for verification or   runtime references, but only after their setup requirements are resolved. Example supporting workflow trigger: ```tsconst inputTrigger = trigger({  type: 'n8n-nodes-base.executeWorkflowTrigger',  version: 1.1,  config: {    parameters: {      inputSource: 'workflowInputs',      workflowInputs: {        values: [          { name: 'city', type: 'string' },          { name: 'units', type: 'string' },        ],      },    },  },});``` Example main-workflow reference: ```tsconst getWeather = node({  type: 'n8n-nodes-base.executeWorkflow',  version: 1.2,  config: {    name: 'Get Weather Data',    parameters: {      source: 'database',      workflowId: { __rl: true, mode: 'id', value: 'SUPPORTING_WORKFLOW_ID' },      mode: 'once',      workflowInputs: {        mappingMode: 'defineBelow',        value: { city: expr('{{ $json.city }}'), units: 'metric' },      },    },  },});``` Replace `SUPPORTING_WORKFLOW_ID` with the real ID returned by the supporting`build-workflow` call. If a supporting workflow uses mocked credentials orplaceholders, route setup before publishing or relying on it. 
Referenced from SKILL.md