agentleFS
echoleesongecholeesong/claude-skills-plugin/skills/n8n-node-configuration/SKILL.md

n8n-node-configuration

Skill4 starsChanged 5 months agoMITView on GitHub

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

26 other projects use a version of this, 19 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use n8n-agents, n8n-error-handling and 7 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • tmolaviSkill

    n8n-agents

    Use when building n8n AI Agent / LangChain clusters — tools, memory, RAG, structured output, system prompts, sub-workflow-as-tool, or fixing agent connection topology (ai_languageModel, ai_tool, ai_memory).

    Also in 5 projects that use this

  • tmolaviSkill

    n8n-error-handling

    Use for production n8n workflows, webhook APIs, retries, error outputs, error workflows, dead-letter patterns, and correct HTTP response status shapes for callers.

    Also in 5 projects that use this

  • czlonkowskiSkill

    n8n-binary-and-data

    Handle files and binary data in n8n correctly. Use when working with files, images, PDFs, attachments, uploads or downloads, base64, vision/multimodal input, or when an AI agent needs a file as tool input or output — and whenever the user mentions $binary, binaryPropertyName, "read the PDF", "attach the file", "send the image", Merge losing binary, or a CDN for chat images. Covers the $binary vs $json split, reading/writing binary, keeping binary alive across transforms with Merge, the agent-tool binary boundary, and the CDN/URL requirement for chat surfaces.

    Also in 4 projects that use this

  • czlonkowskiSkill

    n8n-code-tool

    Write JavaScript or Python for the n8n Custom Code Tool (@n8n/n8n-nodes-langchain.toolCode) — the AI-agent-callable tool, NOT the workflow Code node. Use when building a Code Tool attached to an AI Agent, writing code that an LLM will invoke, parsing the `query` input, returning a string result, defining an input schema for structured arguments (specifyInputSchema, jsonSchemaExample, DynamicStructuredTool), or troubleshooting errors like \"Wrong output type returned\", \"No execution data available\", \"The response property should be a string, but it is an object\", \"Cannot assign to read only property 'name'\", or an AI agent that refuses to call the tool. Covers the critical differences between Code node and Code Tool: return format (string vs `[{json:{...}}]`), unavailability of `$fromAI`/`$input`/`$helpers` in the Code Tool sandbox, naming rules for AI invocation, and when to use `toolWorkflow`/HTTP Request Tool instead.

    Also in 3 projects that use this

  • BlockSkill

    frontend-design

    Create distinctive, production-grade frontend interfaces with high design quality. Use this skill when the user asks to build web components, pages, or applications. Generates creative, polished code that avoids generic AI aesthetics.

    Also in 4 projects that use this

  • +1 more from tmolavi
  • +3 more from czlonkowski

The file

Show its rules and text

We split this skill into the rules it gives an agent

19 rules. 13 are common, 6 are distinctive, and 0 are very specific to this project.

  • 13

    Common

    Most of the 22 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Progressive disclosure: Start minimal, add complexity as needed

    line 14
  2. Distinctive:

    Use when essentials isn't enough

    line 93
  3. Distinctive:

    Use when essentials + dependencies insufficient

    line 98
  4. Common:

    Step 5: Add required field

    line 159
  5. Common:

    Example: IF node conditions

    line 322
  6. Common:

    Use get_node_essentials to see operation-specific requirements

    line 385
  7. Common:

    Examples: IF, Switch, Merge

    line 426
  8. Common:

    Read validation errors carefully

    line 704
  9. Distinctive:

    If field seems missing, check dependencies

    line 707
  10. Common:

    Always check essentials when changing operation

    line 713
  11. Common:

    Don't assume configs are transferable

    line 714
  12. Common:

    Don't manually add/remove singleValue

    line 718
  13. Common:

    IF/Switch metadata added on save

    line 719
  14. Common:

    Only escalate if needed

    line 725
  15. Common:

    Always validate before deploying

    line 729
  16. Distinctive:

    Check dependencies for conditional fields

    line 731
  17. Distinctive:

    Start with get_node_essentials (91.7% success)

    line 757
  18. Distinctive:

    Check dependencies if stuck

    line 760
  19. Common:

    Progressive disclosure: Start minimal, add as needed

    line 766

“Common” is measured: kept by at least 6 in 10 of the 22 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

n8n Node Configuration

Expert guidance for operation-aware node configuration with property dependencies.


Configuration Philosophy

Progressive disclosure: Start minimal, add complexity as needed

Configuration best practices:

  • get_node_essentials is the most used discovery pattern
  • 56 seconds average between configuration edits
  • 91.7% success rate with essentials-based configuration

