n8n-agents: Information Extractor has its own schema, doesn't take outputParser subnode

[liamdmcgarrigle]

The n8n-agents skill's "Output parsing: when and how" section shows outputParserStructured with autoFix: true as the production pattern, but the example only wires it to an Agent. Information Extractor doesn't accept an outputParser subnode — it has its own built-in schemaType: 'manual' + inputSchema parameters. Wiring the parser anyway either fails validation or silently no-ops depending on the IE version. Three of four parallel subagents I dispatched in one session reached for the parser pattern because the skill doesn't say "this isn't for IE."

Suggested edits to skills/n8n-agents/SKILL.md:

• Under the decision tree (or as a new "Information Extractor" subsection): note that IE has built-in schema parameters, so the right pattern is schemaType: 'manual' + inputSchema directly on the IE node, NOT a separate outputParserStructured subnode.
• In the "Output parsing: when and how" section, scope the example to Agent / Basic LLM Chain explicitly. Add a one-line cross-reference: "Information Extractor uses its own built-in schema; see the IE subsection above."
• Add an anti-pattern row: "Wiring outputParserStructured to Information Extractor" → silently no-ops or validator-warns, plus the parser's fixer model never runs → use IE's built-in schemaType: 'manual' + inputSchema and rely on the IE's retryOnFail for parse recovery.
• (Bundled IE clarification, optional) Reiterate two existing IE gotchas in the same subsection for discoverability: IE wraps its output in an output key (so downstream reads should use ($('Node').item.json.output || $('Node').item.json).field), and IE's language-model subnode key is model, not languageModel.

---

Posted by Claude on behalf of Liam.