n8n:create-community-node-lint-rule
- 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
- Plug-and-play
- External API key
- Not required
- Operating systems
- macOS · Linux · Windows
- Runtime requirements
- Node.js
- Permissions
-
- Read-only
- Write / modify
- 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-community-node-lint-rule
description: >- Guide for adding new ESLint rules to packages/@n8n/eslint-plugin-community-nodes/. All paths…
category: other
runtime: Node.js
---
# n8n:create-community-node-lint-rule output preview
## PART A: Task fit
- Use case: >- Guide for adding new ESLint rules to packages/@n8n/eslint-plugin-community-nodes/. All paths below are relative to packages/@n8n/eslint-plugin-community-nodes/. Before writing code, clarify: runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Step 1: Understand the Rule / Step 2: Implement the Rule / Step 3: Write Tests” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “>- Guide for adding new ESLint rules to packages/@n8n/eslint-plugin-community-nodes/. All paths below are relative to packages/@n8n/eslint-plugin-community-nodes/. Before writing code, clarify: runs entirely locally; runs on Node.js. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Step 1: Understand the Rule / Step 2: Implement the Rule / Step 3: Write Tests” 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; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; 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. The source does not require a stable slash command. After installation, invoke the skill by name and describe the task.
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.
Start with a small task and check whether the result follows “Step 1: Understand the Rule / Step 2: Implement the Rule / Step 3: Write Tests”. Inspect diffs, logs, previews, or tests before expanding scope.
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-community-node-lint-rule
description: >- Guide for adding new ESLint rules to packages/@n8n/eslint-plugin-community-nodes/. All paths…
category: other
source: n8n-io/n8n
---
# n8n:create-community-node-lint-rule
## When to use
- >- Guide for adding new ESLint rules to packages/@n8n/eslint-plugin-community-nodes/. All paths below are relative to…
- 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 “Step 1: Understand the Rule / Step 2: Implement the Rule / Step 3: Write Tests” and keep inference separate from source facts.
- read files, write/modify files; 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. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "n8n:create-community-node-lint-rule" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Step 1: Understand the Rule / Step 2: Implement the Rule / Step 3: Write Tests
rules -> SKILL.md triggers / order / output contract
runtime -> Node.js | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Create Community Node Lint Rule
Guide for adding new ESLint rules to packages/@n8n/eslint-plugin-community-nodes/.
All paths below are relative to packages/@n8n/eslint-plugin-community-nodes/.
Step 1: Understand the Rule
Before writing code, clarify:
- What does the rule detect? (missing property, wrong pattern, bad value)
- Where does it apply? (
.node.tsfiles, credential classes, both) - Severity:
error(must fix) orwarn(should fix)? - Fixable? Can it be auto-fixed safely, or only suggest?
- Scope: Both
recommendedconfigs, or exclude fromrecommendedWithoutN8nCloudSupport?
Step 2: Implement the Rule
Create src/rules/<rule-name>.ts:
import { AST_NODE_TYPES } from '@typescript-eslint/utils';
import {
isNodeTypeClass, // or isCredentialTypeClass
findClassProperty,
findObjectProperty,
createRule,
} from '../utils/index.js';
export const YourRuleNameRule = createRule({
name: 'rule-name',
meta: {
type: 'problem', // or 'suggestion'
docs: {
description: 'One-line description of what the rule enforces',
},
messages: {
messageId: 'Human-readable message. Use {{placeholder}} for dynamic data.',
},
fixable: 'code', // omit if not auto-fixable
hasSuggestions: true, // omit if no suggestions
schema: [], // add options schema if configurable
},
defaultOptions: [],
create(context) {
return {
ClassDeclaration(node) {
if (!isNodeTypeClass(node)) return;
const descriptionProperty = findClassProperty(node, 'description');
if (!descriptionProperty) return;
const descriptionValue = descriptionProperty.value;
if (descriptionValue?.type !== AST_NODE_TYPES.ObjectExpression) return;
// Rule logic here — use findObjectProperty(), getLiteralValue(), etc.
context.report({
node: targetNode,
messageId: 'messageId',
data: { /* template vars */ },
fix(fixer) {
return fixer.replaceText(targetNode, 'replacement');
},
});
},
};
},
});
Naming: Export as PascalCaseRule (e.g. MissingPairedItemRule). The name field is kebab-case.
Available AST helpers — see reference.md for the full catalog of ast-utils and file-utils exports.
Step 3: Write Tests
Create src/rules/<rule-name>.test.ts:
import { RuleTester } from '@typescript-eslint/rule-tester';
import { YourRuleNameRule } from './rule-name.js';
const ruleTester = new RuleTester();
// Helper to generate test code — keeps test cases readable
function createNodeCode(/* parameterize the varying parts */): string {
return `
import type { INodeType, INodeTypeDescription } from 'n8n-workflow';
export class TestNode implements INodeType {
description: INodeTypeDescription = {
displayName: 'Test Node',
name: 'testNode',
group: ['input'],
version: 1,
description: 'A test node',
defaults: { name: 'Test Node' },
inputs: [],
outputs: [],
properties: [],
};
}`;
}
ruleTester.run('rule-name', YourRuleNameRule, {
valid: [
{ name: 'class that does not implement INodeType', code: '...' },
{ name: 'node with correct pattern', code: createNodeCode(/* correct */) },
],
invalid: [
{
name: 'descriptive case name',
code: createNodeCode(/* incorrect */),
errors: [{ messageId: 'messageId', data: { /* expected template vars */ } }],
output: createNodeCode(/* expected after fix */), // or `output: null` if no fix
},
],
});
Test guidelines:
- Always test that non-INodeType classes are skipped (valid case)
- Test both the error message and the fixed output for fixable rules
- For rules with options, test each option combination
- For rules using filesystem, mock with
vi.mock('../utils/file-utils.js') - For suggestion-only rules, use
errors: [{ messageId, suggestions: [...] }]
Step 4: Register the Rule
4a. Add to src/rules/index.ts
import { YourRuleNameRule } from './rule-name.js';
// Add to the rules object:
export const rules = {
// ... existing rules
'rule-name': YourRuleNameRule,
} satisfies Record<string, AnyRuleModule>;
4b. Add to src/plugin.ts configs
Add to both config objects (unless the rule depends on n8n cloud features):
'@n8n/community-nodes/rule-name': 'error', // or 'warn'
- Use
errorfor rules that catch bugs or required patterns - Use
warnfor style/convention rules (likeoptions-sorted-alphabetically) - If the rule uses
no-restricted-globalsorno-restricted-importspatterns, only add torecommended(notrecommendedWithoutN8nCloudSupport)
Step 5: Write Documentation
Create docs/rules/<rule-name>.md:
# Description of what the rule does (`@n8n/community-nodes/rule-name`)
<!-- end auto-generated rule header -->
## Rule Details
Explain why this rule exists and what problem it prevents.
## Examples
### Incorrect
\`\`\`typescript
// code that triggers the rule
\`\`\`
### Correct
\`\`\`typescript
// code that passes the rule
\`\`\`
The header above <!-- end auto-generated rule header --> will be regenerated by pnpm build:docs. Write a reasonable first version — it gets overwritten.
Step 6: Verify
Run from packages/@n8n/eslint-plugin-community-nodes/:
pushd packages/@n8n/eslint-plugin-community-nodes
pnpm test <rule-name>.test.ts # tests pass
pnpm typecheck # types are clean
pnpm build # compiles
pnpm build:docs # regenerates doc headers and README table
pnpm lint:docs # docs match schema
popd
Checklist
- Rule file:
src/rules/<rule-name>.ts - Test file:
src/rules/<rule-name>.test.ts - Registered in
src/rules/index.ts - Added to configs in
src/plugin.ts - Doc file:
docs/rules/<rule-name>.md - README table updated via
pnpm build:docs - All verification commands pass
Decide Fit First
Design Intent
How To Use It
Boundaries And Review