Key insight: Most configurations need only essentials, not full schema!


Core Concepts

1. Operation-Aware Configuration

Not all fields are always required - it depends on operation!

Example: Slack node

// For operation='post'
{
  "resource": "message",
  "operation": "post",
  "channel": "#general",  // Required for post
  "text": "Hello!"        // Required for post
}

// For operation='update'
{
  "resource": "message",
  "operation": "update",
  "messageId": "123",     // Required for update (different!)
  "text": "Updated!"      // Required for update
  // channel NOT required for update
}

Key: Resource + operation determine which fields are required!

2. Property Dependencies

Fields appear/disappear based on other field values

Example: HTTP Request node

// When method='GET'
{
  "method": "GET",
  "url": "https://api.example.com"
  // sendBody not shown (GET doesn't have body)
}

// When method='POST'
{
  "method": "POST",
  "url": "https://api.example.com",
  "sendBody": true,       // Now visible!
  "body": {               // Required when sendBody=true
    "contentType": "json",
    "content": {...}
  }
}

Mechanism: displayOptions control field visibility

3. Progressive Discovery

Use the right tool for the right job:

  1. get_node_essentials (91.7% success rate)
    • Quick overview
    • Required fields
    • Common options
    • Use first - covers 90% of needs
  2. get_property_dependencies (for complex nodes)
    • Shows what fields depend on others
    • Reveals conditional requirements
    • Use when essentials isn't enough
  3. get_node_info (full schema)
    • Complete documentation
    • All possible fields
    • Use when essentials + dependencies insufficient

Configuration Workflow

Standard Process

1. Identify node type and operation
   ↓
2. Use get_node_essentials
   ↓
3. Configure required fields
   ↓
4. Validate configuration
   ↓
5. If dependencies unclear → get_property_dependencies
   ↓
6. Add optional fields as needed
   ↓
7. Validate again
   ↓
8. Deploy

Example: Configuring HTTP Request

Step 1: Identify what you need

// Goal: POST JSON to API

Step 2: Get essentials

const info = get_node_essentials({
  nodeType: "nodes-base.httpRequest"
});

// Returns: method, url, sendBody, body, authentication required/optional

Step 3: Minimal config

{
  "method": "POST",
  "url": "https://api.example.com/create",
  "authentication": "none"
}

Step 4: Validate

validate_node_operation({
  nodeType: "nodes-base.httpRequest",
  config,
  profile: "runtime"
});
// → Error: "sendBody required for POST"

Step 5: Add required field

{
  "method": "POST",
  "url": "https://api.example.com/create",
  "authentication": "none",
  "sendBody": true
}

Step 6: Validate again

validate_node_operation({...});
// → Error: "body required when sendBody=true"

Step 7: Complete configuration

{
  "method": "POST",
  "url": "https://api.example.com/create",
  "authentication": "none",
  "sendBody": true,
  "body": {
    "contentType": "json",
    "content": {
      "name": "={{$json.name}}",
      "email": "={{$json.email}}"
    }
  }
}

Step 8: Final validation

validate_node_operation({...});
// → Valid! ✅

get_node_essentials vs get_node_info

Use get_node_essentials When:

✅ Starting configuration (91.7% success rate)

get_node_essentials({
  nodeType: "nodes-base.slack"
});

Returns:

  • Required fields
  • Common options
  • Basic examples
  • Operation list

Fast: ~18 seconds average (from search → essentials)

Use get_node_info When:

✅ Essentials insufficient

get_node_info({
  nodeType: "nodes-base.slack"
});

Returns:

  • Full schema
  • All properties
  • Complete documentation
  • Advanced options

Slower: More data to process

Decision Tree

┌─────────────────────────────────┐
│ Starting new node config?       │
├─────────────────────────────────┤
│ YES → get_node_essentials       │
└─────────────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ Essentials has what you need?   │
├─────────────────────────────────┤
│ YES → Configure with essentials │
│ NO  → Continue                  │
└─────────────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ Need dependency info?           │
├─────────────────────────────────┤
│ YES → get_property_dependencies │
│ NO  → Continue                  │
└─────────────────────────────────┘
         ↓
┌─────────────────────────────────┐
│ Still need more details?        │
├─────────────────────────────────┤
│ YES → get_node_info             │
└─────────────────────────────────┘

Property Dependencies Deep Dive

displayOptions Mechanism

Fields have visibility rules:

{
  "name": "body",
  "displayOptions": {
    "show": {
      "sendBody": [true],
      "method": ["POST", "PUT", "PATCH"]
    }
  }
}

