typescript-eslint 文档写作规范如何编写可验证、自包含、经得起审查的文档【免费下载链接】typescript-eslint:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript项目地址: https://gitcode.com/GitHub_Trending/ty/typescript-eslint本篇技术指南系统讲解 typescript-eslint 仓库一个以 ESLint 支持 TypeScript 为核心的多包 monorepo采用的文档写作规范。无论你是在为规则编写使用文档、完善 MDX 指南还是撰写技能文件与 JSDoc读完本文你都能掌握一套可落地的写作方法如何把论断写得客观可验证、如何让代码示例脱离上下文依然完整可运行、如何写出对辅助技术和搜索引擎友好的链接以及如何在提交前用仓库自带的校验命令兜底。一、核心原则删掉读者已经拥有的每一个词Cut every word the reader already has删掉每个读者已有的词是 typescript-eslint 文档评审中最常见的修改请求。它适用于规则文档、指南、JSDoc 以及技能文件中的一切散文。以下六条操作准则构成其全部内涵。1. 拆分长句一句话如果同时携带括号补充语和一个破折号从句那它其实是两句话。长句会让论断的因果结构变得模糊评审与维护时也难以定位问题。写作时应主动将这类句子拆成两个短句每句只承担一个论断。2. 删除上下文已经暗示的词如果文档开头已经用:::danger Deprecated警示框标注了废弃正文就不必再说 This rule has been deprecated because... 这类重复表达。例如原文 This rule has been deprecated because, as of ESLint v9.37.0, the base rule added native support… 中 deprecated 出现了两次应直接以 As of ESLint v9.37.0, the base rule supports… 开头。上下文已经承载的信息正文一律不重复。3. 不要在第二段重复第一段的观点如果两段都以 TypeScript assumes that… 开头那它们应该合并成一段。每个观点在文档中只陈述一次后续内容要么提供新的信息要么给出可运行代码而不是换个说法重述。4. 不要用 for example 重复主张该选项会递归检查每个数组元素。例如当数组元素具有不可接受的类型时会报告错误。——这样的 for example 只是把前面的论断换了个说法没有增加任何信息量。要么给出真实代码演示要么直接删掉这句。5. 警示框要短且放在正文之后:::note、:::danger等 admonition 在视觉上非常醒目如果内容很长就会喧宾夺主挤压它本应注解的正文字段。规范做法是将警示框裁剪到两三句以内并移动到相关段落和代码示例的下方而不是插在正文与示例之间。参见规则文档 no-unnecessary-condition.mdx 中allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing选项的废弃警示框写法——先用:::danger Deprecated声明废弃状态正文交代移除版本与替代方案。6. 不要解释文档为什么存在本章节将帮助你更好地理解……这类元评论对读者没有任何信息量。文档的读者要的是这个选项做什么、在什么条件下生效而不是你写作时的价值判断。关于文档本身价值的叙述一律删除。7. 不要对散文硬换行仓库根目录的 .prettierrc.json 配置了proseWrap: preserve仓库惯例是每个段落写成一行。若按列宽手动换行任何后续修改都会变成跨多行的 diff极大干扰评审。写作时保持每段一行让 Prettier 与版本控制按自然段落组织内容。二、让论断客观描述可观察的条件与结果文档的每个论断都应能落到规则 X 在配置 Y 下对表达式 Z 报告错误这种可验证的形态而不是对质量或意图的主观评判。点名规则、选项、配置、语法或版本说明在什么条件下发生什么。规则文档 no-unnecessary-condition.mdx 开篇即定义任何用作条件的表达式必须能够评估为真或假才被视为必要反之根据表达式的类型确定始终为真或始终为假的表达式被视为不必要并被该规则标记。区分仓库行为与对用户的建议仓库做了什么是行为事实你应该怎么做是建议两者要分开展述。例如废弃选项的文档既说明strictNullChecks关闭时规则行为未定义行为又建议开启strictNullChecks保证类型安全建议随后明确使用该选项时我们不接受 bug 报告。避免宣传措辞powerful、easy、best 这类词除非有可验证的比较定义否则不要使用。优先写 The rule reports this expression when typed linting determines its condition is always truthy而不是 The rule catches unnecessary conditions。缓和读者架构未必共享的后果不要断言如果你做 X就必然发生 Y因为读者可能做了 X 却没有 Y。Values returned from functions arelikelyignored 和 some projects are architected so that this is generally safe 传达了同样的指导却不会对读者的代码库作出虚假断言。规则文档中关于checkTypePredicates选项的表述即遵循此道Whether this option makes sense for your project may vary. Some projects may intentionally use type predicates to ensure that runtime values do indeed match the types according to TypeScript, especially in test code.三、写前验证每个行为论断都要有源头文档中的每个行为论断都必须能追溯到建立该行为的源头包括实现代码与测试规则实现位于 packages/eslint-plugin/src/rules对应测试位于 packages/eslint-plugin/tests/rules公共工具在 packages/eslint-plugin/src/util规则元数据与选项 schema选项的类型定义如boolean还是boolean | object来自规则 schema贡献者文档docs/contributing 目录下的本地开发、Pull Request、Issue 等流程文档所引用的 TypeScript 与 ESLint 官方文档。两条硬性约束不要从文件名、单个 issue 报告或单个测试 fixture 推断一般行为。规则的实际行为必须由实现与多组测试共同确立。保留限定词凡是版本相关、配置相关或类型相关行为必须保留相应的限定条件。如果现有资料无法确立某个论断就收窄表述或直接省略。例如规则文档 no-unnecessary-condition.mdx 的 Limitations 一节用三个具体代码场景分别说明possibly-undefined 索引访问、函数调用内被修改的值、对象类型下的误报并逐一给出应对方案noUncheckedIndexedAccess、array.at(0)、类型断言、disable 注释每一项行为都源于 TypeScript 类型系统的既定特性而非臆测。四、代码块必须自包含包含影响演示行为的一切声明、类型、选项与配置不要依赖另一个代码块中定义的标识符。读者可能只看到当前这一块。避免省略号或省略设置当被省略的代码可能改变结果时必须补全。使用有意义的标识符不要用foo、bar这类占位名用items、condition、isString这样能传达语义的名字。每块一个逻辑点一个代码块只演示一个行为不要混入多个无关知识点。即使代码块刻意展示违反规则的错误写法它也不能因为缺少无关的 import、声明或选项而失败——错误必须只来自它想演示的那一条规则。规则文档的 Incorrect 示例正是如此function headT(items: T[]) { if (items) { ... } }中items声明、泛型与返回值类型一应俱全唯一的问题就是items永不为空却做了空值判断。五、写出脱离上下文仍然成立的链接辅助技术如屏幕阅读器会把页面上的所有链接作为独立列表呈现因此链接文字必须能独自说明其目的地描述目的地不要写[here]、[the setting]而应写[read more about setting space size in Node.js]这样的完整描述。相同的链接文字在列表中无法区分所以每条都要具体例如[the source code for the recommended config]。不要用方向词below、above、right-hand side 描述的是并非每个读者都拥有的视觉布局。改用指向目标的名字例如[the defineConfig migration guide]。按所有者的大写习惯书写产品名ESLint、TypeScript、Node.js。六、注释只写为什么否则不写TODO 必须命名决策并链接对应 issue如// TODO(typescript-eslintv9)或附带 issue URL。对已决定事项写 TODO 毫无意义——要么当前 API 已可行应立即实现要么不可行应删除注释。尚未有决策的事项其 TODO 应删除直到存在值得记录的决策。绝不在注释中留下猜测。seems like a bug in the rule 无法验证。应先调查再链接证据例如// eslint-disable-next-line typescript-eslint/no-deprecated -- see #10215。不要在行内重述 issue 的历史一个链接就够了散文会随 issue 演进而过时。删除重述代码的注释这类注释属于代码清晰度问题参见仓库技能文件 .agents/skills/code-clarity/SKILL.md 的约定。七、为对比阅读而写规则文档规则文档是 typescript-eslint 文档体系中结构要求最严格的类型它要让读者在正确与错误示例的对比中快速理解规则意图。1. 以官方模板为起点规则文档应从 packages/eslint-plugin/docs/rules/TEMPLATE.md 开始填写。模板的骨架包括frontmatterdescription字段取自规则元数据 提示块声明该文件是源码而非主要文档位置正式站点在 typescript-eslint.ioExamples小节使用 Docusaurus 的Tabs与TabItem组织❌ Incorrect与✅ Correct两个标签页When Not To Use It小节文档整体应遵循单数##标题与平行句式。注意该模板文件本身头部有 This file is source code, not the primary documentation location!的醒目提示因为packages/eslint-plugin/docs/rules下的 MDX 会被工具生成到站点并参与快照测试。2. 保持 Incorrect/Correct 标签页对比同一行为两个标签页应围绕同一个行为展开只改变演示修复的部分。如果两页代码完全相同就合并为单个代码块——完全相同的标签页会被读者视为错误。3. 每个选项都要有配置语法与示例每个选项必须有独立小节包含配置语法以及无效或有效的代码示例仅靠散文无法传达选项的作用。当选项类型不止boolean如boolean | object时必须明确写出因为读者不会从类型块中推断。以下是从 no-unnecessary-condition.mdx 提炼的选项小节模板allowConstantLoopConditions类型为never | always | only-allowed-literals。每个取值单独成段并配option{ allowConstantLoopConditions: ... } showPlaygroundButton标注的代码块only-allowed-literals精确说明允许true、false、0、1直接字面量作为循环条件而类型为true的变量如declare const alwaysTrue: true仍会被报告。checkTypePredicates布尔选项开启后额外检查类型谓词与断言函数中的恒真恒假条件文档同时说明是否启用取决于项目并给出eslint-disable注释的使用建议。allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing布尔选项用:::danger Deprecated警示框标注将在下一主版本移除说明strictNullChecks关闭时规则essentially makes this rule useless且行为未定义、不接受 bug 报告。4. 链接驱动选项的 issue为选项链接催生它的 issue 或评论读者才能理解该选项为何存在。5. When Not To Use It 只写给真实场景不要套用共享模板文案loosely typed codebases 之类如果该规则确实没有合适的禁用场景就不写只有模板措辞确实描述该规则时才复用并改编。例如 no-unnecessary-condition 的该小节针对正在从 JavaScript 转换、控制流分析存在 trade-off 的代码区域并建议用局部 disable 注释替代整体禁用。6. 精确命名特性说清特性归属于谁例如 auto-accessor 属性是 JavaScript 特性不是 TypeScript 特性不能写成 TypeScript 的发明。7. 深度内容引导到博客如果某节内容膨胀成深入探讨不要无限扩展规则页面而是提议一篇博客文章并在文档中链接它。规则文档只保留让读者对比理解并立刻可用的内容。八、提交前的验证流程在提交文档前运行仓库的格式化、拼写与 Markdown 验证命令均可从根目录或对应包目录执行详见 docs/contributing/Local_Development.mdx检查项命令工具代码/文档格式化pnpm run formatPrettier遵循 .prettierrc.json含proseWrap: preserveESLintpnpm run lintESLint 本身拼写检查pnpm run check-spellingCSpellMarkdown 校验pnpm run lint-markdownMarkdownlint类型检查pnpm run typecheckTypeScript规则快照cd packages/eslint-plugin pnpm run test docs -u基于规则文档与选项重新生成快照若修改了规则还需从根目录运行pnpm run generate-configs重新生成共享配置见 packages/eslint-plugin 的测试约定。这些检查在 Pull Request 上会自动运行本地提前跑通能显著减少来回评审。九、与相邻技能的衔接typescript-eslint 的 Agent 技能体系将文档写作与相邻关注点分离注释重述代码的问题由 .agents/skills/code-clarity/SKILL.md 处理规则实现层面的约定见 .agents/skills/rule-conventions/SKILL.md 与 .agents/skills/rule-performance/SKILL.md测试编写见 .agents/skills/tests/SKILL.md类型相关约束见 .agents/skills/types-not-workarounds/SKILL.md。文档写作技能聚焦可验证的论断 自包含的示例其余环节交由对应技能协作完成。总结typescript-eslint 的文档写作规范可以浓缩为四句话删掉冗余每词必有信息量、论断可验证点名规则、选项与条件、示例自包含脱离上下文也能运行、链接有语义单独列出也能定位。将这套规范应用于规则文档时以 TEMPLATE.md 为骨架、以实际规则实现与测试为证据、以仓库校验命令为兜底就能写出既专业易读、又经得起评审与检索的文档。【免费下载链接】typescript-eslint:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript项目地址: https://gitcode.com/GitHub_Trending/ty/typescript-eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 typescript-eslint 文档写作规范：如何编写可验证、自包含、经得起审查的文档
typescript-eslint 文档写作规范如何编写可验证、自包含、经得起审查的文档【免费下载链接】typescript-eslint:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript项目地址: https://gitcode.com/GitHub_Trending/ty/typescript-eslint本篇技术指南系统讲解 typescript-eslint 仓库一个以 ESLint 支持 TypeScript 为核心的多包 monorepo采用的文档写作规范。无论你是在为规则编写使用文档、完善 MDX 指南还是撰写技能文件与 JSDoc读完本文你都能掌握一套可落地的写作方法如何把论断写得客观可验证、如何让代码示例脱离上下文依然完整可运行、如何写出对辅助技术和搜索引擎友好的链接以及如何在提交前用仓库自带的校验命令兜底。一、核心原则删掉读者已经拥有的每一个词Cut every word the reader already has删掉每个读者已有的词是 typescript-eslint 文档评审中最常见的修改请求。它适用于规则文档、指南、JSDoc 以及技能文件中的一切散文。以下六条操作准则构成其全部内涵。1. 拆分长句一句话如果同时携带括号补充语和一个破折号从句那它其实是两句话。长句会让论断的因果结构变得模糊评审与维护时也难以定位问题。写作时应主动将这类句子拆成两个短句每句只承担一个论断。2. 删除上下文已经暗示的词如果文档开头已经用:::danger Deprecated警示框标注了废弃正文就不必再说 This rule has been deprecated because... 这类重复表达。例如原文 This rule has been deprecated because, as of ESLint v9.37.0, the base rule added native support… 中 deprecated 出现了两次应直接以 As of ESLint v9.37.0, the base rule supports… 开头。上下文已经承载的信息正文一律不重复。3. 不要在第二段重复第一段的观点如果两段都以 TypeScript assumes that… 开头那它们应该合并成一段。每个观点在文档中只陈述一次后续内容要么提供新的信息要么给出可运行代码而不是换个说法重述。4. 不要用 for example 重复主张该选项会递归检查每个数组元素。例如当数组元素具有不可接受的类型时会报告错误。——这样的 for example 只是把前面的论断换了个说法没有增加任何信息量。要么给出真实代码演示要么直接删掉这句。5. 警示框要短且放在正文之后:::note、:::danger等 admonition 在视觉上非常醒目如果内容很长就会喧宾夺主挤压它本应注解的正文字段。规范做法是将警示框裁剪到两三句以内并移动到相关段落和代码示例的下方而不是插在正文与示例之间。参见规则文档 no-unnecessary-condition.mdx 中allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing选项的废弃警示框写法——先用:::danger Deprecated声明废弃状态正文交代移除版本与替代方案。6. 不要解释文档为什么存在本章节将帮助你更好地理解……这类元评论对读者没有任何信息量。文档的读者要的是这个选项做什么、在什么条件下生效而不是你写作时的价值判断。关于文档本身价值的叙述一律删除。7. 不要对散文硬换行仓库根目录的 .prettierrc.json 配置了proseWrap: preserve仓库惯例是每个段落写成一行。若按列宽手动换行任何后续修改都会变成跨多行的 diff极大干扰评审。写作时保持每段一行让 Prettier 与版本控制按自然段落组织内容。二、让论断客观描述可观察的条件与结果文档的每个论断都应能落到规则 X 在配置 Y 下对表达式 Z 报告错误这种可验证的形态而不是对质量或意图的主观评判。点名规则、选项、配置、语法或版本说明在什么条件下发生什么。规则文档 no-unnecessary-condition.mdx 开篇即定义任何用作条件的表达式必须能够评估为真或假才被视为必要反之根据表达式的类型确定始终为真或始终为假的表达式被视为不必要并被该规则标记。区分仓库行为与对用户的建议仓库做了什么是行为事实你应该怎么做是建议两者要分开展述。例如废弃选项的文档既说明strictNullChecks关闭时规则行为未定义行为又建议开启strictNullChecks保证类型安全建议随后明确使用该选项时我们不接受 bug 报告。避免宣传措辞powerful、easy、best 这类词除非有可验证的比较定义否则不要使用。优先写 The rule reports this expression when typed linting determines its condition is always truthy而不是 The rule catches unnecessary conditions。缓和读者架构未必共享的后果不要断言如果你做 X就必然发生 Y因为读者可能做了 X 却没有 Y。Values returned from functions arelikelyignored 和 some projects are architected so that this is generally safe 传达了同样的指导却不会对读者的代码库作出虚假断言。规则文档中关于checkTypePredicates选项的表述即遵循此道Whether this option makes sense for your project may vary. Some projects may intentionally use type predicates to ensure that runtime values do indeed match the types according to TypeScript, especially in test code.三、写前验证每个行为论断都要有源头文档中的每个行为论断都必须能追溯到建立该行为的源头包括实现代码与测试规则实现位于 packages/eslint-plugin/src/rules对应测试位于 packages/eslint-plugin/tests/rules公共工具在 packages/eslint-plugin/src/util规则元数据与选项 schema选项的类型定义如boolean还是boolean | object来自规则 schema贡献者文档docs/contributing 目录下的本地开发、Pull Request、Issue 等流程文档所引用的 TypeScript 与 ESLint 官方文档。两条硬性约束不要从文件名、单个 issue 报告或单个测试 fixture 推断一般行为。规则的实际行为必须由实现与多组测试共同确立。保留限定词凡是版本相关、配置相关或类型相关行为必须保留相应的限定条件。如果现有资料无法确立某个论断就收窄表述或直接省略。例如规则文档 no-unnecessary-condition.mdx 的 Limitations 一节用三个具体代码场景分别说明possibly-undefined 索引访问、函数调用内被修改的值、对象类型下的误报并逐一给出应对方案noUncheckedIndexedAccess、array.at(0)、类型断言、disable 注释每一项行为都源于 TypeScript 类型系统的既定特性而非臆测。四、代码块必须自包含包含影响演示行为的一切声明、类型、选项与配置不要依赖另一个代码块中定义的标识符。读者可能只看到当前这一块。避免省略号或省略设置当被省略的代码可能改变结果时必须补全。使用有意义的标识符不要用foo、bar这类占位名用items、condition、isString这样能传达语义的名字。每块一个逻辑点一个代码块只演示一个行为不要混入多个无关知识点。即使代码块刻意展示违反规则的错误写法它也不能因为缺少无关的 import、声明或选项而失败——错误必须只来自它想演示的那一条规则。规则文档的 Incorrect 示例正是如此function headT(items: T[]) { if (items) { ... } }中items声明、泛型与返回值类型一应俱全唯一的问题就是items永不为空却做了空值判断。五、写出脱离上下文仍然成立的链接辅助技术如屏幕阅读器会把页面上的所有链接作为独立列表呈现因此链接文字必须能独自说明其目的地描述目的地不要写[here]、[the setting]而应写[read more about setting space size in Node.js]这样的完整描述。相同的链接文字在列表中无法区分所以每条都要具体例如[the source code for the recommended config]。不要用方向词below、above、right-hand side 描述的是并非每个读者都拥有的视觉布局。改用指向目标的名字例如[the defineConfig migration guide]。按所有者的大写习惯书写产品名ESLint、TypeScript、Node.js。六、注释只写为什么否则不写TODO 必须命名决策并链接对应 issue如// TODO(typescript-eslintv9)或附带 issue URL。对已决定事项写 TODO 毫无意义——要么当前 API 已可行应立即实现要么不可行应删除注释。尚未有决策的事项其 TODO 应删除直到存在值得记录的决策。绝不在注释中留下猜测。seems like a bug in the rule 无法验证。应先调查再链接证据例如// eslint-disable-next-line typescript-eslint/no-deprecated -- see #10215。不要在行内重述 issue 的历史一个链接就够了散文会随 issue 演进而过时。删除重述代码的注释这类注释属于代码清晰度问题参见仓库技能文件 .agents/skills/code-clarity/SKILL.md 的约定。七、为对比阅读而写规则文档规则文档是 typescript-eslint 文档体系中结构要求最严格的类型它要让读者在正确与错误示例的对比中快速理解规则意图。1. 以官方模板为起点规则文档应从 packages/eslint-plugin/docs/rules/TEMPLATE.md 开始填写。模板的骨架包括frontmatterdescription字段取自规则元数据 提示块声明该文件是源码而非主要文档位置正式站点在 typescript-eslint.ioExamples小节使用 Docusaurus 的Tabs与TabItem组织❌ Incorrect与✅ Correct两个标签页When Not To Use It小节文档整体应遵循单数##标题与平行句式。注意该模板文件本身头部有 This file is source code, not the primary documentation location!的醒目提示因为packages/eslint-plugin/docs/rules下的 MDX 会被工具生成到站点并参与快照测试。2. 保持 Incorrect/Correct 标签页对比同一行为两个标签页应围绕同一个行为展开只改变演示修复的部分。如果两页代码完全相同就合并为单个代码块——完全相同的标签页会被读者视为错误。3. 每个选项都要有配置语法与示例每个选项必须有独立小节包含配置语法以及无效或有效的代码示例仅靠散文无法传达选项的作用。当选项类型不止boolean如boolean | object时必须明确写出因为读者不会从类型块中推断。以下是从 no-unnecessary-condition.mdx 提炼的选项小节模板allowConstantLoopConditions类型为never | always | only-allowed-literals。每个取值单独成段并配option{ allowConstantLoopConditions: ... } showPlaygroundButton标注的代码块only-allowed-literals精确说明允许true、false、0、1直接字面量作为循环条件而类型为true的变量如declare const alwaysTrue: true仍会被报告。checkTypePredicates布尔选项开启后额外检查类型谓词与断言函数中的恒真恒假条件文档同时说明是否启用取决于项目并给出eslint-disable注释的使用建议。allowRuleToRunWithoutStrictNullChecksIKnowWhatIAmDoing布尔选项用:::danger Deprecated警示框标注将在下一主版本移除说明strictNullChecks关闭时规则essentially makes this rule useless且行为未定义、不接受 bug 报告。4. 链接驱动选项的 issue为选项链接催生它的 issue 或评论读者才能理解该选项为何存在。5. When Not To Use It 只写给真实场景不要套用共享模板文案loosely typed codebases 之类如果该规则确实没有合适的禁用场景就不写只有模板措辞确实描述该规则时才复用并改编。例如 no-unnecessary-condition 的该小节针对正在从 JavaScript 转换、控制流分析存在 trade-off 的代码区域并建议用局部 disable 注释替代整体禁用。6. 精确命名特性说清特性归属于谁例如 auto-accessor 属性是 JavaScript 特性不是 TypeScript 特性不能写成 TypeScript 的发明。7. 深度内容引导到博客如果某节内容膨胀成深入探讨不要无限扩展规则页面而是提议一篇博客文章并在文档中链接它。规则文档只保留让读者对比理解并立刻可用的内容。八、提交前的验证流程在提交文档前运行仓库的格式化、拼写与 Markdown 验证命令均可从根目录或对应包目录执行详见 docs/contributing/Local_Development.mdx检查项命令工具代码/文档格式化pnpm run formatPrettier遵循 .prettierrc.json含proseWrap: preserveESLintpnpm run lintESLint 本身拼写检查pnpm run check-spellingCSpellMarkdown 校验pnpm run lint-markdownMarkdownlint类型检查pnpm run typecheckTypeScript规则快照cd packages/eslint-plugin pnpm run test docs -u基于规则文档与选项重新生成快照若修改了规则还需从根目录运行pnpm run generate-configs重新生成共享配置见 packages/eslint-plugin 的测试约定。这些检查在 Pull Request 上会自动运行本地提前跑通能显著减少来回评审。九、与相邻技能的衔接typescript-eslint 的 Agent 技能体系将文档写作与相邻关注点分离注释重述代码的问题由 .agents/skills/code-clarity/SKILL.md 处理规则实现层面的约定见 .agents/skills/rule-conventions/SKILL.md 与 .agents/skills/rule-performance/SKILL.md测试编写见 .agents/skills/tests/SKILL.md类型相关约束见 .agents/skills/types-not-workarounds/SKILL.md。文档写作技能聚焦可验证的论断 自包含的示例其余环节交由对应技能协作完成。总结typescript-eslint 的文档写作规范可以浓缩为四句话删掉冗余每词必有信息量、论断可验证点名规则、选项与条件、示例自包含脱离上下文也能运行、链接有语义单独列出也能定位。将这套规范应用于规则文档时以 TEMPLATE.md 为骨架、以实际规则实现与测试为证据、以仓库校验命令为兜底就能写出既专业易读、又经得起评审与检索的文档。【免费下载链接】typescript-eslint:sparkles: Monorepo for all the tooling which enables ESLint to support TypeScript项目地址: https://gitcode.com/GitHub_Trending/ty/typescript-eslint创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考