n8n:create-skill
- Repo stars 190,957
- Author updated Live
- Author repo n8n
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @n8n-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Shell exec
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: n8n:create-skill
description: >- Use when the user works with PDFs, forms, or document extraction. Skills are markdown (plus o…
category: other
runtime: no special runtime
---
# n8n:create-skill output preview
## PART A: Task fit
- Use case: >- Use when the user works with PDFs, forms, or document extraction. Skills are markdown (plus optional scripts) that teach the agent a focused workflow. Keep SKILL.md short—the context window is shared with chat, code, and other skills. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Where skills live / Before you write: gather requirements / File layout” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “>- Use when the user works with PDFs, forms, or document extraction. Skills are markdown (plus optional scripts) that teach the agent a focused workflow. Keep SKILL.md short—the context window is shared with chat, code, and other skills. runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Where skills live / Before you write: gather requirements / File layout” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. Choose the trigger
The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
Provide inputs and boundaries
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, run shell commands.
Validate with a small run
Start with a small task and check whether the result follows “Where skills live / Before you write: gather requirements / File layout”. Inspect diffs, logs, previews, or tests before expanding scope.
Review before delivery
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: n8n:create-skill
description: >- Use when the user works with PDFs, forms, or document extraction. Skills are markdown (plus o…
category: other
source: n8n-io/n8n
---
# n8n:create-skill
## When to use
- >- Use when the user works with PDFs, forms, or document extraction. Skills are markdown (plus optional scripts) that…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Where skills live / Before you write: gather requirements / File layout” and keep inference separate from source facts.
- read files, write/modify files, run shell commands; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. Evidence boundary and execution chain
The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "n8n:create-skill" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Where skills live / Before you write: gather requirements / File layout
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files, run shell commands | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Creating skills
Skills are markdown (plus optional scripts) that teach the agent a focused workflow. Keep SKILL.md short—the context window is shared with chat, code, and other skills.
Where skills live
| Location | When to use |
|---|---|
.claude/plugins/n8n/skills/<name>/ |
Default for n8n: team-shared, versioned, namespaced under n8n:. |
~/.claude/skills/<name>/ |
Personal skill for Claude Code across all projects. |
~/.cursor/skills/<name>/ |
Optional personal skill for Cursor only, global to your machine. |
Do not put custom skills in ~/.cursor/skills-cursor/—that is reserved for Cursor’s built-in skills.
Prefer plugin .claude/plugins/n8n/skills/ for anything that should match how the rest of the team works.
Before you write: gather requirements
Ask (or infer) briefly:
- Purpose — one concrete task or workflow.
- Triggers — when should the agent apply this skill?
- Gaps — what does the agent not already know (project rules, URLs, formats)?
- Outputs — templates, checklists, or strict formats?
- Examples — follow an existing skill in
.claude/plugins/n8n/skills/if one fits.
Ask the user in plain language when you need more detail.
File layout
skill-name/
├── SKILL.md # required
├── reference.md # optional — detail the agent reads only if needed
├── examples.md # optional
└── scripts/ # optionalFrontmatter (required)
---
name: skill-name # lowercase, hyphens, max 64 chars
description: >- # max 1024 chars, non-empty — see below
...
---Description (discovery is everything — third person, WHAT + WHEN, trigger words):
- Good:
Extracts tables from PDFs and fills forms. Use when the user works with PDFs, forms, or document extraction. - Bad:
Helps with documentsorI can help you with PDFs
Authoring rules
- Concise — assume the model is capable; only add non-obvious domain or project facts.
- Progressive disclosure — essentials in
SKILL.md; long reference inreference.md. Link one level deep fromSKILL.md. - Prefer one default — e.g. one library or one workflow; add an escape hatch only if needed.
- Stable wording — one term per concept; avoid dated “until month X” notes unless you tuck legacy bits behind a short “Deprecated” note.
- Paths — forward slashes only (
scripts/foo.py).
Rough size: aim for well under ~200 lines in SKILL.md; if it grows, split detail out.
Scope: one job per skill (and parent skills)
- Single responsibility — one primary workflow or decision tree per skill. If triggers and steps diverge a lot (e.g. “create issue” vs “create PR” vs “full ticket → PR flow”), split into smaller dedicated skills.
- Prefer small + compose — two or three focused skills keep irrelevant detail out of context until needed. A parent (orchestrator) skill can say when to follow each child workflow and link to their
SKILL.md; avoid pasting full child content into the parent. - When one large skill is OK — a single end-to-end flow that always runs together and shares one tight checklist;
MCPs, CLI tools, and other skills
- Prefer CLI and repo commands when they solve the same problem — agents handle them well and they usually add less scaffolding noise to context than MCP tool discovery and schemas. Examples:
ghfor PRs/issues,pnpmscripts fromAGENTS.md. - MCPs are optional per user — not everyone has the same servers enabled. If a skill requires a specific MCP to work as written, say so explicitly:
- Put a hint in the frontmatter description (e.g. “Requires Linear MCP for …”) so mismatches are obvious early.
- Add a short Prerequisites (or Requirements) block near the top: which integration, what it is used for, and a fallback (e.g. web UI,
gh, or “ask the user to paste …”) when it is missing.
- Referencing other skills — use the namespaced invocation name (e.g.
n8n:create-issue) so the agent resolves the plugin skill. For human-readable links, give the path from the repo root (e.g..claude/plugins/n8n/skills/create-issue/SKILL.md). From a sibling folder, a relative link works too:[create-issue](../create-issue/SKILL.md). Parent skills should delegate steps instead of duplicating long procedures.
Patterns (pick what fits)
- Template — give the exact output shape (markdown/code blocks).
- Checklist — numbered or
- [ ]steps for multi-step work. - Branching — “If A → …; if B → …” at the top of a workflow.
- Scripts — document run commands; say whether to execute or read the script.
Workflow: create → verify
- Name + description — hyphenated name; description with triggers.
- Outline — minimal sections; link optional files.
- Implement —
SKILL.mdfirst; addreference.md/scripts/only if they save tokens or reduce errors. - Check — third-person description; terminology consistent; no duplicate encyclopedic content the model already knows.
Anti-patterns
- Verbose tutorials (“what is a PDF”) inside the skill.
- Many equivalent options with no default.
- Vague names (
helper,utils). - Deep chains of linked files.
- Assuming an MCP or tool is present without stating it or offering a fallback.
- One oversized skill that mixes unrelated workflows instead of smaller skills + a thin parent.
Quick example stub
---
name: my-workflow
description: Does X using project convention Y. Use when the user asks for X or mentions Z.
---
# My workflow
1. …
2. …
## Output format
Use a fenced code block for the exact shape reviewers should see.
## More detail
See [reference.md](reference.md) if edge cases matter.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review