メニュー
Debug failed or wrong-output workflow executions using executions tools. Load when the user reports execution failures, unexpected node output, or empty parameter values after a successful run.
ONLY for coordinated multi-artifact work: multiple workflows with dependencies, shared data-table schema/migration across tasks, or the user explicitly asked to review a plan first. Do NOT use for new one-off workflows, single-workflow edits, verification-only requests, or standalone data-table ops — use workflow-builder or data-table-manager instead.
Default path for all single-workflow work: new one-off workflows, existing- workflow edits, verification repairs, and workflow-local data tables. Use build-workflow directly — 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.
Designs and manages n8n Data Tables directly with the data-tables and parse-file tools. Use when the user asks to list, show, create, inspect, import, seed, query, update, clean up, rename columns in, or delete data tables and rows, especially from CSV/XLSX/JSON attachments, and before building or planning workflows that create or write to Data Tables.
Handles system follow-up turns: planned-task-follow-up (synthesize, replan, build-workflow, checkpoint), background-task-completed, running-tasks context, create-tasks silence rules, and detached delegate completion. Load whenever any of these tags appear or after spawning create-tasks or delegate.
Handles workflow verification and setup after build-workflow succeeds, or when the message contains workflow-verification-follow-up or workflow-setup-required. Load after direct builds, when verificationReadiness requires action, or on orchestrator verify/setup follow-up turns.
Guides work on `packages/frontend/editor-ui` experiments. Use when creating, extending, wiring, testing, reviewing, or retiring editor-ui experiments, PostHog feature flags, experiment key indexes, variants, stores/composables, persisted experiment state, or experiment telemetry.
| name | debugging-executions |
| description | Debug failed or wrong-output workflow executions using executions tools. Load when the user reports execution failures, unexpected node output, or empty parameter values after a successful run. |
| recommended_tools | ["executions","workflows"] |
Use this skill when debugging workflow execution failures or successful runs with wrong or empty values.
Use executions(action="run") with inputData matching the trigger's output
shape — do not rebuild the workflow with a Manual Trigger. For trigger
inputData shapes, read knowledge-base/reference/trigger-input-data-shapes.md
when a sandbox workspace is available.
executions(action="debug") already includes failedNode.resolvedParameters —
start there. That bundle has parameters (raw, with expressions intact),
resolved (substituted), failedExpressions (those that threw), and
emptyResolutions (those that resolved to null/undefined/"" silently).
The offending expression is usually visible without a follow-up call. Entries in
either list tagged with reason: "unreconstructable-context" are NOT real bugs —
they reference variables we don't reconstruct in replay ($vars, $secrets,
$response, $request, $pageCount, $ai). The value existed at execution
time; we just don't have it here.
When debug doesn't apply because nothing errored, call
executions(action="get-resolved-node-parameters", executionId, nodeName) on the
node whose output looks off — do this unprompted, don't ask the user for
permission first. It's a cheap read-only inspection and the only reliable way to
confirm whether an empty value came from an expression silently resolving to
nullish. Check emptyResolutions first; most "this parameter is empty" cases are
expressions resolving to null/undefined/"", not thrown errors.
