Synthèse automatique
Guide la manipulation structurelle des fichiers JSON de workflow n8n (nœuds, connexions, JavaScript des Code nodes) pour le pipeline Vigil Guard v2.0.0.
Points forts
- Décrit précisément le schéma JSON n8n (nodes, connections, settings, positions) et la façon d'ajouter, retirer ou réordonner des nœuds
- Explique la logique du 3-Branch Executor parallèle et la fusion pondérée d'Arbiter v2 telle qu'implémentée dans la v2.0.0
- Rappelle le cycle de vie critique : le workflow s'exécute depuis SQLite, le fichier JSON n'est qu'une sauvegarde jusqu'à l'import via l'interface n8n
- Fournit un modèle de communication opérateur pour exiger l'import immédiat après chaque modification
Limites
- Fortement spécifique au projet Vigil Guard v2.0.0 (24 nœuds) et peu réutilisable tel quel sur d'autres workflows n8n
- Ne couvre volontairement pas les patterns de détection ni la logique métier, renvoyés à une autre skill
- Suppose une instance n8n locale accessible via l'interface pour finaliser le cycle d'import
À utiliser dès qu'il faut éditer la structure d'un fichier workflow n8n, recâbler des connexions ou modifier le JavaScript embarqué d'un Code node.
À éviter pour concevoir des règles de détection, déboguer la logique métier ou travailler sur un workflow n8n sans rapport avec Vigil Guard.
Analyse de sécurité
SûrThe skill is a documentation guide for managing n8n workflow JSON files. It does not contain destructive commands, exfiltration instructions, or obfuscated payloads. Allowed tools include Bash, but the skill text itself does not provide any malicious Bash commands. It focuses on file editing and workflow management, which are legitimate uses. No security concerns identified.
Aucun point d'attention détecté
Comment cette analyse est faiteExemples
In services/workflow/workflows/Vigil Guard v2.0.0.json, add a new Code node called Normalize_Input between the Webhook and the Preprocessor, and update the connections block so data flows through it correctly.Rewrite the JavaScript inside the 3-Branch Executor node so it fans out three parallel HTTP calls and merges their responses into a single item, keeping the existing node ID and position.I edited the workflow JSON but nothing changed at runtime — walk me through the import-to-n8n-GUI step and check that my connections and node names in the JSON are consistent.name: workflow-json-architect description: n8n workflow JSON structure management for Vigil Guard v2.0.0 (24-node 3-branch parallel pipeline). Use for node manipulation, connections, Code node JavaScript, 3-Branch Executor logic, Arbiter v2 integration, and critical reminder to import workflow to n8n GUI. version: 2.0.0 allowed-tools: [Read, Write, Edit, Bash, Grep, Glob]
n8n Workflow JSON Architecture Management (v2.0.0)
Overview
Expert guidance for managing n8n workflow JSON files (24 nodes, 3-branch parallel detection) in Vigil Guard v2.0.0. This skill focuses exclusively on the JSON structure, node manipulation, connections, and workflow lifecycle - NOT on detection patterns or business logic (see n8n-vigil-workflow for patterns).
When to Use This Skill
- Modifying workflow JSON structure (
Vigil Guard v2.0.0.json) - Adding/removing/reordering nodes
- Editing Code node embedded JavaScript
- Managing node connections and data flow
- Working with 3-Branch Executor node
- Configuring Arbiter v2 weighted fusion
- Migrating workflows between versions
- Debugging workflow execution errors
- Understanding n8n JSON schema
- Explaining to user: "Import workflow to n8n GUI NOW!"
v2.0.0 Architecture Change
From 40-node Sequential → 24-node 3-Branch Parallel
OLD (v1.x): 40+ nodes, sequential processing, rules.config.json
NEW (v2.0.0): 24 nodes, 3-branch parallel detection
- 3-Branch Executor (parallel HTTP calls)
- Arbiter v2 (weighted fusion)
- No rules.config.json (patterns in heuristics-service)
CRITICAL: Workflow Lifecycle Understanding
The #1 Most Important Concept
n8n workflows are stored in SQLite database, NOT in JSON files!
TRUTH:
- Workflow execution reads from: SQLite database (/home/node/.n8n/database.sqlite)
- JSON file in repo is: Backup/version control ONLY
- Changes to JSON have NO EFFECT until user imports to n8n GUI
WORKFLOW:
1. Edit JSON file in repo
2. IMMEDIATELY tell user: " IMPORT THIS FILE TO n8n GUI NOW!"
3. User imports via: n8n GUI → Import from File
4. n8n copies JSON → SQLite database
5. Workflow executes from SQLite (NOT from file)
CROWN RULE: WORKFLOW IMPORT STATUS - OPERATOR TRUST AXIOM
ABSOLUTELY FORBIDDEN DEBUGGING HYPOTHESES:
NEVER CHECK:
- "Was the workflow imported?"
- "Is the workflow in n8n SQL database?"
- "Is the workflow active?"
- "Did you activate the workflow after import?"
INDISPUTABLE FACT:
- If operator confirmed import: workflow IS imported
- Workflow IS in SQLite database
- Workflow IS active
- All Code nodes have LATEST JavaScript from JSON file
- This is 100% TRUTH without verification
CORRECT DEBUGGING APPROACH:
- Operator confirms import → END OF STORY
- Problem is NOT in import
- Problem IS in workflow logic
- Debug: analyze node code, tests, configuration
- DO NOT waste tokens verifying import
User Communication Template
Workflow JSON updated successfully!
**CRITICAL NEXT STEP - DO THIS NOW:**
1. Open n8n GUI: http://localhost:5678
2. Click menu (≡) → **Import from File**
3. Select: `services/workflow/workflows/Vigil Guard v2.0.0.json`
4. Confirm import
5. Activate workflow (toggle switch)
**Your changes will NOT work until you complete this import!**
After importing, test with: n8n GUI → Test workflow → Chat tab
Workflow JSON Structure (v2.0.0)
Top-Level Schema
{
"name": "Vigil Guard v2.0.0",
"nodes": [
{
"parameters": {},
"id": "unique-uuid",
"name": "Node_Name",
"type": "n8n-nodes-base.code",
"typeVersion": 2,
"position": [x, y]
}
],
"connections": {
"Source_Node": {
"main": [
[
{
"node": "Target_Node",
"type": "main",
"index": 0
}
]
]
}
},
"settings": {
"executionOrder": "v1"
},
"updatedAt": "2025-01-30T10:00:00.000Z",
"versionId": "uuid"
}
24-Node Architecture (v2.0.0)
1. When chat message received # Chat trigger
2. Webhook v2 # HTTP webhook trigger
3. Extract Input # Normalize input format
4. Load allowlist.schema.json # Load allowlist config
5. Load pii.conf # Load PII patterns (361 lines)
6. Load unified_config.json # Load main config (303 lines, v5.0.0)
7. Extract allowlist # Parse allowlist
8. Extract pii.conf # Parse PII config
9. Extract unified_config # Parse main config
10. Merge Config # Combine all configs
11. Config Loader v2 # Final config object
12. Input Validator v2 # Validate input (length, format)
13. Validation Check # Route based on validation
14. 3-Branch Executor # PARALLEL branch execution (CRITICAL)
15. Arbiter v2 # Weighted score fusion (CRITICAL)
16. Arbiter Decision # Route based on score
17. PII_Redactor_v2 # Dual-language PII detection
18. Block Response v2 # Generate block response
19. Merge Final # Merge all paths
20. Build NDJSON v2 # Format for logging
21. Log to ClickHouse v2 # Send to analytics DB
22. Clean Output v2 # User-facing result
23. Early Block v2 # Fast-path for validation failures
24. output to plugin # Browser extension response
Node Types
Core Processing Nodes:
- Code - Custom JavaScript logic (most common)
- HTTP Request - API calls (3-branch services, Presidio, ClickHouse)
- Merge - Combine data streams (config merge, path merge)
- Switch - Conditional routing (thresholds)
- Set - Variable assignment
- Webhook - Trigger endpoint
Data Flow (3-Branch Parallel)
Webhook Trigger
→ Extract Input
→ Config Loader v2 (merge configs)
→ Input Validator v2
→ 3-Branch Executor (PARALLEL):
├─ HTTP: heuristics-service:5005 (Branch A)
├─ HTTP: semantic-service:5006 (Branch B)
└─ HTTP: prompt-guard-api:8000 (Branch C)
→ Arbiter v2 (weighted fusion: A*0.30 + B*0.35 + C*0.35)
→ Arbiter Decision (Switch)
├─ ALLOW → Clean Output
├─ SANITIZE → PII_Redactor_v2 → Clean Output
└─ BLOCK → Block Response
→ Build NDJSON v2
→ Log to ClickHouse v2
→ Clean Output v2
Common Tasks
Task 1: Modify 3-Branch Executor
Example: Add timeout to branch calls
// Find 3-Branch Executor node
const branchNode = workflow.nodes.find(n => n.name === "3-Branch Executor");
// Modify HTTP parameters for each branch
branchNode.parameters = {
jsCode: `
const items = $input.all();
const text = items[0].json.sanitized_input || items[0].json.chatInput;
const requestId = items[0].json.request_id || 'default';
// Branch timeouts (v2.0.0)
const TIMEOUTS = {
A: 1000, // Heuristics: 1 second
B: 2000, // Semantic: 2 seconds
C: 3000 // LLM Guard: 3 seconds
};
// Parallel branch execution
const [branchA, branchB, branchC] = await Promise.allSettled([
// Branch A: Heuristics Service
fetch('http://heuristics-service:5005/analyze', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text, request_id: requestId }),
signal: AbortSignal.timeout(TIMEOUTS.A)
}).then(r => r.json()),
// Branch B: Semantic Service
fetch('http://semantic-service:5006/analyze', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text, request_id: requestId }),
signal: AbortSignal.timeout(TIMEOUTS.B)
}).then(r => r.json()),
// Branch C: LLM Guard
fetch('http://prompt-guard-api:8000/detect', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text }),
signal: AbortSignal.timeout(TIMEOUTS.C)
}).then(r => r.json())
]);
return [{
json: {
...items[0].json,
branch_results: {
A: branchA.status === 'fulfilled' ? branchA.value : { score: 0, degraded: true },
B: branchB.status === 'fulfilled' ? branchB.value : { score: 0, degraded: true },
C: branchC.status === 'fulfilled' ? branchC.value : { score: 0, degraded: true }
}
}
}];
`
};
Task 2: Modify Arbiter v2 Weights
Example: Change branch weights
// Find Arbiter v2 node
const arbiterNode = workflow.nodes.find(n => n.name === "Arbiter v2");
// Modify weighted fusion logic
arbiterNode.parameters.jsCode = `
const items = $input.all();
const branches = items[0].json.branch_results;
// v2.0.0 Weighted fusion
const WEIGHTS = {
A: 0.30, // Heuristics
B: 0.35, // Semantic
C: 0.35 // LLM Guard
};
// Calculate weighted score
const weightedScore =
(branches.A.score || 0) * WEIGHTS.A +
(branches.B.score || 0) * WEIGHTS.B +
(branches.C.score || 0) * WEIGHTS.C;
// Critical signal override
const criticalOverride =
branches.A.critical_signals?.obfuscation_heavy ||
branches.C.critical_signals?.llm_attack;
// Decision matrix
let decision;
if (criticalOverride || weightedScore >= 85) {
decision = 'BLOCK';
} else if (weightedScore >= 30) {
decision = 'SANITIZE';
} else {
decision = 'ALLOW';
}
return [{
json: {
...items[0].json,
threat_score: weightedScore,
arbiter_decision: decision,
critical_override: criticalOverride
}
}];
`;
Task 3: Add New Node
Example: Add post-processing step
// 1. Create new node
const newNode = {
"parameters": {
"jsCode": `
const items = $input.all();
// Your processing logic
return items.map((item, index) => ({
json: {
...item.json,
processed: true
},
pairedItem: { item: index }
}));
`
},
"id": crypto.randomUUID(),
"name": "Post_Processing",
"type": "n8n-nodes-base.code",
"typeVersion": 2,
"position": [1500, 300]
};
// 2. Insert into nodes array
workflow.nodes.push(newNode);
// 3. Update connections
// Find where to insert (after Arbiter Decision, before Clean Output)
workflow.connections["Arbiter Decision"].main[0][0].node = "Post_Processing";
workflow.connections["Post_Processing"] = {
"main": [[{ "node": "Clean Output v2", "type": "main", "index": 0 }]]
};
// 4. Save and tell user to import
Task 4: Migrate from v1.x to v2.0.0
Migration Checklist:
// 1. Update workflow name
workflow.name = "Vigil Guard v2.0.0";
// 2. Replace 40-node sequential with 24-node parallel
// - Remove all sequential pattern matching nodes
// - Add 3-Branch Executor
// - Add Arbiter v2
// 3. Remove rules.config.json references
// - Pattern matching now in heuristics-service
// - Categories in unified_config.json
// 4. Update ClickHouse logging
const loggingNode = workflow.nodes.find(n => n.name.includes("NDJSON"));
loggingNode.parameters.jsCode = loggingNode.parameters.jsCode
.replace(/"pipeline_version": "1\.\d+\.\d+"/, '"pipeline_version": "2.0.0"')
+ `
// v2.0.0: Add branch columns
result.branch_a_score = items[0].json.branch_results?.A?.score || 0;
result.branch_b_score = items[0].json.branch_results?.B?.score || 0;
result.branch_c_score = items[0].json.branch_results?.C?.score || 0;
result.arbiter_decision = items[0].json.arbiter_decision;
result.branch_a_timing_ms = items[0].json.timing?.branch_a_ms || 0;
result.branch_b_timing_ms = items[0].json.timing?.branch_b_ms || 0;
result.branch_c_timing_ms = items[0].json.timing?.branch_c_ms || 0;
`;
// 5. Update workflow metadata
workflow.updatedAt = new Date().toISOString();
workflow.versionId = crypto.randomUUID();
Code Node Patterns (v2.0.0)
Pattern 1: Data Access
// Get all input items
const items = $input.all();
// Access first item's JSON
const data = items[0].json;
// Access branch results (v2.0.0)
const branchA = data.branch_results?.A;
const branchB = data.branch_results?.B;
const branchC = data.branch_results?.C;
Pattern 2: Returning Modified Data
// Return modified items (preserves pairedItem for tracing)
return items.map((item, index) => ({
json: {
...item.json,
new_field: "value"
},
pairedItem: {
item: index
}
}));
Pattern 3: Accessing Config Data
// Config loaded via Merge node, available in all downstream Code nodes
const items = $input.all();
const contextItem = items[0];
// Access config sections (v2.0.0: unified_config.json)
const unified = contextItem.json.config; // unified_config.json (303 lines)
const piiConfig = contextItem.json.pii; // pii.conf (361 lines)
// Use config values
const allowMax = unified.thresholds?.allow_max || 29;
const sanitizeLight = unified.thresholds?.sanitize_light || 64;
Pattern 4: Branch Result Handling
// Handle degraded branches (timeout/error)
const branches = items[0].json.branch_results;
for (const [id, result] of Object.entries(branches)) {
if (result.degraded) {
console.log(`Branch ${id} degraded, using score 0`);
result.score = 0;
}
}
// Calculate weighted score
const score =
branches.A.score * 0.30 +
branches.B.score * 0.35 +
branches.C.score * 0.35;
Pattern 5: HTTP Request Error Handling
try {
const response = await fetch('http://heuristics-service:5005/analyze', {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text, request_id: requestId }),
signal: AbortSignal.timeout(1000) // 1 second timeout
});
if (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}
return await response.json();
} catch (error) {
console.error('Branch A error:', error.message);
return { score: 0, degraded: true, error: error.message };
}
Node Positioning (Visual Layout)
Grid System
- X-axis: 0 (left) → 2000+ (right)
- Y-axis: 0 (top) → 1200+ (bottom)
- Spacing: 220 pixels between nodes horizontally
- Vertical offset: 100-150 pixels for parallel branches
Example Layout (v2.0.0)
// Sequential flow (left to right)
nodes[0].position = [240, 300]; // Webhook Trigger
nodes[1].position = [460, 300]; // Extract Input
nodes[2].position = [680, 300]; // Config Loader
nodes[3].position = [900, 300]; // Input Validator
// 3-Branch Executor (single node, handles parallel internally)
nodes[4].position = [1120, 300]; // 3-Branch Executor
// Post-branch processing
nodes[5].position = [1340, 300]; // Arbiter v2
nodes[6].position = [1560, 300]; // Arbiter Decision
Connection Syntax
Simple Connection (A → B)
{
"connections": {
"Node_A": {
"main": [
[{ "node": "Node_B", "type": "main", "index": 0 }]
]
}
}
}
Switch Node (Conditional - Arbiter Decision)
{
"connections": {
"Arbiter Decision": {
"main": [
[{ "node": "Clean Output v2", "type": "main", "index": 0 }],
[{ "node": "PII_Redactor_v2", "type": "main", "index": 0 }],
[{ "node": "Block Response v2", "type": "main", "index": 0 }]
]
}
}
}
Debugging Workflow Execution
Common Error Patterns
Error: Branch timeout
// Problem: Branch service takes too long
// Solution: Increase timeout or check service health
// Check service health
curl http://localhost:5005/health // Heuristics
curl http://localhost:5006/health // Semantic
curl http://localhost:8000/health // LLM Guard
Error: "Cannot read property 'branch_results' of undefined"
// Problem: 3-Branch Executor didn't return results
// Solution: Check branch node output and add fallback
const branches = items[0].json.branch_results || {
A: { score: 0, degraded: true },
B: { score: 0, degraded: true },
C: { score: 0, degraded: true }
};
Enable Debug Logging
// Add to Code nodes for debugging
console.log('=== Node Name Debug ===');
console.log('Input:', JSON.stringify($input.all(), null, 2));
console.log('Branch Results:', JSON.stringify(items[0].json.branch_results, null, 2));
console.log('Arbiter Decision:', items[0].json.arbiter_decision);
View Logs:
docker logs vigil-n8n | grep "Debug"
Performance Optimization
Parallel Branch Execution
// 3-Branch Executor uses Promise.allSettled for parallel execution
// Each branch runs independently, no blocking
const [branchA, branchB, branchC] = await Promise.allSettled([
fetchBranchA(text),
fetchBranchB(text),
fetchBranchC(text)
]);
// All branches complete in max(timeoutA, timeoutB, timeoutC)
// Not sequential: timeoutA + timeoutB + timeoutC
Cache Config Data
// Config loaded once at start, reused in all nodes
const config = $('Config_Loader_v2').all()[0].json.config;
// Don't reload in every node
Integration with Other Skills
When to Use Other Skills
n8n-vigil-workflow:
- Understanding 3-branch detection logic
- Modifying decision thresholds
- PII detection configuration
- Business logic changes
pattern-library-manager:
- Adding detection patterns (heuristics-service)
- ReDoS validation
vigil-testing-e2e:
- Writing tests for modified workflow
- Validating arbiter decisions
- Testing branch behavior
clickhouse-grafana-monitoring:
- Verifying workflow logs branch columns correctly
- Analyzing branch metrics
Reference Files
Workflow
- Current:
services/workflow/workflows/Vigil Guard v2.0.0.json - Backups:
services/workflow/workflows/backups/
Configuration
services/workflow/config/unified_config.json(303 lines, v5.0.0)services/workflow/config/pii.conf(361 lines)
Documentation
- Architecture:
docs/ARCHITECTURE.md - n8n docs: https://docs.n8n.io/
Quick Reference
Essential Commands
# View workflow structure
cat services/workflow/workflows/Vigil*.json | jq .
# Count nodes (expected: 24)
jq '.nodes | length' services/workflow/workflows/Vigil*.json
# List node names
jq -r '.nodes[].name' services/workflow/workflows/Vigil*.json
# Find 3-Branch Executor
jq '.nodes[] | select(.name | contains("Branch"))' services/workflow/workflows/Vigil*.json
# Extract Arbiter v2 code
jq -r '.nodes[] | select(.name == "Arbiter v2") | .parameters.jsCode' services/workflow/workflows/Vigil*.json
Node Checklist (Before Commit)
- [ ] Node has unique
id(UUID) - [ ] Node has valid
type(n8n-nodes-base.*) - [ ] Node has
position[x, y] - [ ] Node has incoming connection (or is trigger)
- [ ] Node has outgoing connection (or is terminal)
- [ ] Code node JavaScript is syntactically valid
- [ ] pairedItem preserved in return statements
- [ ] Error handling implemented (try/catch)
- [ ] Branch degradation handled (score=0 on timeout)
- [ ] Workflow
updatedAttimestamp updated - [ ] User instructed: "Import to n8n NOW!"
Last Updated: 2025-12-09 Workflow Version: v2.0.0 (24 nodes, 3-branch parallel) Maintained By: Vigil Guard Development Team
Version History
- v2.0.0 (Current): 24 nodes, 3-branch parallel, Arbiter v2
- v1.7.0: 41 nodes, sequential pipeline
- v1.6.11: 40 nodes, rules.config.json (DEPRECATED)
Du fichier au premier essai
Le téléchargement contient exactement le contenu affiché sur cette fiche. Cette copie peut différer de la dernière version du dépôt source.
Consulter la source et ses fichiers annexesCe téléchargement contient uniquement SKILL.md. Les scripts, références, modèles et dépendances éventuels ne sont pas inclus. Récupérez les fichiers nécessaires depuis la source en conservant leur arborescence avant de poursuivre.
1. Télécharger le fichier
Télécharger SKILL.mdDepuis la racine d’un projet de test, enregistrez le fichier sous .skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md, ou utilisez la commande suivante. Ce dossier sert à examiner la skill avant son installation.
Commande pour macOS/Linux ou WSL : un shell POSIX et curl sont nécessaires. Sous Windows sans WSL, utilisez le bouton de téléchargement et créez le dossier manuellement.
mkdir -p '.skill-downloads/n8n-workflow-json-management-mse7ini0' && curl --fail --show-error --location 'https://skills-guides.com/api/skills/n8n-workflow-json-management-mse7ini0/download' --output '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md.part' && mv '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md.part' '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md'2. Vérifier les prérequis
Lisez SKILL.md avant de l’utiliser. Si le fichier cite des scripts ou services externes, examinez-les et préparez les accès nécessaires dans votre environnement de test.
Extrait original : Quick Reference
Essential Commands
# View workflow structure
cat services/workflow/workflows/Vigil*.json | jq .
# Count nodes (expected: 24)
jq '.nodes | length' services/workflow/workflows/Vigil*.json
# List node names
jq -r '.nodes[].name' services/workflow/workflows/Vigil*.json
# Find 3-Branch Executor
jq '.nodes[] | select(.name | contains("Branch"))' services/workflow/workflows/Vigil*.json
# Extract Arbiter v2 code
jq -r '.nodes[] | select(.name == "Arbiter v2") | .parameters.jsCode' services/workflow/workflows/Vigil*.json
Node Checklist (Before Commit)
- Node has unique
id(UUID) - Node has valid
type(n8n-nodes-base.*) - Node has
position[x, y] - Node has incoming connection (or is trigger)
- Node has outgoing connection (or is terminal)
- Code node JavaScript is syntactically valid
- pairedItem preserved in return statements
- Error handling implemented (try/catch)
- Branch degradation handled (score=0 on timeout)
- Workflow
updatedAttimestamp updated - User instructed: "Import to n8n NOW!"
Last Updated: 2025-12-09 Workflow Version: v2.0.0 (24 nodes, 3-branch parallel) Maintained By: Vigil Guard Development Team
Les plateformes de la fiche sont des indications du catalogue. Les chemins ci-dessous suivent la documentation des outils ; ils ne prouvent pas que cette skill y a été exécutée. Aucune version minimale de ces outils n’est attestée pour cette fiche.
3. Charger la skill
Après vérification, copiez le dossier complet dans le projet avec l’une des commandes ci-dessous, puis ouvrez une nouvelle session de l’outil. La commande s’arrête si un dossier du même nom existe déjà : comparez les fichiers avant de le remplacer.
Claude Code
test -f '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md' && test -s '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md' && mkdir -p '.claude/skills' && test ! -e '.claude/skills/workflow-json-architect' && cp -R '.skill-downloads/n8n-workflow-json-management-mse7ini0' '.claude/skills/workflow-json-architect'Codex
test -f '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md' && test -s '.skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md' && mkdir -p '.agents/skills' && test ! -e '.agents/skills/workflow-json-architect' && cp -R '.skill-downloads/n8n-workflow-json-management-mse7ini0' '.agents/skills/workflow-json-architect'OpenSkills
OpenSkills doit déjà être installé. La procédure locale install/read est contrôlée avec OpenSkills 1.5.0, qui exige Node.js ≥ 20.6.0. Aucun slug du catalogue n’est résolu automatiquement.
Installation officielle d’OpenSkillsopenskills install './.skill-downloads/n8n-workflow-json-management-mse7ini0'openskills read 'n8n-workflow-json-management-mse7ini0'La lecture doit afficher le contenu du fichier installé et son dossier de base. Elle ne lance ni la skill ni ses dépendances.
Pour un agent qui lit AGENTS.md, synchronisez ensuite l’index. Cette commande modifie AGENTS.md : relisez le diff avant de l’utiliser.
openskills syncMode manuel ou autre outil : joignez SKILL.md à une conversation, ou ouvrez-le dans un agent capable de lire les fichiers. Ajoutez les ressources annexes nécessaires. Il n’existe pas de dossier universel reconnu par tous les outils.
4. Faire un premier essai
Utilisez une entrée courte et fictive : un endpoint d’API, un petit document ou un brief d’interface. Dans une nouvelle conversation, joignez le fichier ou donnez son chemin à l’agent, puis adaptez cette demande :
Lis .skill-downloads/n8n-workflow-json-management-mse7ini0/SKILL.md et applique ses instructions à cet exemple : [décrire une entrée de test]. Indique les fichiers, dépendances ou accès qui manquent. Produis le résultat demandé par la skill sans inventer de données ni exécuter de script non examiné.Résultat attendu : une sortie correspondant aux instructions de la skill, ou une liste précise des prérequis manquants. Une simple confirmation de lecture ne valide pas le premier usage. Si une ressource externe est indisponible, ce parcours reste à tester.
Bonnes pratiques React Hook Form
Developpement
Maîtrisez React Hook Form : évitez les anti-patterns, gérez les abonnements, et traitez correctement reset, dirty state et entrées contrôlées.
Migration Emotion vers Mantine
Developpement
Migrer les styled-components Emotion vers des composants Mantine avec style props et modules CSS. Pour convertir .styled.tsx ou supprimer les imports @emotion.
Détecteur de dérive de périmètre
Developpement
Analyse les diffs git par rapport à une intention pour détecter la dérive de périmètre, fichiers non liés et PR trop larges, puis suggère de garder, diviser ou justifier.