# n8n-skills turns 545 n8n node definitions into one SKILL.md > haunchen/n8n-skills generates a static SKILL.md and a resources/ tree for Claude Code, Claude.ai and Claude Desktop, with node data read out of the n8n npm packages. You install a release zip, and the release tags sit one version behind package.json. **haunchen/n8n-skills** — Designed specifically for AI assistants, the n8n Workflow Automation Skills Suite. - Repository: https://github.com/haunchen/n8n-skills - Website: https://n8n-skills.frankchen.tw - Stars: 404 · Forks: 28 - Language: TypeScript - License: NOASSERTION - Published: 2026-09-15 · Updated: 2026-09-15 · Language: en - Canonical page: https://hysenlabs.com/projects/haunchen-n8n-skills ## The install is a release zip, and the release tags trail package.json haunchen/n8n-skills does not install from npm. The README sends you to the GitHub Releases page, tells you to download n8n-skills-{version}.zip, and stops there. What comes out of that archive is a folder with one Markdown file and one directory of node documentation, and then you put that folder wherever your Claude client looks for skills. The version numbers need reading carefully. package.json in the repository root carries version 2.23.0, while the three most recent release tags are v2.20.0 on 17 August 2026, v2.21.0 on 23 August 2026 and v2.22.0 on 30 August 2026. Following the README literally gets you v2.22.0, one release behind the source tree. That gap is narrow, but it means the archive and the repository can disagree about which n8n version the pack was generated against, and the README header pins support to n8n v2.38.7. Nothing in the top level resolves the drift for you. CHANGELOG.md and CHANGELOG.en.md sit beside the source, and the last push to the repository was on 27 September 2026, later than any of those tags. ## SKILL.md over eight resource folders, one per node category One Markdown file carries the pack. Everything else sits under resources/, split by node category. ```text n8n-skills/ ├── SKILL.md # Main skill file └── resources/ # Detailed node documentation ├── input/ # Input category nodes ├── output/ # Output category nodes ├── transform/ # Transform category nodes ├── trigger/ # Trigger category nodes ├── organization/ # Organization category nodes ├── misc/ # Miscellaneous nodes ├── community/ # Community package nodes └── templates/ # Workflow templates ``` Direction is the organising idea: input, output and transform describe where a node sits in a chain, trigger describes what starts a run, organization and misc catch the administrative remainder, community collects nodes from third-party n8n packages, and templates holds the 20 curated workflows. Scale is the reason priority ranking matters. The pack covers documentation and usage guides for 545 n8n nodes plus 30 or more popular community packages, and a multi-dimensional priority ranking system is supposed to put the useful nodes in front. An assistant handed a flat list of 545 entries has no way to guess which twenty deserve its context. ## Claude Code reads it from .claude/skills/n8n-skills Claude Code is the path with real filesystem steps. Create the skills directory inside your project, then copy the extracted pack into it. ```bash mkdir -p .claude/skills/n8n-skills ``` ```bash cp -r n8n-skills/* .claude/skills/n8n-skills/ ``` What you end up with is the layout Claude Code expects. ```text your-project/ └── .claude/ └── skills/ └── n8n-skills/ ├── SKILL.md └── resources/ ``` Verification is one prompt: ask "List available n8n nodes" and see whether the answer comes back as a node list rather than as something scraped from a web page. Two details decide whether the copy works. The relative path in the second command depends on where you extracted the archive, and the wildcard copies everything sitting in the folder, including whatever a previous install left there. The README documents no clean-up step for the destination, so reinstalling over an older pack is whatever cp makes of it. ## Both the web and desktop clients upload the same archive Claude.ai and Claude Desktop walk nearly the same road. On the web version you log in, open Settings, find the Capabilities section, click Upload skill, and select the n8n-skills-{version}.zip you downloaded. When the upload finishes, n8n-skills appears below, and if it is not enabled you click to enable it. Then you ask about n8n in the conversation window. Desktop adds one label. Settings, Capabilities, then a Skills section, then Upload skill, then the same zip. The archive being the unit of installation is the part with a cost. Whatever size limit your account applies to a skill is applied to a file that already contains 545 nodes of documentation, and there is no documented way to hand Claude.ai a subset. Anyone who wants a narrower context has to build one, and no script in package.json builds a single-category archive: build, build:full, dev, clean, rebuild, validate and start all produce the full pack. Installation for the web client is therefore all-or-nothing, while the clone is not. ## Five layers sit between the n8n packages and SKILL.md This is a generator, not a hand-written prompt. The architecture has five layers: collectors, parsers, organizers, generators and build scripts. Information comes from n8n npm packages, APIs and documentation, and leaves as a skill pack arranged for an assistant to read. The dependency list says where the source material lives. Alongside simple-git for repository work, the package depends on n8n, n8n-core, n8n-nodes-base, n8n-workflow and @n8n/n8n-nodes-langchain, with n8n pinned at ^2.38.7. Five n8n packages in one dependency list is unusual for something that produces Markdown, and it explains why the primary language GitHub reports is TypeScript rather than prose: node definitions are read out of installed packages, not transcribed. Running the generator needs a Node toolchain and a build. `npm run build` compiles TypeScript, `npm run build:full` chains that with the script that assembles the pack, and `npm start` chains the two together. `npm test` runs jest against tests/ using jest.config.js, and `npm run lint` points eslint at src. ## Where n8n-skills parts company with the n8n-mcp architecture The architecture is borrowed on purpose. The README says the project is built upon the n8n-mcp architecture from czlonkowski and converted into an n8n skill pack generator, with three additions: priority ranking, node grouping and documentation integration. Those three additions are the whole claim. n8n Skills produces files; nothing in the instructions describes a server to keep running. Priority ranking decides what an assistant reads first out of 545 nodes. Node grouping is the input, output, transform and trigger split that makes the resources/ tree navigable at all. Documentation integration pulls usage guides into each node entry instead of leaving the assistant to infer a node's parameters from its name. The supported clients match the format rather than the language: Claude Code, Claude.ai Web and Claude Desktop. Anything that reads a SKILL.md alongside a resources/ directory could in principle consume the pack, but those three are the ones with written instructions, and the three installation paths differ in whether you copy files or upload an archive. ## update:check is the dry run, and clean deletes almost all of data/cache Two script pairs carry the cost of keeping the pack current. `npm run update` builds and then runs dist/scripts/update-n8n-data.js to pull fresh n8n node data. `npm run update:check` runs the same script with --dry-run, so the change can be inspected before it is made. Community packages have their own pair, `npm run update:community` and `npm run update:community:check`. A third script, `npm run update:website`, refreshes the website/ directory. Then there is `npm run clean`, and it deserves a second read. It runs rm -rf dist output and then walks data/cache deleting every file except community-nodes.json. A cache directory that keeps exactly one file is a deliberate cache, and community-nodes.json is the entry it preserves. Output gets its own check as well: `npm run validate` builds and runs dist/scripts/validate-output.js, which is the only automated pass described between the generator and the archive you upload. Alongside src/ and tests/, the root carries a separate tsconfig.json for the TypeScript build and an .eslintrc.js for linting, and config/, data/, docs/, examples/ and scripts/ each hold a stage of the pipeline. ## MIT in package.json, NOASSERTION on GitHub, and one file you cannot read from the tree Two sources disagree about licensing. package.json declares MIT and names haunchen as author. GitHub's license field for the repository reads NOASSERTION, which is the value shown when the licence cannot be classified from the repository. A LICENSE file does sit at the root, next to CHANGELOG.md, CONTRIBUTING.md, SECURITY.md and CODE_OF_CONDUCT.md, each with an .en.md mirror. Attribution matters more here than in an ordinary dependency, because the pack is built from other people's work. Documentation for 545 built-in nodes comes out of n8n packages, and community/ covers 30 or more third-party packages. ATTRIBUTIONS.md and ATTRIBUTIONS.en.md exist at the top level for exactly that purpose, but neither file's contents are visible from the repository listing, so who wrote what stays unverified from outside. One more thing to check before relying on the pack: whether the node data is current for the n8n version you run. It refreshes only when the update scripts are run, the newest release tag is v2.22.0 from 30 August 2026, and the README stops mid-sentence in its before-and-after comparison of workflow design, so the claimed benefit of asking instead of searching is asserted rather than shown. ## Conclusion Take this if you build n8n workflows with Claude in the loop and want node lookup without web searches. Leave it if you want a maintained catalogue you can pin to a release, because the newest tag is older than package.json, the licence is stated in one place and not another, and the node data only refreshes when you run the update scripts yourself. Before installing, confirm the version in the zip matches the n8n version you actually run. ## FAQ ### What does haunchen/n8n-skills give Claude? A generated pack made of one SKILL.md file and a resources/ directory holding documentation for 545 n8n nodes and 20 curated workflow templates. It is built on the n8n-mcp architecture with priority ranking, node grouping and documentation integration added. ### How do I install haunchen/n8n-skills? Download n8n-skills-{version}.zip from the GitHub Releases page and extract it. For Claude Code, run mkdir -p .claude/skills/n8n-skills followed by cp -r n8n-skills/* .claude/skills/n8n-skills/. Claude.ai and Claude Desktop take the zip instead, through Settings, Capabilities and Upload skill. ### Which n8n version does haunchen/n8n-skills support? The README header states n8n v2.38.7, and package.json depends on n8n at ^2.38.7 along with n8n-core, n8n-nodes-base, n8n-workflow and @n8n/n8n-nodes-langchain. ### How do I check that an n8n-skills install worked? In Claude Code, ask it to list available n8n nodes. On Claude.ai and Claude Desktop, confirm that n8n-skills appears after the upload, enable it if it is not already, then ask n8n questions in the conversation window. ### What license is haunchen/n8n-skills under? package.json declares MIT. GitHub's license field for the repository reads NOASSERTION, and a LICENSE file sits in the repository root. Attribution for the bundled community packages is kept in ATTRIBUTIONS.md. ## Sources - [haunchen/n8n-skills on GitHub](https://github.com/haunchen/n8n-skills) - [Issues](https://github.com/haunchen/n8n-skills/issues) - [Project website](https://n8n-skills.frankchen.tw) - [README](https://github.com/haunchen/n8n-skills/blob/main/README.md) - [Releases](https://github.com/haunchen/n8n-skills/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haunchen-n8n-skills