# Markdown 代码检查该技能为使用“markdownlint-cli2”（可在任何项目中使用的行业标准 Markdown linter）进行 Markdown linting 提供了全面的指导。 ## 目录 * 概述 * 何时使用此技能 * 降价口味 * 首次使用：安装和设置 * 在您的存储库中设置 Markdown Linting * 快速启动 * 统一的工具架构 * 关键：配置策略 * 关键：没有自动化脚本 * 在本地运行 Linting * 智能修复处理 * VS Code 扩展设置（可选/高级） * GitHub Actions 集成（可选/高级） * 自定义规则（需要批准） * 故障排除 * 最佳实践 * 资源 * 评估场景 * 多型号测试笔记 * 版本历史 * 最后更新 ## 概述该工具可以通过自动 linting 执行严格的降价质量标准。可以使用“markdownlint-cli2”和统一的工具方法来验证 Markdown 文件，以确保跨 VS Code、CLI 和 CI/CD 环境的零配置漂移。 **核心理念：** *单一事实来源：`.markdownlint-cli2.jsonc`包含所有配置（规则、忽略、选项） * 统一工具：到处都有相同的“markdownlint-cli2”引擎（VS Code、CLI、CI/CD） * 严格执行：修复内容是为了遵守规则，而不是规则为了容纳内容 * 质量第一：Linting 规则是有意为之并加强文档质量 ## 何时使用此技能该技能应该在以下情况下使用： * 用户遇到 Markdown linting 错误（MD001、MD013、MD033 等） * 用户询问 Markdown 验证、格式或质量标准 * 用户需要配置`.markdownlint-cli2.jsonc`（规则、忽略或选项） * 用户询问配置文件设置或结构 * 用户想要设置 VS Code markdown linting 扩展 * 用户需要解决 Markdown linting 问题 * 用户询问如何在本地运行 Markdown linting * 用户想要了解 GitHub Actions markdown 验证 * 用户正在使用 Markdown 文件并需要质量指导 ## Markdown 口味 markdownlint-cli2 支持多种 Markdown 风格。默认情况下，它会验证 GitHub Flavored Markdown (GFM)，建议大多数项目使用该版本。 **支持的口味：** 风味 |默认 |最适合 ---|---|--- **GFM** | ✓ | GitHub 存储库，大多数 Web 项目 **CommonMark** | |最大便携性，严格合规 **快速指导：** * **对 GitHub 存储库、典型 Web 项目以及需要表/任务列表时使用 GFM（默认）** * **使用 CommonMark** 进行跨平台发布或严格的标准合规性 **有关详细的风味指南**，请参阅专用参考文件： * [风味概述]() \- 比较和选择指导 * [GFM 配置]() \- GitHub Flavored Markdown (默认) * [CommonMark 配置]() \- 严格的基本规范 **口味敏感规则：** 有些规则仅适用于特定口味。请参阅 [Markdownlint 规则参考]()，了解标记有其风味兼容性的规则。 ## 首次使用：安装和设置 **如果这是您第一次设置 Markdown linting**，请参阅综合安装指南： **[安装和设置指南]()** 本指南涵盖： * 先决条件（Node.js/npm） * 检测现有设置 * 两种方法：npx（零设置）与本地安装（完整功能） * 配置文件创建（`.markdownlint-cli2.jsonc`） * 在一个文件中配置规则、忽略和选项 * 验证步骤 * 解决设置问题 **快速检测检查：** # 检查您是否已经设置 ls .markdownlint-cli2.jsonc # 配置存在吗？ npm list markdownlint-cli2 # 软件包已安装？猫包.json | grep "lint:md" # 脚本配置了吗？如果缺少其中任何一个，请首先遵循[安装和设置指南]()。 ## 在您的存储库中设置 Markdown Linting 本节提供了在任何存储库中从头开始设置 Markdown linting 的完整指南。 ### 先决条件 **需要 Node.js 20+**。通过 [fnm]() 安装（推荐）： # Windows（PowerShell 作为管理员） winget安装Schniz.fnm #macOS/Linux 卷曲-fsSL https://fnm.vercel.app/install |巴什然后在 Git Bash 中，添加到 `~/.bashrc`： eval "$(fnm env --use-on-cd --shell bash)" 安装节点： fnm 安装 24 && fnm 默认 24 **为什么选择 fnm？** 与 nvm-windows 不同，fnm 在 Git Bash 中原生工作，没有[无提示输出错误]()。 ### 第 1 步：创建配置在您的存储库根目录中创建“.markdownlint-cli2.jsonc”： { “gitignore”：正确， “配置”：{ “默认”：真， “MD013”：假 } } 有关所有规则，请参阅 [Markdownlint 规则参考]()。 ### 步骤 2：添加到 package.json 如果您没有 `package.json`，请创建一个： { "name": "你的仓库名称", “私人”：真实， “脚本”：{ "lint:md": "markdownlint-cli2 \"**/*.md\"", "lint:md:fix": "markdownlint-cli2 \"**/*.md\" --fix" }, “开发依赖项”：{ "markdownlint-cli2": "^0.20.0" }, “引擎”：{ “节点”：“>=20.0.0” } } 然后安装： npm 安装 ### 步骤 3：添加到 .gitignore 确保“node_modules/”位于“.gitignore”中：节点模块/ ### 步骤 4：添加 CI 工作流程（可选）创建`.github/workflows/markdown-lint.yml`：名称：Markdown Lint 于：拉请求：路径：['**.md'] 推：分支：[主要] 路径：['**.md'] 职位：棉绒：运行：ubuntu-latest 步骤： - 使用：actions/checkout@v5 - 使用：DavidAnson/markdownlint-cli2-action@v22 与：全局：'**/*.md' ### 步骤 5：运行 Linting npm run lint:md # 检查 npm run lint:md:fix # 自动修复 ### 验证清单 * `.markdownlint-cli2.jsonc` 存在于您的规则中 * `package.json` 有 lint:md 脚本 * `node_modules/` 位于 `.gitignore` 中 * `npm run lint:md` 在本地工作 * CI 工作流程在 PR 上运行（如果添加） ## 快速入门 **选项 1：使用 npx（需要零设置）：** # 检查所有markdown文件 npx markdownlint-cli2“**/*.md” # 自动修复问题 npx markdownlint-cli2 "**/*.md" --fix **选项 2：使用 npm 脚本（如果已配置）：** # 检查所有 Markdown 文件是否存在 linting 错误 npm 运行 lint:md # 自动修复可修复的 linting 问题 npm 运行 lint:md:fix **选项 3：用于实时 linting 的 VS Code 扩展（可选/高级）：** 1. 从 VS Code 市场安装“davidanson.vscode-markdownlint” 2. 创建`.markdownlint-cli2.jsonc`配置（参见安装指南） 3. 在启用保存时自动修复的情况下键入时会发生 Linting（如果已配置） ## 统一工具架构配置后，“markdownlint-cli2”可以在任何地方使用，以确保零配置漂移： ### 工具组件 1. **CLI工具** (`markdownlint-cli2`) - **核心组件，先使用这个** * 可以通过 npx（零设置）或本地安装运行 * 用于本地验证和预提交检查 * 所有其他集成的基础 2. **VS Code 扩展** (`davidanson.vscode-markdownlint`) - **可选/高级** * 使用与 CLI 相同的 `markdownlint-cli2` 引擎 * 键入时实时检查 * 保存和粘贴时自动修复（可在 `.vscode/settings.json` 中配置） * 请参阅[VS Code 扩展设置]() 3. **GitHub 操作** (`markdownlint-cli2-action`) - **可选/高级** * 与 VS Code 和 CLI 相同的引擎 * 在修改 markdown 文件的 PR 上自动运行（配置后） * 与本地开发相同的规则（没有意外） * 请参阅 [GitHub Actions 配置]() ### 配置源所有工具都将项目根目录中的“.markdownlint-cli2.jsonc”读取为单一事实来源： { “gitignore”：正确， “忽略”：[“供应商/**/*.md”]， “配置”：{ “默认”：真， “MD013”：假 } } **这包含什么：** * `gitignore`: 自动从`.gitignore`中排除文件 * `ignores`：从 linting 中排除的附加 glob 模式 * `config`：Linting 规则（所有默认启用，长行禁用 MD013） **配置优先级**（按降序排列）： 1. `.markdownlint-cli2.{jsonc,yaml,cjs}` 文件 - **单一事实来源** 2. VS Code 用户/工作区设置（避免 - 不可移植） 3.默认配置 **注意：** 对 `.markdownlint-cli2.jsonc` 的更改会立即应用于所有工具（VS Code、CLI、GitHub Actions） ## 关键：配置策略 **重要 - 在修改任何配置之前请阅读此内容：** ### 严格政策——未经批准不得修改 * **未经明确批准，请勿修改`.markdownlint-cli2.jsonc`** * 严格的 linting 规则是有意为之并加强文档质量 * 如果发生 linting 错误，**修复内容以符合规则**，而不是规则本身 * 仅当存在**令人信服的架构原因**时才请求规则更改 * 如有疑问，**在放宽任何 linting 规则之前询问** ### 为什么存在这个政策 1. **质量执行**：检查规则保持文档的一致性和专业性 2. **最佳实践**：规则编码多年来积累的 Markdown 最佳实践 3. **辅助功能**：许多规则提高了屏幕阅读器和 Markdown 解析器的兼容性 4. **可维护性**：一致的格式使文档更易于维护 5. **协作**：共享标准减少代码审查中的摩擦 ### 对 Linting 错误的正确响应 **正确做法：** 错误：MD022/blanks-around-headings - 标题应由空行包围操作：在 markdown 文件中的标题前后添加空行 **错误的做法：** 错误：MD022/blanks-around-headings - 标题应由空行包围操作：禁用 .markdownlint-cli2.jsonc 中的 MD022 规则 **例外：** 如果您确实认为应该修改规则，请向用户展示您的案例： * 具体规则以及为什么会出现问题 * 导致问题的示例 * 架构或可用性原理 * 建议的配置更改用户将最终决定是否修改配置。 ## 关键：没有自动化脚本 > **⚠️ 严格禁止使用脚本进行 Markdown linting 修复 ⚠️** **切勿使用自动化脚本来修复 Markdown 文件。** 这包括： * 一次修改多个文件的 Python/Bash 脚本 * 基于正则表达式的跨文件查找和替换操作 * 任何无需人工审核每次更改即可进行批量更改的自动化工具 *“智能”修复程序，可检测语言说明符并将其添加到代码块中 ### 为什么存在这个政策 **A) 脚本很危险 - 我们已经看到了真正的问题：** 1. **上下文盲目性**：脚本无法理解语义上下文（例如，显示工具输出的代码块与需要语法突出显示的实际代码） 2. **过度应用**：脚本统一应用修复，即使在不适当的地方 3. **级联损坏**：一个错误的假设会影响数百个文件，需要痛苦的手动清理 4. **错误语言检测**：将 `text` 或其他语言说明符添加到故意没有的块中 **B) 手动修复速度较慢，但更准确、更安全：** 虽然手动逐一修复 linting 错误需要更长的时间，但它可以确保： * 每项变更在申请前都会根据上下文进行审查 * 保留语义意义（不仅仅是语法正确性） * 适当处理边缘情况 * 不会对不相关内容造成附带损害 **速度/准确性的权衡是值得的。** “节省时间”但需要数小时清理的脚本是净损失。 ### 嵌套代码块：极其复杂文档通常包含 **markdown inside markdown** \- 展示如何编写 markdown 的示例、带有代码示例的技能文档、模板等。这会创建脚本无法正确处理的嵌套结构： **示例：展示如何编写代码块的技能：** 创建 Python 代码块的方法如下： ````降价 ````蟒蛇定义你好（）： print("你好，世界！") ```` ```` 在这个例子中： * 外栅栏使用4个反引号（``````markdown`） * 内栅栏使用 3 个反引号 (````python`) * 看到 ````` 的脚本可能会错误地添加语言说明符或破坏嵌套 **需要注意的常见嵌套模式：** * ````{language}` \- 带有语法高亮的常规代码块 * `````markdown` \- 显示 markdown 示例的包装器（使用 4 个以上反引号） * 代码块中的代码块（关于文档的文档） * 不应有语言说明符的示例输出 **脚本无法可靠地区分：** * 哪个反引号栅栏是“真正的”栅栏与示例 * 裸露的````是有意的（原始输出）还是需要一种语言 * 每个代码块的语义目的 ### 现实世界的失败示例脚本将“文本”语言说明符添加到显示 MCP 工具输出、概念搜索和其他非代码示例的代码块中。这些块故意是裸露的（没有语言说明符），以显示原始输出而无需语法突出显示。该脚本的“修复”需要数百次手动编辑才能撤消。 ### 唯一可接受的方法 1. 运行 `markdownlint-cli2 --fix` 进行安全的内置自动修复（尾随空格、空行等） 2. 对于“无法修复”的错误（MD040、MD024 等），请使用 **编辑工具** 进行有针对性的上下文修复，一次修复一个 3. **应用前检查每个更改** \- 了解错误存在的原因以及修复在语义上是否正确 4. **查看周围的上下文** \- 这是一个嵌套的代码块吗？举个例子？原始输出？ 5. 如果修复看起来机械/重复，**停止并询问用户**，然后再继续 ### 如果您考虑使用脚本 1. **立即停止** 2. **明确询问用户**：“我正在考虑使用脚本自动执行此操作。您确定吗？脚本在过去导致了痛苦的清理工作。” 3. **仅在用户明确确认时才继续**并且您已经对脚本逻辑进行了三次检查 4. **首先测试一个文件**并在批量应用之前向用户显示差异 ### MD040（防护代码语言）特别指南 MD040 规则要求代码块具有语言说明符。然而： * **不要** 盲目地将“文本”添加到没有语言说明符的所有块中 * 有些块故意没有语言（显示原始输出、示例、模板） * 问问自己：“这显示的是需要语法突出显示的代码，还是原始输出？” * 如有疑问，**询问用户**而不是猜测 **添加语言说明符之前要问的问题：** 1. 这是实际代码，还是示例输出/结果？ 2. 这是一个更大的 Markdown 示例（嵌套）吗？ 3. 语法高亮会有助于还是会损害可读性？ 4、作者是故意裸露的吗？ ## 在本地运行 Linting ### 关键：自动修复工作流程 **运行 linting 验证时，始终自动修复所有错误（可修复和“不可修复”），而不要求用户确认。** **工作流程：** 1. 运行 linting 验证命令（npx 或 npm 脚本） 2. 如果发现错误： * **立即运行自动修复命令**（`--fix` 标志）而不提示 * 报告自动修复的内容 * **对于任何剩余的“无法修复”错误：** * 阅读受影响的文件以了解上下文 * 分析错误及周边内容 * 根据上下文应用智能修复（请参阅下面的“智能修复处理”） * 重新运行 linting 以验证修复 3.如果没有发现错误，则报告成功 **不要问“你想让我自动修复吗？”或“你想让我调查一下吗？” - 自动修复所有问题。** ### 先决条件 **对于 npx 方法（零设置）：** * 安装 Node.js 18+ 和 npm 8+ * 无需额外设置 **对于本地安装方法：** # 安装依赖项（仅限第一次） npm 安装如果您的项目没有安装“markdownlint-cli2”，请参阅[安装和设置指南]()。 ### 检查所有 Markdown 文件 **使用 npx：** npx markdownlint-cli2“**/*.md” **使用 npm 脚本（如果配置）：** npm 运行 lint:md **这有什么作用：** * 针对项目中的所有“.md”文件运行“markdownlint-cli2” * 自动排除 `node_modules` 目录 * 输出带有文件路径和行号的错误 * 如果没有错误则退出代码 0，如果发现错误则退出代码非零 **输出示例：** docs/setup-guide.md:45:1 MD022/blanks-around-headings 标题应由空行包围 README.md:12:81 MD009/no-trailing-spaces 尾随空格 ### 自动修复可修复的问题 **使用 npx：** npx markdownlint-cli2 "**/*.md" --fix **使用 npm 脚本（如果配置）：** npm 运行 lint:md:fix **这有什么作用：** * 自动修复可以安全纠正的问题 * 就地修改文件 * 报告剩余的无法修复的问题 **可修复的问题包括：** * 尾随空格 (MD009) * 缺少空行（MD012、MD022） * 列表标记一致性（MD004、MD007） * 代码围栏样式（MD048） **无法修复的问题需要智能分析和手动修复：** * 标题结构（MD001、MD025） * 重复标题 (MD024) * 线路长度（MD013，如果启用） * 链接参考（MD051、MD052） ### 智能修复处理 **当自动修复后仍然存在“无法修复”的错误时，自动分析并修复它们。** 有关处理每种错误类型的详细策略，请参阅专用指南： **[智能修复指南]()** 本指南涵盖： * MD024 - 重复标题（上下文感知重命名或删除） * MD001/MD025 - 标题结构（层次结构修复） * MD051/MD052 - 链接参考（锚点和参考链接更正） * MD013 - 线长（智能绕行） * 上下文感知分析的一般原则 * 验证和报告最佳实践 * 并行任务代理的性能优化 **快速总结：** 1. 首先运行自动修复：`npx markdownlint-cli2 "**/*.md" --fix` 2. 对于剩余的错误，请阅读受影响的文件以了解上下文 3. 根据错误模式应用智能修复（请参阅指南） 4. 始终重新运行 linting 以验证所有错误均已解决 5. 报告修复了什么以及如何修复 ## VS Code 扩展设置（可选/高级） **对于 VS Code 集成**，请参阅专用指南： **[VS Code 扩展设置指南]()** VS Code 扩展 (`davidanson.vscode-markdownlint`) 在编辑器中提供实时 linting。该指南涵盖： * 扩展安装和验证 * 自动修复配置（保存时格式化、粘贴时格式化） * 交互式 linting 功能（波浪下划线、快速修复） * 所有修复方法的键盘快捷键 * 配置优先级及故障排除 * 团队使用的最佳实践 **这是可选的，但强烈建议用于常规降价工作。** ## GitHub Actions 集成（可选/高级） **对于 CI/CD 集成**，请参阅专用指南： **[GitHub Actions 配置指南]()** GitHub Actions 可以自动验证 PR 和推送中的 Markdown 文件。该指南涵盖： * 完整的工作流程文件配置 * 触发设置（带有路径过滤的PR和推送事件） * 操作版本（checkout@v5、markdownlint-cli2-action@v22） * Workflow执行流程及结果解读 * 查看并修复 CI 故障 * 高级配置（自定义 glob、自动修复、分支保护） * 解决常见问题 **这是可选的，但强烈建议团队项目使用。** ## 自定义规则（需要批准） **警告：只有在上述政策明确批准的情况下才能进行修改。** **详细规则信息**，请参阅综合指南： **[Markdownlint 规则参考]()** 规则参考涵盖： * 所有 60 多个 MD 规则均附有说明和示例 * 规则类别（自动修复与需要手动修复） * 自定义规则的配置语法 * 常用规则修改（禁用、配置参数） * 每个文件覆盖的内联注释语法 * 每条规则的官方文档链接 **快速语法提醒：** { "default": true, // 启用所有默认值 "MD013": false, // 禁用特定规则 "MD033": { // 配置选项 “允许的元素”：[“br”] } } ## 故障排除 **常见问题及解决方案：** ### 问题：“未找到命令：markdownlint-cli2” **解决方案：** 运行 `npm install` 或使用 npx: `npx markdownlint-cli2 "**/*.md"` ### 问题：太多的 linting 错误无法手动修复 **解决方案：** 1. 运行自动修复：`npx markdownlint-cli2 "**/*.md" --fix` 2.批量修复剩余错误 3.详细故障排除请参见【安装指南】() ### 问题：VS Code 或 GitHub Actions 问题 **有关详细的故障排除**，请参阅专用指南： * **VS Code 问题**：[VS Code 扩展设置]() * **GitHub Actions 问题**：[GitHub Actions 配置]() ### 问题：不清楚的违规行为 **解决方案：** 检查 [Markdownlint 规则参考]() 以获取规则说明、示例和官方文档链接。 ## 最佳实践有关 Markdown linting、配置管理、协作和技能自动化的全面最佳实践： **[最佳实践指南]()** 该指南涵盖： * 有效地编写 Markdown 并考虑到 linting * 配置管理和规则定制 * 协作模式和团队工作流程 * Claude Code 使用的技能自动化 * 何时以及如何使用并行任务代理来提高效率 ## 资源 ### 官方文档 * **markdownlint-cli2 自述文件：** [github.com/DavidAnson/markdownlint-cli2]() * **markdownlint 规则：** [github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md]() * **VS 代码扩展：** [marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint]() * **GitHub 操作：** [github.com/DavidAnson/markdownlint-cli2-action]() ### 项目配置文件这些文件应该在您的项目根目录中创建（请参阅安装指南进行设置）： * **配置：** `.markdownlint-cli2.jsonc` （自定义规则所需） * **NPM 脚本：** `package.json` （可选，用于 npm run 命令） * **VS Code 设置：** `.vscode/settings.json` （可选，用于保存时自动修复） * **GitHub 工作流程：** `.github/workflows/markdown-lint.yml` （可选，适用于 CI/CD） ### 支持文档该技能包括“references/”目录中的参考文档： * [references/installation-setup.md]() \- **从这里开始：** 安装和首次设置 * [references/intelligent-fixing-guide.md]() \- 修复“不可修复”错误的策略 * [references/markdownlint-rules.md]() \- 详细的规则解释和定制 * [references/best-practices.md]() \- 编写、配置、协作和自动化的最佳实践 * [references/vscode-extension-setup.md]() \- VS Code 集成指南 (可选/高级) * [references/github-actions-config.md]() \- CI/CD 工作流程设置（可选/高级） ## 评估场景这些场景用于评估技能激活、引导质量和多模型兼容性。 ### 场景 1：首次设置 { "name": "首次设置", "query": "我需要在我的项目中设置 markdown linting", "context": "用户没有现有的 Markdown linting 配置", “文件”：[]， “预期行为”：[ “技能激活成功”, “加载references/installation-setup.md以获取全面指导”， “提供分步安装说明”， “区分 npx（零安装）和本地安装方法”， “通过 .markdownlint-cli2.jsonc 配置指南”， “包括验证步骤” ], “test_models”：[“十四行诗”，“俳句”，“作品”] } ### 场景 2：修复 linting 错误 { "name": "修复 linting 错误", "query": "我收到 MD022 错误，如何修复它们？", "context": "用户有 linting 错误，需要修复指导", "文件": ["样本文件.md"], “预期行为”：[ "错误类型和规则解释的技能激活", “解释 MD022 规则（标题周围的空白）”， “提供自动修复命令（npx markdownlint-cli2 --fix）”， “解释自动和智能修复方法”， “如果需要，请参考 smart-fixing-guide.md”， “提供验证步骤” ], “test_models”：[“十四行诗”，“俳句”，“作品”] } ### 场景 3：VS Code 集成 { "name": "VS Code 集成", "query": "如何在 VS Code 中启用保存时自动修复？", "context": "用户希望将 Markdown linting 集成到他们的编辑器工作流程中", “文件”：[]， “预期行为”：[ “激活 VS Code 集成技能”， “加载引用/vscode-extension-setup.md”， “提供扩展安装说明”， “解释 .vscode/settings.json 中的自动修复配置”， “记录键盘快捷键和交互功能”， “包括常见 VS Code 问题的故障排除” ], “test_models”：[“十四行诗”，“俳句”，“作品”] } ### 场景 4：GitHub Actions CI 设置 { "name": "GitHub Actions CI 设置", "query": "将 markdown linting 添加到 GitHub Actions", "context": "用户希望在 CI/CD 管道中自动进行 Markdown 验证", “文件”：[“.github/workflows/”]， “预期行为”：[ “激活 GitHub Actions 集成的技能”， “加载引用/github-actions-config.md”， “提供完整的工作流程文件配置”， “解释触发器设置（PR 和推送事件）”， “记录工作流程执行和结果解释”， “包括自动修复和分支保护的配置” ], “test_models”：[“十四行诗”，“俳句”，“作品”] } ### 场景5：配置定制 { "name": "配置定制", "query": "如何禁用 MD013 行长度规则？", "context": "用户需要为其项目自定义 linting 规则", “文件”：[“.markdownlint-cli2.jsonc”]， “预期行为”：[ “技能激活用于规则定制”， “解释配置策略（修复内容，而不是规则）”， "提供.markdownlint-cli2.jsonc配置示例", “显示禁用/配置特定规则的语法”， “规则详细信息参考references/markdownlint-rules.md”， “强调验证所有工具的更改” ], “test_models”：[“十四行诗”，“俳句”，“作品”] } ## 多模型测试笔记 **测试使用**： * **Claude Sonnet** ：最佳性能，很好地遵循集线器架构 * **Claude Haiku** ：（待测试 - 在给出明确指示的情况下应该可以工作） * **Claude Opus** ：（待测试 - 可能过度分析，内容范围适当） **观察**：技能的明确命令示例和清晰的决策树应该适用于所有模型层。 ## 版本历史 * v2.0.0 (2025-11-30)：迁移到 claude-code-plugins 存储库中的代码质量插件 * v1.2.0 (2025-11-17)：提取智能修复指南 - 将详细的错误修复策略移至单独的参考文件，减小 SKILL.md 大小以获得更好的令牌效率 * v1.1.0 (2025-11-17)：删除重复内容 - 删除重复的参考资料，简化为中心架构 * v1.0.2 (2025-11-17)：版本更新 - 更新至 markdownlint-cli2 v0.19.0，Node 20+ 要求，操作 v21 * v1.0.1 (2025-01-09)：改进的可移植性 - 删除了存储库特定的语言，增强了首次使用指南 * v1.0.0 (2025-01-09): 初始版本 - 从 `.claude/memory/workflows.md` 迁移 ## 最后更新 **日期：** 2026-01-17 **型号：** claude-opus-4-5-20251101

语法检查 Markdown

包含技能