Translation: "body" field shows when:

  • sendBody = true AND
  • method = POST, PUT, or PATCH

Common Dependency Patterns

Pattern 1: Boolean Toggle

Example: HTTP Request sendBody

// sendBody controls body visibility
{
  "sendBody": true   // → body field appears
}

Pattern 2: Operation Switch

Example: Slack resource/operation

// Different operations → different fields
{
  "resource": "message",
  "operation": "post"
  // → Shows: channel, text, attachments, etc.
}

{
  "resource": "message",
  "operation": "update"
  // → Shows: messageId, text (different fields!)
}

Pattern 3: Type Selection

Example: IF node conditions

{
  "type": "string",
  "operation": "contains"
  // → Shows: value1, value2
}

{
  "type": "boolean",
  "operation": "equals"
  // → Shows: value1, value2, different operators
}

Using get_property_dependencies

Example:

const deps = get_property_dependencies({
  nodeType: "nodes-base.httpRequest"
});

// Returns dependency tree
{
  "dependencies": {
    "body": {
      "shows_when": {
        "sendBody": [true],
        "method": ["POST", "PUT", "PATCH", "DELETE"]
      }
    },
    "queryParameters": {
      "shows_when": {
        "sendQuery": [true]
      }
    }
  }
}

Use this when: Validation fails and you don't understand why field is missing/required


Common Node Patterns

Pattern 1: Resource/Operation Nodes

Examples: Slack, Google Sheets, Airtable

Structure:

{
  "resource": "<entity>",      // What type of thing
  "operation": "<action>",     // What to do with it
  // ... operation-specific fields
}

How to configure:

  1. Choose resource
  2. Choose operation
  3. Use get_node_essentials to see operation-specific requirements
  4. Configure required fields

Pattern 2: HTTP-Based Nodes

Examples: HTTP Request, Webhook

Structure:

{
  "method": "<HTTP_METHOD>",
  "url": "<endpoint>",
  "authentication": "<type>",
  // ... method-specific fields
}

Dependencies:

  • POST/PUT/PATCH → sendBody available
  • sendBody=true → body required
  • authentication != "none" → credentials required

Pattern 3: Database Nodes

Examples: Postgres, MySQL, MongoDB

Structure:

{
  "operation": "<query|insert|update|delete>",
  // ... operation-specific fields
}

Dependencies:

  • operation="executeQuery" → query required
  • operation="insert" → table + values required
  • operation="update" → table + values + where required

Pattern 4: Conditional Logic Nodes

Examples: IF, Switch, Merge

Structure:

{
  "conditions": {
    "<type>": [
      {
        "operation": "<operator>",
        "value1": "...",
        "value2": "..."  // Only for binary operators
      }
    ]
  }
}

Dependencies:

  • Binary operators (equals, contains, etc.) → value1 + value2
  • Unary operators (isEmpty, isNotEmpty) → value1 only + singleValue: true

Operation-Specific Configuration

Slack Node Examples

Post Message

{
  "resource": "message",
  "operation": "post",
  "channel": "#general",      // Required
  "text": "Hello!",           // Required
  "attachments": [],          // Optional
  "blocks": []                // Optional
}

Update Message

{
  "resource": "message",
  "operation": "update",
  "messageId": "1234567890",  // Required (different from post!)
  "text": "Updated!",         // Required
  "channel": "#general"       // Optional (can be inferred)
}

Create Channel

{
  "resource": "channel",
  "operation": "create",
  "name": "new-channel",      // Required
  "isPrivate": false          // Optional
  // Note: text NOT required for this operation
}

HTTP Request Node Examples

GET Request

{
  "method": "GET",
  "url": "https://api.example.com/users",
  "authentication": "predefinedCredentialType",
  "nodeCredentialType": "httpHeaderAuth",
  "sendQuery": true,                    // Optional
  "queryParameters": {                  // Shows when sendQuery=true
    "parameters": [
      {
        "name": "limit",
        "value": "100"
      }
    ]
  }
}

POST with JSON

{
  "method": "POST",
  "url": "https://api.example.com/users",
  "authentication": "none",
  "sendBody": true,                     // Required for POST
  "body": {                             // Required when sendBody=true
    "contentType": "json",
    "content": {
      "name": "John Doe",
      "email": "john@example.com"
    }
  }
}

IF Node Examples

String Comparison (Binary)

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.status}}",
        "operation": "equals",
        "value2": "active"              // Binary: needs value2
      }
    ]
  }
}

Empty Check (Unary)

