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.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
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.
Expert guidance for operation-aware node configuration with property dependencies.
When to Use
You need to configure an n8n node correctly for a specific resource and operation.
The task involves required fields, property dependencies, or choosing the right get_node detail level.
You are troubleshooting node setup rather than overall workflow architecture.
Configuration Philosophy
Progressive disclosure: Start minimal, add complexity as needed
Configuration best practices:
get_node with detail: "standard" is the most used discovery pattern
56 seconds average between configuration edits
Covers 95% of use cases with 1-2K tokens response
Key insight: Most configurations need only standard detail, 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 detail level:
get_node({detail: "standard"}) - DEFAULT
Quick overview (~1-2K tokens)
Required fields + common options
Use first - covers 95% of needs
get_node({mode: "search_properties", propertyQuery: "..."}) (for finding specific fields)
Find properties by name
Use when looking for auth, body, headers, etc.
get_node({detail: "full"}) (complete schema)
All properties (~3-8K tokens)
Use only when standard detail is insufficient
Configuration Workflow
Standard Process
1. Identify node type and operation
↓
2. Use get_node (standard detail is default)
↓
3. Configure required fields
↓
4. Validate configuration
↓
5. If field unclear → get_node({mode: "search_properties"})
↓
6. Add optional fields as needed
↓
7. Validate again
↓
8. Deploy
{
"resource": "channel",
"operation": "create",
"name": "new-channel", // Required"isPrivate": false// Optional// Note: text NOT required for this operation
}
body is required when:
- sendBody = true AND
- method IN (POST, PUT, PATCH, DELETE)
How to discover:
// Option 1: Read validation errorvalidate_node({...});
// Error: "body required when sendBody=true"// Option 2: Search for the propertyget_node({
nodeType: "nodes-base.httpRequest",
mode: "search_properties",
propertyQuery: "body"
});
// Shows: body property with displayOptions rules// 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)
