n8n-node-configuration

Operation-aware node configuration guidance. Use when configuring nodes, understanding property dependencies, determining required fields, choosing between get_node detail levels, or learning common configuration patterns by node type.

Author

Install

Hot:14

Download and extract to your skills directory

Copy command and send to OpenClaw for auto-install:

Download and install this skill https://openskills.cc/api/download?slug=sickn33-skills-n8n-node-configuration&locale=en&source=copy

n8n Node Configuration Expert Skill

Skill Overview

Provide guidance on configuring nodes in n8n workflows with a focus on “operation-aware” configuration. Help developers understand property dependencies, determine required fields, and master the progressive discovery method using get_node.

Applicable Scenarios

1. When Configuring n8n Nodes

When you need to add or modify node configurations for an n8n workflow, this skill guides you on how to configure fields correctly. By understanding how field requirements differ across various operations, you can avoid configuration mistakes. For example, the Slack node’s post operation requires the channel field, while the update operation requires messageId.

2. Understanding Property Dependencies

When certain fields “disappear” in the UI or fail validation, it’s usually due to displayOptions. This skill helps you understand dependencies between fields—for instance, in the HTTP Request node, the body field is shown only when sendBody is true.

3. Determining Required Fields for n8n Nodes

If you’re unsure which fields are required for the current operation, use get_node with the standard detail level to quickly get core field information. It covers 95% of configuration needs, with responses only 1–2K tokens long.

Core Functions

Operation-Aware Configuration

Different operations (operation) have different field requirements. This skill teaches you how to determine the correct configuration structure based on the resource + operation combination. For example: the IF node’s binary operators (equals, contains) require value1 and value2, while a unary operator (isEmpty) requires only value1.

Progressive Discovery Method

Recommended starting point: use get_node({ detail: "standard" }). Only upgrade to the full level if the standard details are insufficient. To find specific fields precisely, use get_node({ mode: "search_properties", propertyQuery: "..." }).

Validation-Driven Configuration

Use an iterative flow of “configure → validate → fix.” Typically, the correct configuration can be completed in 2–3 iterations on average. Read validation error messages carefully—they clearly indicate missing or incorrect fields.

Common Questions

What’s the difference between get_node’s standard and full detail levels?

standard is the default level. It returns required fields, common options, and the operation list, with responses around 1–2K tokens. It covers 95% of real usage scenarios.
full returns the complete architecture and all nested options, with responses around 3–8K tokens, and should be used only when standard is not enough.

Why does validation say some fields cannot be found?

This is usually caused by the displayOptions mechanism. A field’s presence depends on other fields’ values. For example, the HTTP Request node’s body field is shown only when sendBody is true and the method is POST/PUT/PATCH. Using the search_properties mode can help you check the display conditions.

How do field requirements change across different operations?

The operation determines which fields are required. Using the Slack node as an example:

  • post requires channel and text

  • update requires messageId and text

  • create (for channel) only requires name

  • When switching operations, make sure to use get_node again to retrieve the field requirements.