{
  "conditions": {
    "string": [
      {
        "value1": "={{$json.email}}",
        "operation": "isEmpty",
        // No value2 - unary operator
        "singleValue": true             // Auto-added by sanitization
      }
    ]
  }
}

Handling Conditional Requirements

Example: HTTP Request Body

Scenario: body field required, but only sometimes

Rule:

body is required when:
  - sendBody = true AND
  - method IN (POST, PUT, PATCH, DELETE)

How to discover:

// Option 1: Read validation error
validate_node_operation({...});
// Error: "body required when sendBody=true"

// Option 2: Check dependencies
get_property_dependencies({
  nodeType: "nodes-base.httpRequest"
});
// Shows: body → shows_when: sendBody=[true], method=[POST,PUT,PATCH,DELETE]

// Option 3: Try minimal config and iterate
// Start without body, validation will tell you if needed

Example: IF Node singleValue

Scenario: singleValue property appears for unary operators

Rule:

singleValue should be true when:
  - operation IN (isEmpty, isNotEmpty, true, false)

Good news: Auto-sanitization fixes this!

Manual check:

get_property_dependencies({
  nodeType: "nodes-base.if"
});
// Shows operator-specific dependencies

Configuration Anti-Patterns

❌ Don't: Over-configure Upfront

Bad:

// Adding every possible field
{
  "method": "GET",
  "url": "...",
  "sendQuery": false,
  "sendHeaders": false,
  "sendBody": false,
  "timeout": 10000,
  "ignoreResponseCode": false,
  // ... 20 more optional fields
}

Good:

// Start minimal
{
  "method": "GET",
  "url": "...",
  "authentication": "none"
}
// Add fields only when needed

❌ Don't: Skip Validation

Bad:

// Configure and deploy without validating
const config = {...};
n8n_update_partial_workflow({...});  // YOLO

Good:

// Validate before deploying
const config = {...};
const result = validate_node_operation({...});
if (result.valid) {
  n8n_update_partial_workflow({...});
}

❌ Don't: Ignore Operation Context

Bad:

// Same config for all Slack operations
{
  "resource": "message",
  "operation": "post",
  "channel": "#general",
  "text": "..."
}

// Then switching operation without updating config
{
  "resource": "message",
  "operation": "update",  // Changed
  "channel": "#general",  // Wrong field for update!
  "text": "..."
}

Good:

// Check requirements when changing operation
get_node_essentials({
  nodeType: "nodes-base.slack"
});
// See what update operation needs (messageId, not channel)

Best Practices

✅ Do

  1. Start with get_node_essentials
    • 91.7% success rate
    • Faster than get_node_info
    • Sufficient for most needs
  2. Validate iteratively
    • Configure → Validate → Fix → Repeat
    • Average 2-3 iterations is normal
    • Read validation errors carefully
  3. Use property dependencies when stuck
    • If field seems missing, check dependencies
    • Understand what controls field visibility
    • get_property_dependencies reveals rules
  4. Respect operation context
    • Different operations = different requirements
    • Always check essentials when changing operation
    • Don't assume configs are transferable
  5. Trust auto-sanitization
    • Operator structure fixed automatically
    • Don't manually add/remove singleValue
    • IF/Switch metadata added on save

❌ Don't

  1. Jump to get_node_info immediately
    • Try essentials first
    • Only escalate if needed
    • Full schema is overwhelming
  2. Configure blindly
    • Always validate before deploying
    • Understand why fields are required
    • Check dependencies for conditional fields
  3. Copy configs without understanding
    • Different operations need different fields
    • Validate after copying
    • Adjust for new context
  4. Manually fix auto-sanitization issues
    • Let auto-sanitization handle operator structure
    • Focus on business logic
    • Save and let system fix structure

Detailed References

For comprehensive guides on specific topics:

  • DEPENDENCIES.md - Deep dive into property dependencies and displayOptions
  • OPERATION_PATTERNS.md - Common configuration patterns by node type

Summary

Configuration Strategy:

  1. Start with get_node_essentials (91.7% success)
  2. Configure required fields for operation
  3. Validate configuration
  4. Check dependencies if stuck
  5. Iterate until valid (avg 2-3 cycles)
  6. Deploy with confidence

Key Principles:

  • Operation-aware: Different operations = different requirements
  • Progressive disclosure: Start minimal, add as needed
  • Dependency-aware: Understand field visibility rules
  • Validation-driven: Let validation guide configuration

Related Skills:

  • n8n MCP Tools Expert - How to use discovery tools correctly
  • n8n Validation Expert - Interpret validation errors
  • n8n Expression Syntax - Configure expression fields
  • n8n Workflow Patterns - Apply patterns with proper configuration

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.