ESLint 自定义规则生成代理

它解决什么问题

团队里总有一些约定散落在 README 或 Code Review 评论里：导出的常量必须带后缀、某些 API 不允许在业务代码里出现、文件命名要统一。把这些约定落地成 ESLint 规则，通常意味着手写 AST 遍历、补 RuleTester 用例、再处理 TypeScript 的类型收窄，成本高到多数人直接放弃，让约定停留在口头。

这个技能做的是：把一句自然语言描述变成可用的 ESLint 规则。你描述希望拦截什么样的代码，它基于 RuleTester API 与 AST 选择器生成规则实现与校验用例，并接入 typescript-eslint 解析器，让规则在 TypeScript 代码里也能读到类型信息。

核心能力与工作流程

• 自然语言到规则：把「禁止在 import 中使用 require」这类描述，转成 RuleMetaData、create() 里的遍历逻辑与报错信息。
• AST 选择器定位目标：用选择器精确描述要匹配的语法节点，而不是靠猜一条遍历路径。
• RuleTester 校验：生成的规则自带最小测试用例，保证该报错的报错、该放过的放过。
• TypeScript 感知：借助 typescript-eslint parser 获取类型信息，覆盖重载、条件类型这类纯 JS 解析器看不清的场景。

大致流程：描述规则 → 解析出目标 AST 节点与触发条件 → 生成规则代码与 RuleTester 用例 → 本地跑一遍验证。

适用边界与注意点

• 生成结果仍是规则骨架：语义判断（例如「这个默认参数不安全」）需要你自己补逻辑，工具提供结构与测试脚手架。
• Node.js 版本要求较新：^20.19.0、^22.13.0 或 >=24，且构建时需要 SSL 支持。
• 若要使用 ESLint 的 TypeScript 类型定义，需要 TypeScript 5.3+。
• 上游文档摘自 ESLint 官方 README，规则 API 以实际安装的 ESLint 版本为准。