markdown-linting

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Markdown Linting

Markdown代码检查

This skill provides comprehensive guidance for markdown linting using

markdownlint-cli2

, the industry-standard markdown linter that can be used in any project.

本技能提供使用

markdownlint-cli2

进行Markdown代码检查的全面指导，这是一款可用于任何项目的行业标准Markdown代码检查工具。

Overview

概述

This tooling enables enforcement of strict markdown quality standards through automated linting. Markdown files can be validated using

markdownlint-cli2

with a unified tooling approach that ensures zero configuration drift across VS Code, CLI, and CI/CD environments.

Core Philosophy:

Single source of truth:
```
.markdownlint-cli2.jsonc
```
contains all configuration (rules, ignores, options)
Unified tooling: Same
```
markdownlint-cli2
```
engine everywhere (VS Code, CLI, CI/CD)
Strict enforcement: Fix content to comply with rules, not rules to accommodate content
Quality-first: Linting rules are intentional and enforce documentation quality

该工具通过自动化代码检查来强制执行严格的Markdown质量标准。可以使用

markdownlint-cli2

验证Markdown文件，采用统一工具方法确保VS Code、CLI和CI/CD环境之间的配置完全一致。

核心理念：

单一事实来源：
```
.markdownlint-cli2.jsonc
```
包含所有配置（规则、忽略项、选项）
统一工具：所有环境（VS Code、CLI、CI/CD）使用相同的
```
markdownlint-cli2
```
引擎
严格执行：修改内容以符合规则，而非修改规则来适配内容
质量优先：代码检查规则是经过精心设计的，用于保障文档质量

When to Use This Skill

何时使用本技能

This skill should be used when:

User encounters markdown linting errors (MD001, MD013, MD033, etc.)
User asks about markdown validation, formatting, or quality standards
User needs to configure
```
.markdownlint-cli2.jsonc
```
(rules, ignores, or options)
User asks about configuration file setup or structure
User wants to set up VS Code markdown linting extension
User needs to troubleshoot markdown linting issues
User asks how to run markdown linting locally
User wants to understand GitHub Actions markdown validation
User is working with markdown files and needs quality guidance

在以下场景中应使用本技能：

用户遇到Markdown代码检查错误（MD001、MD013、MD033等）
用户询问Markdown验证、格式化或质量标准相关问题
用户需要配置
```
.markdownlint-cli2.jsonc
```
文件（规则、忽略项或选项）
用户询问配置文件的设置或结构
用户想要设置VS Code的Markdown代码检查扩展
用户需要排查Markdown代码检查问题
用户询问如何在本地运行Markdown代码检查
用户想要了解GitHub Actions的Markdown验证
用户正在处理Markdown文件并需要质量指导

Markdown Flavors

Markdown格式支持

markdownlint-cli2 supports multiple markdown flavors. By default, it validates GitHub Flavored Markdown (GFM), which is recommended for most projects.

Supported Flavors:

Flavor	Default	Best For
GFM	✓	GitHub repos, most web projects
CommonMark		Maximum portability, strict compliance

Quick Guidance:

Use GFM (default) for GitHub repos, typical web projects, and when you need tables/task lists
Use CommonMark for cross-platform publishing or strict standards compliance

For detailed flavor guidance, see the dedicated reference files:

Flavors Overview - Comparison and selection guidance
GFM Configuration - GitHub Flavored Markdown (default)
CommonMark Configuration - Strict base specification

Flavor-Sensitive Rules:

Some rules only apply to specific flavors. See Markdownlint Rules Reference for rules tagged with their flavor compatibility.

markdownlint-cli2支持多种Markdown格式。默认情况下，它验证GitHub Flavored Markdown (GFM)，这是大多数项目的推荐格式。

支持的格式：

格式	默认启用	适用场景
GFM	✓	GitHub仓库、大多数Web项目
CommonMark		最大可移植性、严格标准合规

快速指导：

使用GFM（默认） 适用于GitHub仓库、典型Web项目，以及需要表格/任务列表的场景
使用CommonMark 适用于跨平台发布或严格标准合规的场景

如需详细的格式指导，请参阅专门的参考文件：

格式概述 - 对比与选择指南
GFM配置 - GitHub Flavored Markdown（默认）
CommonMark配置 - 严格基础规范

格式敏感规则：

部分规则仅适用于特定格式。有关标记了格式兼容性的规则，请参阅Markdownlint规则参考。

First Use: Installation and Setup

首次使用：安装与设置

If this is your first time setting up markdown linting, see the comprehensive installation guide:

Installation and Setup Guide

This guide covers:

Prerequisites (Node.js/npm)
Detection of existing setup
Two approaches: npx (zero setup) vs local install (full features)
Configuration file creation (
```
.markdownlint-cli2.jsonc
```
)
Configuring rules, ignores, and options in one file
Verification steps
Troubleshooting setup issues

Quick detection check:

bash

undefined

如果是首次配置Markdown代码检查，请参阅完整的安装指南：

安装与设置指南

本指南涵盖：

前置条件（Node.js/npm）
检测现有配置
两种方式：npx（零配置） vs 本地安装（全功能）
创建配置文件（
```
.markdownlint-cli2.jsonc
```
）
在单个文件中配置规则、忽略项和选项
验证步骤
排查设置问题

快速检测检查：

bash

undefined

Check if you're already set up

检查是否已配置

ls .markdownlint-cli2.jsonc # Configuration exists? npm list markdownlint-cli2 # Package installed? cat package.json | grep "lint:md" # Scripts configured?


If any of these are missing, follow the [Installation and Setup Guide](references/installation-setup.md) first.

ls .markdownlint-cli2.jsonc # 配置文件是否存在？ npm list markdownlint-cli2 # 包是否已安装？ cat package.json | grep "lint:md" # 是否配置了脚本？


如果以上任何一项缺失，请先遵循[安装与设置指南](references/installation-setup.md)。

Setting Up Markdown Linting in Your Repo

在代码仓库中配置Markdown代码检查

This section provides a complete guide for setting up markdown linting from scratch in any repository.

本节提供在任何代码仓库中从头开始配置Markdown代码检查的完整指南。

Prerequisites

前置条件

Node.js 20+ is required. Install via fnm (recommended):

bash

undefined

需要Node.js 20+。推荐通过fnm安装：

bash

undefined

Windows (PowerShell as Admin)

Windows（以管理员身份运行PowerShell）

winget install Schniz.fnm

macOS/Linux

curl -fsSL https://fnm.vercel.app/install | bash


Then in Git Bash, add to `~/.bashrc`:

```bash
eval "$(fnm env --use-on-cd --shell bash)"

Install Node:

bash

fnm install 24 && fnm default 24

Why fnm? Unlike nvm-windows, fnm works natively in Git Bash without silent output bugs.

curl -fsSL https://fnm.vercel.app/install | bash


然后在Git Bash中，将以下内容添加到`~/.bashrc`：

```bash
eval "$(fnm env --use-on-cd --shell bash)"

安装Node：

bash

fnm install 24 && fnm default 24

为什么选择fnm？ 与nvm-windows不同，fnm原生支持Git Bash，不会出现静默输出问题。

Step 1: Create Configuration

步骤1：创建配置

Create

.markdownlint-cli2.jsonc

in your repo root:

jsonc

{
  "gitignore": true,
  "config": {
    "default": true,
    "MD013": false
  }
}

See Markdownlint Rules Reference for all rules.

在仓库根目录创建

.markdownlint-cli2.jsonc

文件：

jsonc

{
  "gitignore": true,
  "config": {
    "default": true,
    "MD013": false
  }
}

有关所有规则，请参阅Markdownlint规则参考。

Step 2: Add to package.json

步骤2：添加到package.json

If you don't have a

package.json

, create one:

json

{
  "name": "your-repo-name",
  "private": true,
  "scripts": {
    "lint:md": "markdownlint-cli2 \"**/*.md\"",
    "lint:md:fix": "markdownlint-cli2 \"**/*.md\" --fix"
  },
  "devDependencies": {
    "markdownlint-cli2": "^0.20.0"
  },
  "engines": {
    "node": ">=20.0.0"
  }
}

Then install:

bash

npm install

如果没有

package.json

，请创建一个：

json

{
  "name": "your-repo-name",
  "private": true,
  "scripts": {
    "lint:md": "markdownlint-cli2 \"**/*.md\"",
    "lint:md:fix": "markdownlint-cli2 \"**/*.md\" --fix"
  },
  "devDependencies": {
    "markdownlint-cli2": "^0.20.0"
  },
  "engines": {
    "node": ">=20.0.0"
  }
}

然后安装依赖：

bash

npm install

Step 3: Add to .gitignore

步骤3：添加到.gitignore

Ensure

node_modules/

is in your

.gitignore

gitignore

node_modules/

确保

node_modules/

已添加到

.gitignore

：

gitignore

node_modules/

Step 4: Add CI Workflow (Optional)

步骤4：添加CI工作流（可选）

Create

.github/workflows/markdown-lint.yml

yaml

name: Markdown Lint

on:
  pull_request:
    paths: ['**.md']
  push:
    branches: [main]
    paths: ['**.md']

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: DavidAnson/markdownlint-cli2-action@v22
        with:
          globs: '**/*.md'

创建

.github/workflows/markdown-lint.yml

：

yaml

name: Markdown Lint

on:
  pull_request:
    paths: ['**.md']
  push:
    branches: [main]
    paths: ['**.md']

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5
      - uses: DavidAnson/markdownlint-cli2-action@v22
        with:
          globs: '**/*.md'

Step 5: Run Linting

步骤5：运行代码检查

bash

npm run lint:md        # Check
npm run lint:md:fix    # Auto-fix

bash

npm run lint:md        # 检查
npm run lint:md:fix    # 自动修复

Verification Checklist

验证清单

```
.markdownlint-cli2.jsonc
```
exists with your rules
```
package.json
```
has lint:md scripts
```
node_modules/
```
is in
```
.gitignore
```
```
npm run lint:md
```
works locally
CI workflow runs on PRs (if added)

```
.markdownlint-cli2.jsonc
```
已存在并包含你的规则
```
package.json
```
包含lint:md脚本
```
node_modules/
```
已添加到
```
.gitignore
```
```
npm run lint:md
```
在本地可正常运行
CI工作流在PR上运行（如果已添加）

Quick Start

快速开始

Option 1: Using npx (zero setup required):

bash

undefined

选项1：使用npx（无需配置）：

bash

undefined

Check all markdown files

检查所有Markdown文件

npx markdownlint-cli2 "**/*.md"

Auto-fix issues

自动修复问题

npx markdownlint-cli2 "**/*.md" --fix


**Option 2: Using npm scripts (if configured):**

```bash

npx markdownlint-cli2 "**/*.md" --fix


**选项2：使用npm脚本（如果已配置）：**

```bash

Check all markdown files for linting errors

检查所有Markdown文件的代码检查错误

npm run lint:md

Auto-fix fixable linting issues

自动修复可修复的代码检查问题

npm run lint:md:fix


**Option 3: VS Code extension for real-time linting (optional/advanced):**

1. Install `davidanson.vscode-markdownlint` from VS Code marketplace
2. Create `.markdownlint-cli2.jsonc` configuration (see installation guide)
3. Linting happens as you type with auto-fix on save enabled (if configured)

npm run lint:md:fix


**选项3：使用VS Code扩展进行实时代码检查（可选/进阶）：**

1. 从VS Code市场安装`davidanson.vscode-markdownlint`
2. 创建`.markdownlint-cli2.jsonc`配置文件（请参阅安装指南）
3. 在你输入时进行实时代码检查，并启用保存时自动修复（如果已配置）

Unified Tooling Architecture

统一工具架构

When configured,

markdownlint-cli2

can be used everywhere to ensure zero configuration drift:

配置完成后，

markdownlint-cli2

可在所有环境中使用，确保配置完全一致：

Tooling Components

工具组件

CLI Tool (
```
markdownlint-cli2
```
) - Core component, use this first
- Can be run via npx (zero setup) or local install
- Used for local validation and pre-commit checks
- Foundation for all other integrations
VS Code Extension (
```
davidanson.vscode-markdownlint
```
) - Optional/Advanced
- Uses same
```
markdownlint-cli2
```
  engine as CLI
- Real-time linting as you type
- Auto-fix on save and paste (configurable in
```
.vscode/settings.json
```
  )
- See VS Code Extension Setup
GitHub Actions (
```
markdownlint-cli2-action
```
) - Optional/Advanced
- Same engine as VS Code and CLI
- Runs automatically on PRs that modify markdown files (when configured)
- Same rules as local development (no surprises)
- See GitHub Actions Configuration

CLI工具 (
```
markdownlint-cli2
```
) - 核心组件，优先使用
- 可通过npx（零配置）或本地安装运行
- 用于本地验证和提交前检查
- 是所有其他集成的基础
VS Code扩展 (
```
davidanson.vscode-markdownlint
```
) - 可选/进阶
- 使用与CLI相同的
```
markdownlint-cli2
```
  引擎
- 在你输入时进行实时代码检查
- 支持保存和粘贴时自动修复（在
```
.vscode/settings.json
```
  中配置）
- 请参阅VS Code扩展设置
GitHub Actions (
```
markdownlint-cli2-action
```
) - 可选/进阶
- 使用与VS Code和CLI相同的引擎
- 当配置后，在修改Markdown文件的PR上自动运行
- 使用与本地开发相同的规则（无意外情况）
- 请参阅GitHub Actions配置

Configuration Source

配置来源

All tools read

.markdownlint-cli2.jsonc

in the project root as the single source of truth:

jsonc

{
  "gitignore": true,
  "ignores": ["vendor/**/*.md"],
  "config": {
    "default": true,
    "MD013": false
  }
}

What this contains:

```
gitignore
```
: Automatically excludes files from
```
.gitignore
```
```
ignores
```
: Additional glob patterns to exclude from linting
```
config
```
: Linting rules (all defaults enabled, MD013 disabled for long lines)

Configuration precedence (in decreasing order):

```
.markdownlint-cli2.{jsonc,yaml,cjs}
```
file - Single source of truth
VS Code user/workspace settings (avoid - not portable)
Default configuration

Note: Changes to

.markdownlint-cli2.jsonc

apply instantly to all tools (VS Code, CLI, GitHub Actions)

所有工具都会读取项目根目录下的

.markdownlint-cli2.jsonc

作为单一事实来源：

jsonc

{
  "gitignore": true,
  "ignores": ["vendor/**/*.md"],
  "config": {
    "default": true,
    "MD013": false
  }
}

配置内容说明：

```
gitignore
```
: 自动排除
```
.gitignore
```
中的文件
```
ignores
```
: 额外的要从代码检查中排除的glob模式
```
config
```
: 代码检查规则（启用所有默认规则，禁用MD013）

配置优先级（从高到低）：

```
.markdownlint-cli2.{jsonc,yaml,cjs}
```
文件 - 单一事实来源
VS Code用户/工作区设置（避免使用 - 不具备可移植性）
默认配置

注意： 对

.markdownlint-cli2.jsonc

的更改会立即应用于所有工具（VS Code、CLI、GitHub Actions）

CRITICAL: Configuration Policy

重要说明：配置策略

IMPORTANT - Read this before modifying any configuration:

重要 - 在修改任何配置前请阅读：

Strict Policy - Never Modify Without Approval

严格策略 - 未经批准请勿修改

DO NOT modify
.markdownlint-cli2.jsonc
without explicit approval
Strict linting rules are intentional and enforce documentation quality
If linting errors occur, fix the content to comply with the rules, NOT the rules themselves
Only request rule changes if there is a compelling architectural reason
When in doubt, ask before relaxing any linting rules

未经明确批准，请勿修改
.markdownlint-cli2.jsonc
严格的代码检查规则是经过精心设计的，用于保障文档质量
如果出现代码检查错误，修改内容以符合规则，而非修改规则本身
只有存在令人信服的架构原因时，才可以申请修改规则
如有疑问，在放宽任何代码检查规则前请先咨询

Why This Policy Exists

该策略存在的原因

Quality enforcement: Linting rules maintain documentation consistency and professionalism
Best practices: Rules encode markdown best practices accumulated over years
Accessibility: Many rules improve screen reader and markdown parser compatibility
Maintainability: Consistent formatting makes documentation easier to maintain
Collaboration: Shared standards reduce friction in code reviews

质量保障: 代码检查规则保持文档的一致性和专业性
最佳实践: 规则编码了多年积累的Markdown最佳实践
可访问性: 许多规则提高了屏幕阅读器和Markdown解析器的兼容性
可维护性: 一致的格式使文档更易于维护
协作: 共享标准减少了代码审查中的摩擦

Proper Response to Linting Errors

处理代码检查错误的正确方式

Correct approach:

markdown

Error: MD022/blanks-around-headings - Headings should be surrounded by blank lines

Action: Add blank lines before and after the heading in the markdown file

Incorrect approach:

markdown

Error: MD022/blanks-around-headings - Headings should be surrounded by blank lines

Action: Disable MD022 rule in .markdownlint-cli2.jsonc

Exception: If you genuinely believe a rule should be modified, present your case to the user with:

The specific rule and why it's problematic
Examples of where it causes issues
Architectural or usability rationale
Proposed configuration change

The user will make the final decision on whether to modify the configuration.

正确做法：

markdown

错误：MD022/blanks-around-headings - 标题前后应添加空行

操作：在Markdown文件中的标题前后添加空行

错误做法：

markdown

错误：MD022/blanks-around-headings - 标题前后应添加空行

操作：在.markdownlint-cli2.jsonc中禁用MD022规则

例外情况： 如果你确实认为某个规则应该修改，请向用户说明以下内容：

具体规则及其问题所在
导致问题的示例
架构或可用性理由
建议的配置更改

用户将最终决定是否修改配置。

CRITICAL: NO AUTOMATED SCRIPTS

重要说明：禁止使用自动化脚本

⚠️ SCRIPTS ARE STRICTLY PROHIBITED FOR MARKDOWN LINTING FIXES ⚠️

NEVER use automated scripts to fix markdown files. This includes:

Python/Bash scripts that modify multiple files at once
Regex-based find-and-replace operations across files
Any automated tool that makes bulk changes without human review per-change
"Smart" fixers that detect and add language specifiers to code blocks

⚠️ 严格禁止使用自动化脚本修复Markdown文件 ⚠️

切勿使用自动化脚本修改Markdown文件，包括：

同时修改多个文件的Python/Bash脚本
跨文件的基于正则表达式的查找替换操作
任何无需人工逐次审查就进行批量更改的自动化工具
检测并为代码块添加语言指定符的“智能”修复工具

Why This Policy Exists

该策略存在的原因

A) Scripts are dangerous - we have seen real issues:

Context blindness: Scripts cannot understand semantic context (e.g., a code block showing tool output vs actual code that needs syntax highlighting)
Over-application: Scripts apply fixes uniformly, even where inappropriate
Cascading damage: One wrong assumption affects hundreds of files, requiring painful manual cleanup
False language detection: Adding
```
text
```
or other language specifiers to blocks that intentionally have none

B) Manual fixes are slower but more accurate and safer:

While manually fixing linting errors one-by-one takes longer, it ensures:

Each change is reviewed in context before application
Semantic meaning is preserved (not just syntactic correctness)
Edge cases are handled appropriately
No collateral damage to unrelated content

The speed/accuracy trade-off is worth it. A script that "saves time" but requires hours of cleanup is a net loss.

A) 脚本很危险 - 我们已经遇到过实际问题：

上下文盲视: 脚本无法理解语义上下文（例如，显示工具输出的代码块与需要语法高亮的实际代码）
过度应用: 脚本统一应用修复，即使在不合适的场景
级联损坏: 一个错误的假设会影响数百个文件，需要耗时费力的手动清理
错误的语言检测: 为有意不指定语言的块添加
```
text
```
或其他语言指定符

B) 手动修复速度较慢但更准确、更安全：

虽然逐个手动修复代码检查错误需要更长时间，但可以确保：

每次更改都在上下文中经过审查后再应用
语义含义得以保留（不仅仅是语法正确）
边缘情况得到适当处理
不会对无关内容造成附带损害

速度/准确性的权衡是值得的。一个“节省时间”但需要数小时清理的脚本最终是得不偿失的。

Nested Code Blocks: A Critical Complexity

嵌套代码块：关键复杂性

Documentation often contains markdown within markdown - examples showing how to write markdown, skill documentation with code samples, templates, etc. This creates nested structures that scripts cannot handle correctly:

Example: A skill showing how to write a code block:

markdown

Here's how to create a Python code block:

````markdown
```python
def hello():
    print("Hello, world!")
```
````

In this example:

The outer fence uses 4 backticks (`````markdown`)
The inner fence uses 3 backticks (
```
```python
```
)
A script seeing
```
```
```
might incorrectly add language specifiers or break the nesting

Common nested patterns to watch for:

```
```{language}
```
- Regular code block with syntax highlighting
```
````markdown
```
- Wrapper showing markdown examples (uses 4+ backticks)
Code blocks inside code blocks (documentation about documentation)
Example output that should NOT have language specifiers

Scripts cannot reliably distinguish:

Which backtick fence is the "real" one vs an example
Whether a bare
```
```
```
is intentional (raw output) or needs a language
The semantic purpose of each code block

文档中经常包含Markdown嵌套Markdown - 展示如何编写Markdown的示例、包含代码示例的技能文档、模板等。这会创建脚本无法正确处理的嵌套结构：

示例：展示如何创建代码块的技能文档：

markdown

以下是创建Python代码块的方法：

````markdown
```python
def hello():
    print("Hello, world!")
```
````

在这个示例中：

外层围栏使用4个反引号（`````markdown`）
内层围栏使用3个反引号（
```
```python
```
）
看到
```
```
```
的脚本可能会错误地添加语言指定符或破坏嵌套结构

需要注意的常见嵌套模式：

```
```{language}
```
- 带语法高亮的常规代码块
```
````markdown
```
- 展示Markdown示例的包装器（使用4个以上反引号）
代码块内的代码块（关于文档的文档）
不应有语言指定符的示例输出

脚本无法可靠区分：

哪个反引号围栏是“真实的”还是示例
裸
```
```
```
是有意为之（原始输出）还是需要指定语言
每个代码块的语义用途

Real-World Failure Example

实际失败示例

A script added

text

language specifiers to code blocks showing MCP tool output, Notion searches, and other non-code examples. These blocks were intentionally bare (no language specifier) to show raw output without syntax highlighting. The script's "fix" required hundreds of manual edits to undo.

某个脚本为显示MCP工具输出、Notion搜索结果和其他非代码示例的代码块添加了

text

语言指定符。这些块有意不指定语言，以显示原始输出而不进行语法高亮。脚本的“修复”需要数百次手动编辑来撤销。

The ONLY Acceptable Approach

唯一可接受的方法

Run
```
markdownlint-cli2 --fix
```
for safe, built-in auto-fixes (trailing spaces, blank lines, etc.)
For "unfixable" errors (MD040, MD024, etc.), use the Edit tool to make targeted, contextual fixes one at a time
Review each change before applying - understand WHY the error exists and whether the fix is semantically correct
Look at surrounding context - is this a nested code block? An example? Raw output?
If a fix seems mechanical/repetitive, STOP and ask the user before proceeding

运行
```
markdownlint-cli2 --fix
```
进行安全的内置自动修复（尾随空格、空行等）
对于“无法自动修复”的错误（MD040、MD024等），使用编辑工具逐个进行有针对性的上下文修复
在应用前审查每个更改 - 理解错误存在的原因以及修复是否在语义上正确
查看周围上下文 - 这是嵌套代码块吗？是示例吗？是原始输出吗？
如果修复看起来机械/重复，停止并咨询用户后再继续

If You Even Consider Using a Script

MD040（fenced-code-language）特殊指导

STOP immediately
Ask the user explicitly: "I'm considering automating this with a script. Are you sure? Scripts have caused painful cleanup in the past."
Only proceed if user explicitly confirms AND you've triple-checked the script logic
Test on ONE file first and show the user the diff before bulk application

MD040规则要求代码块有语言指定符。然而：

请勿盲目地为所有没有语言指定符的块添加
```
text
```
有些块有意不指定语言（显示原始输出、示例、模板）
问问自己：“这是需要语法高亮的代码，还是原始输出？”
如有疑问，咨询用户而非猜测

添加语言指定符前应问的问题：

这是实际代码，还是示例输出/结果？
它是否在更大的Markdown示例中（嵌套）？
语法高亮对可读性有帮助还是有损害？
作者是否有意不指定语言？

MD040 (fenced-code-language) Special Guidance

在本地运行代码检查

—

重要：自动修复工作流

The MD040 rule requires code blocks to have language specifiers. However:

DO NOT blindly add
```
text
```
to all blocks without language specifiers
Some blocks intentionally have no language (showing raw output, examples, templates)
Ask yourself: "Is this showing code that needs syntax highlighting, or raw output?"
When in doubt, ask the user rather than guessing

Questions to ask before adding a language specifier:

Is this actual code, or example output/results?
Is this inside a larger markdown example (nested)?
Would syntax highlighting help or hurt readability here?
Did the author intentionally leave it bare?

运行代码检查验证时，请自动修复所有错误（包括可自动修复和“无法自动修复”的错误），无需征求用户确认。

工作流：

运行代码检查验证命令（npx或npm脚本）
如果发现错误：
- 立即运行自动修复命令（
```
--fix
```
  标志），无需提示
- 报告已自动修复的内容
- 对于任何剩余的“无法自动修复”的错误：
  - 读取受影响的文件以理解上下文
  - 分析错误和周围内容
  - 根据上下文应用智能修复（请参阅下文“智能修复处理”）
  - 重新运行代码检查以验证修复
如果未发现错误，报告成功

请勿询问“是否需要我自动修复？”或“是否需要我调查？” - 直接自动修复所有问题。

Running Linting Locally

前置条件

CRITICAL: Auto-Fix Workflow

—

When running linting validation, ALWAYS automatically fix ALL errors (both fixable and "unfixable") without asking for user confirmation.

Workflow:

Run linting validation command (npx or npm scripts)
If errors are found:
- IMMEDIATELY run the auto-fix command (
```
--fix
```
  flag) without prompting
- Report what was auto-fixed
- For any remaining "unfixable" errors:
  - Read the affected files to understand context
  - Analyze the error and surrounding content
  - Apply intelligent fixes based on context (see "Intelligent Fix Handling" below)
  - Re-run linting to verify fixes
If no errors are found, report success

DO NOT ask "Would you like me to auto-fix?" or "Would you like me to investigate?" - just fix everything automatically.

对于npx方式（零配置）：

已安装Node.js 18+和npm 8+
无需额外设置

对于本地安装方式：

bash

undefined

Prerequisites

安装依赖（仅首次需要）

For npx approach (zero setup):

Node.js 18+ and npm 8+ installed
No additional setup required

For local install approach:

bash

undefined

npm install


如果你的项目未安装`markdownlint-cli2`，请参阅[安装与设置指南](references/installation-setup.md)。

Install dependencies (first time only)

检查所有Markdown文件

npm install


If your project doesn't have `markdownlint-cli2` installed, see the [Installation and Setup Guide](references/installation-setup.md).

使用npx：

bash

npx markdownlint-cli2 "**/*.md"

使用npm脚本（如果已配置）：

bash

npm run lint:md

作用：

对项目中所有
```
.md
```
文件运行
```
markdownlint-cli2
```
自动排除
```
node_modules
```
目录
输出带有文件路径和行号的错误
如果没有错误，退出码为0；如果有错误，退出码非0

示例输出：

text

docs/setup-guide.md:45:1 MD022/blanks-around-headings Headings should be surrounded by blank lines
README.md:12:81 MD009/no-trailing-spaces Trailing spaces

Check All Markdown Files

自动修复可修复的问题

With npx:

bash

npx markdownlint-cli2 "**/*.md"

With npm scripts (if configured):

bash

npm run lint:md

What this does:

Runs
```
markdownlint-cli2
```
against all
```
.md
```
files in the project
Automatically excludes
```
node_modules
```
directory
Outputs errors with file paths and line numbers
Exit code 0 if no errors, non-zero if errors found

Example output:

text

docs/setup-guide.md:45:1 MD022/blanks-around-headings Headings should be surrounded by blank lines
README.md:12:81 MD009/no-trailing-spaces Trailing spaces

使用npx：

bash

npx markdownlint-cli2 "**/*.md" --fix

使用npm脚本（如果已配置）：

bash

npm run lint:md:fix

作用：

自动修复可以安全纠正的问题
直接修改文件
报告剩余的无法自动修复的问题

可自动修复的问题包括：

尾随空格（MD009）
缺少空行（MD012、MD022）
列表标记一致性（MD004、MD007）
代码围栏样式（MD048）

无法自动修复的问题需要智能分析和手动修复：

标题结构（MD001、MD025）
重复标题（MD024）
行长度（MD013，如果启用）
链接引用（MD051、MD052）

Auto-Fix Fixable Issues

智能修复处理

With npx:

bash

npx markdownlint-cli2 "**/*.md" --fix

With npm scripts (if configured):

bash

npm run lint:md:fix

What this does:

Automatically fixes issues that can be safely corrected
Modifies files in place
Reports remaining unfixable issues

Fixable issues include:

Trailing spaces (MD009)
Missing blank lines (MD012, MD022)
List marker consistency (MD004, MD007)
Code fence style (MD048)

Non-fixable issues require intelligent analysis and manual fixes:

Heading structure (MD001, MD025)
Duplicate headings (MD024)
Line length (MD013, if enabled)
Link references (MD051, MD052)

自动修复后仍存在“无法自动修复”的错误时，请自动分析并修复它们。

有关处理每种错误类型的详细策略，请参阅专门的指南：

智能修复指南

本指南涵盖：

MD024 - 重复标题（基于上下文的重命名或删除）
MD001/MD025 - 标题结构（层级修复）
MD051/MD052 - 链接引用（锚点和引用链接修正）
MD013 - 行长度（智能换行）
上下文感知分析的一般原则
验证和报告最佳实践
使用并行Task代理优化性能

快速摘要：

先运行自动修复：
```
npx markdownlint-cli2 "**/*.md" --fix
```
对于剩余错误，读取受影响的文件以理解上下文
根据错误模式应用智能修复（请参阅指南）
始终重新运行代码检查以验证所有错误已解决
报告已修复的内容和方式

Intelligent Fix Handling

VS Code扩展设置（可选/进阶）

When "unfixable" errors remain after auto-fix, automatically analyze and fix them.

For detailed strategies on handling each error type, see the dedicated guide:

Intelligent Fixing Guide

This guide covers:

MD024 - Duplicate Headings (context-aware renaming or removal)
MD001/MD025 - Heading Structure (hierarchy fixes)
MD051/MD052 - Link References (anchor and reference link corrections)
MD013 - Line Length (intelligent wrapping)
General principles for context-aware analysis
Verification and reporting best practices
Performance optimization with parallel Task agents

Quick summary:

Run auto-fix first:
```
npx markdownlint-cli2 "**/*.md" --fix
```
For remaining errors, read affected files to understand context
Apply intelligent fixes based on error patterns (see guide)
Always re-run linting to verify all errors are resolved
Report what was fixed and how

如需VS Code集成，请参阅专门的指南：

VS Code扩展设置指南

VS Code扩展（

davidanson.vscode-markdownlint

）在编辑器中提供实时代码检查。本指南涵盖：

扩展安装与验证
自动修复配置（保存时格式化、粘贴时格式化）
交互式代码检查功能（波浪下划线、快速修复）
所有修复方法的键盘快捷键
配置优先级与故障排查
团队使用的最佳实践

这是可选的，但对于经常处理Markdown的用户强烈推荐。

VS Code Extension Setup (Optional/Advanced)

GitHub Actions集成（可选/进阶）

For VS Code integration, see the dedicated guide:

VS Code Extension Setup Guide

The VS Code extension (

davidanson.vscode-markdownlint

) provides real-time linting in your editor. The guide covers:

Extension installation and verification
Auto-fix configuration (format on save, format on paste)
Interactive linting features (squiggly underlines, quick fixes)
Keyboard shortcuts for all fix methods
Configuration precedence and troubleshooting
Best practices for team usage

This is optional but highly recommended for regular markdown work.

如需CI/CD集成，请参阅专门的指南：

GitHub Actions配置指南

GitHub Actions可以在PR和推送时自动验证Markdown文件。本指南涵盖：

完整的工作流文件配置
触发器设置（PR和推送事件，带路径过滤）
Action版本（checkout@v5、markdownlint-cli2-action@v22）
工作流执行流程与结果解读
查看和修复CI失败
进阶配置（自定义glob、自动修复、分支保护）
常见问题排查

这是可选的，但对于团队项目强烈推荐。

GitHub Actions Integration (Optional/Advanced)

自定义规则（需审批）

For CI/CD integration, see the dedicated guide:

GitHub Actions Configuration Guide

GitHub Actions can automatically validate markdown files on PRs and pushes. The guide covers:

Complete workflow file configuration
Trigger setup (PR and push events with path filtering)
Action versions (checkout@v5, markdownlint-cli2-action@v22)
Workflow execution flow and results interpretation
Viewing and fixing CI failures
Advanced configuration (custom globs, auto-fix, branch protection)
Troubleshooting common issues

This is optional but highly recommended for team projects.

警告：仅在获得上述策略的明确批准后才能修改。

如需详细的规则信息，请参阅综合指南：

Markdownlint规则参考

规则参考涵盖：

所有60+个MD规则的描述和示例
规则类别（可自动修复 vs 需要手动修复）
自定义规则的配置语法
常见的规则修改（禁用、配置参数）
每个文件覆盖的内联注释语法
每个规则的官方文档链接

快速语法提醒：

json

{
  "default": true,        // 启用所有默认规则
  "MD013": false,         // 禁用特定规则
  "MD033": {              // 使用选项配置
    "allowed_elements": ["br"]
  }
}

Customizing Rules (Requires Approval)

故障排查

WARNING: Only modify with explicit approval per policy above.

For detailed rule information, see the comprehensive guide:

Markdownlint Rules Reference

The rules reference covers:

All 60+ MD rules with descriptions and examples
Rule categories (auto-fixable vs manual-fix required)
Configuration syntax for customizing rules
Common rule modifications (disable, configure parameters)
Inline comment syntax for per-file overrides
Links to official documentation for each rule

Quick syntax reminder:

json

{
  "default": true,        // Enable all defaults
  "MD013": false,         // Disable specific rule
  "MD033": {              // Configure with options
    "allowed_elements": ["br"]
  }
}

常见问题与解决方案：

Troubleshooting

问题："Command not found: markdownlint-cli2"

Common issues and solutions:

解决方案： 运行

npm install

或使用npx：

npx markdownlint-cli2 "**/*.md"

Issue: "Command not found: markdownlint-cli2"

问题：代码检查错误太多，无法手动修复

Solution: Run

npm install

or use npx:

npx markdownlint-cli2 "**/*.md"

解决方案：

运行自动修复：
```
npx markdownlint-cli2 "**/*.md" --fix
```
分批修复剩余错误
请参阅安装指南获取详细的故障排查信息

Issue: Too many linting errors to fix manually

问题：VS Code或GitHub Actions问题

Solution:

Run auto-fix:
```
npx markdownlint-cli2 "**/*.md" --fix
```
Fix remaining errors in batches
See Installation Guide for detailed troubleshooting

如需详细的故障排查，请参阅专门的指南：

VS Code问题：VS Code扩展设置
GitHub Actions问题：GitHub Actions配置

Issue: VS Code or GitHub Actions problems

问题：规则违规不明确

For detailed troubleshooting, see the dedicated guides:

VS Code issues: VS Code Extension Setup
GitHub Actions issues: GitHub Actions Configuration

解决方案： 查阅Markdownlint规则参考获取规则解释、示例和官方文档链接。

Issue: Unclear rule violations

最佳实践

Solution: Check Markdownlint Rules Reference for rule explanations, examples, and official documentation links.

有关Markdown代码检查、配置管理、协作和技能自动化的综合最佳实践：

最佳实践指南

本指南涵盖：

结合代码检查有效编写Markdown
配置管理与规则自定义
协作模式与团队工作流
用于Claude Code的技能自动化
何时以及如何使用并行Task代理提高效率

Best Practices

资源

—

官方文档

For comprehensive best practices on markdown linting, configuration management, collaboration, and skill automation:

Best Practices Guide

The guide covers:

Writing markdown effectively with linting in mind
Configuration management and rule customization
Collaboration patterns and team workflows
Skill automation for Claude Code usage
When and how to use parallel Task agents for efficiency

markdownlint-cli2 README: github.com/DavidAnson/markdownlint-cli2
markdownlint规则: github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md
VS Code扩展: marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint
GitHub Action: github.com/DavidAnson/markdownlint-cli2-action

Resources

项目配置文件

Official Documentation

—

markdownlint-cli2 README: github.com/DavidAnson/markdownlint-cli2
markdownlint rules: github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md
VS Code extension: marketplace.visualstudio.com/items?itemName=DavidAnson.vscode-markdownlint
GitHub Action: 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）

Project Configuration Files

支持文档

These files should be created in your project root (see installation guides for setup):

Configuration:
```
.markdownlint-cli2.jsonc
```
(required for custom rules)
NPM scripts:
```
package.json
```
(optional, for npm run commands)
VS Code settings:
```
.vscode/settings.json
```
(optional, for auto-fix on save)
GitHub workflow:
```
.github/workflows/markdown-lint.yml
```
(optional, for 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工作流设置（可选/进阶）

Supporting Documentation

评估场景

This skill includes reference documentation in the

references/

directory:

references/installation-setup.md - Start here: Installation and first-time setup
references/intelligent-fixing-guide.md - Strategies for fixing "unfixable" errors
references/markdownlint-rules.md - Detailed rule explanations and customization
references/best-practices.md - Best practices for writing, configuration, collaboration, and automation
references/vscode-extension-setup.md - VS Code integration guide (optional/advanced)
references/github-actions-config.md - CI/CD workflow setup (optional/advanced)

这些场景用于评估技能激活、指导质量和多模型兼容性。

Evaluation Scenarios

场景1：首次设置

These scenarios are used to evaluate skill activation, guidance quality, and multi-model compatibility.

json

{
  "name": "首次设置",
  "query": "我需要在项目中设置Markdown代码检查",
  "context": "用户没有现有的Markdown代码检查配置",
  "files": [],
  "expected_behavior": [
    "技能成功激活",
    "加载references/installation-setup.md以获取全面指导",
    "提供分步安装说明",
    "区分npx（零配置）和本地安装方式",
    "指导配置.markdownlint-cli2.jsonc",
    "包含验证步骤"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

Scenario 1: First-time setup

场景2：修复代码检查错误

json

{
  "name": "First-time setup",
  "query": "I need to set up markdown linting in my project",
  "context": "User has no existing markdown linting configuration",
  "files": [],
  "expected_behavior": [
    "Skill activates successfully",
    "Loads references/installation-setup.md for comprehensive guidance",
    "Provides step-by-step installation instructions",
    "Distinguishes between npx (zero-setup) and local install approaches",
    "Guides through .markdownlint-cli2.jsonc configuration",
    "Includes verification steps"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

json

{
  "name": "修复代码检查错误",
  "query": "我遇到了MD022错误，如何修复？",
  "context": "用户遇到代码检查错误并需要修复指导",
  "files": ["sample-file.md"],
  "expected_behavior": [
    "针对错误类型和规则解释激活技能",
    "解释MD022规则（标题前后空行）",
    "提供自动修复命令（npx markdownlint-cli2 --fix）",
    "解释自动修复和智能修复两种方法",
    "必要时参考intelligent-fixing-guide.md",
    "提供验证步骤"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

Scenario 2: Fix linting errors

场景3：VS Code集成

json

{
  "name": "Fix linting errors",
  "query": "I'm getting MD022 errors, how do I fix them?",
  "context": "User has linting errors and needs guidance on fixes",
  "files": ["sample-file.md"],
  "expected_behavior": [
    "Skill activates for error type and rule explanation",
    "Explains MD022 rule (blanks around headings)",
    "Provides auto-fix command (npx markdownlint-cli2 --fix)",
    "Explains both automatic and intelligent fix approaches",
    "References intelligent-fixing-guide.md if needed",
    "Provides verification steps"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

json

{
  "name": "VS Code集成",
  "query": "如何在VS Code中启用保存时自动修复？",
  "context": "用户想要将Markdown代码检查集成到其编辑器工作流中",
  "files": [],
  "expected_behavior": [
    "针对VS Code集成激活技能",
    "加载references/vscode-extension-setup.md",
    "提供扩展安装说明",
    "解释在.vscode/settings.json中配置自动修复",
    "记录键盘快捷键和交互式功能",
    "包含常见VS Code问题的故障排查"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

Scenario 3: VS Code integration

场景4：GitHub Actions CI设置

json

{
  "name": "VS Code integration",
  "query": "How do I enable auto-fix on save in VS Code?",
  "context": "User wants to integrate markdown linting into their editor workflow",
  "files": [],
  "expected_behavior": [
    "Skill activates for VS Code integration",
    "Loads references/vscode-extension-setup.md",
    "Provides extension installation instructions",
    "Explains auto-fix configuration in .vscode/settings.json",
    "Documents keyboard shortcuts and interactive features",
    "Includes troubleshooting for common VS Code issues"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

json

{
  "name": "GitHub Actions CI设置",
  "query": "将Markdown代码检查添加到GitHub Actions",
  "context": "用户想要在CI/CD流水线中自动化Markdown验证",
  "files": [".github/workflows/"],
  "expected_behavior": [
    "针对GitHub Actions集成激活技能",
    "加载references/github-actions-config.md",
    "提供完整的工作流文件配置",
    "解释触发器设置（PR和推送事件）",
    "记录工作流执行和结果解读",
    "包含自动修复和分支保护的配置"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

Scenario 4: GitHub Actions CI setup

场景5：配置自定义

json

{
  "name": "GitHub Actions CI setup",
  "query": "Add markdown linting to GitHub Actions",
  "context": "User wants to automate markdown validation in CI/CD pipeline",
  "files": [".github/workflows/"],
  "expected_behavior": [
    "Skill activates for GitHub Actions integration",
    "Loads references/github-actions-config.md",
    "Provides complete workflow file configuration",
    "Explains trigger setup (PR and push events)",
    "Documents workflow execution and results interpretation",
    "Includes configuration for auto-fix and branch protection"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

json

{
  "name": "配置自定义",
  "query": "如何禁用MD013行长度规则？",
  "context": "用户需要为其项目自定义代码检查规则",
  "files": [".markdownlint-cli2.jsonc"],
  "expected_behavior": [
    "针对规则自定义激活技能",
    "解释配置策略（修改内容，而非规则）",
    "提供.markdownlint-cli2.jsonc配置示例",
    "展示禁用/配置特定规则的语法",
    "参考references/markdownlint-rules.md获取规则详细信息",
    "强调在所有工具中验证更改"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

Scenario 5: Configuration customization

多模型测试说明

json

{
  "name": "Configuration customization",
  "query": "How do I disable MD013 line length rule?",
  "context": "User needs to customize linting rules for their project",
  "files": [".markdownlint-cli2.jsonc"],
  "expected_behavior": [
    "Skill activates for rule customization",
    "Explains configuration policy (fix content, not rules)",
    "Provides .markdownlint-cli2.jsonc configuration example",
    "Shows syntax for disabling/configuring specific rules",
    "References references/markdownlint-rules.md for rule details",
    "Emphasizes verification of changes across all tools"
  ],
  "test_models": ["sonnet", "haiku", "opus"]
}

已测试模型：

Claude Sonnet: 性能最佳，很好地遵循了中心架构
Claude Haiku: （待测试 - 给定明确说明后应可正常工作）
Claude Opus: （待测试 - 可能过度分析，内容范围已适当限定）

观察结果: 技能的明确命令示例和清晰的决策树应在所有模型层级中正常工作。

Multi-Model Testing Notes

版本历史

Tested with:

Claude Sonnet: Optimal performance, follows hub architecture well
Claude Haiku: (To be tested - should work given explicit instructions)
Claude Opus: (To be tested - may over-analyze, content is appropriately scoped)

Observations: Skill's explicit command examples and clear decision trees should work well across all model tiers.

v2.0.0 (2025-11-30): 迁移到claude-code-plugins仓库中的code-quality插件
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+要求、action v21
v1.0.1 (2025-01-09): 提高可移植性 - 删除仓库特定语言，增强首次使用指导
v1.0.0 (2025-01-09): 初始版本 - 从
```
.claude/memory/workflows.md
```
迁移

Version History

最后更新

v2.0.0 (2025-11-30): Migrated to code-quality plugin in claude-code-plugins repo
v1.2.0 (2025-11-17): Extracted Intelligent Fixing Guide - moved detailed error fixing strategies to separate reference file, reduced SKILL.md size for better token efficiency
v1.1.0 (2025-11-17): Deduplicated content - removed duplicated reference material, streamlined to hub architecture
v1.0.2 (2025-11-17): Version updates - updated to markdownlint-cli2 v0.19.0, Node 20+ requirement, action v21
v1.0.1 (2025-01-09): Improved portability - removed repository-specific language, enhanced first-use guidance
v1.0.0 (2025-01-09): Initial release - migrated from
```
.claude/memory/workflows.md
```

日期: 2026-01-17 模型: claude-opus-4-5-20251101

Last Updated

—

Date: 2026-01-17 Model: claude-opus-4-5-20251101

—

markdown-linting

Original

Translation

Markdown Linting

Markdown代码检查

Table of Contents

目录

Overview

概述

When to Use This Skill

何时使用本技能

Markdown Flavors

Markdown格式支持

First Use: Installation and Setup

首次使用：安装与设置

Check if you're already set up

检查是否已配置

Setting Up Markdown Linting in Your Repo

在代码仓库中配置Markdown代码检查

Prerequisites

前置条件

Windows (PowerShell as Admin)

Windows（以管理员身份运行PowerShell）

macOS/Linux

macOS/Linux

Step 1: Create Configuration

步骤1：创建配置

Step 2: Add to package.json

步骤2：添加到package.json

Step 3: Add to .gitignore

步骤3：添加到.gitignore

Step 4: Add CI Workflow (Optional)

步骤4：添加CI工作流（可选）

Step 5: Run Linting

步骤5：运行代码检查

Verification Checklist

验证清单

Quick Start

快速开始

Check all markdown files

检查所有Markdown文件

Auto-fix issues

自动修复问题

Check all markdown files for linting errors

检查所有Markdown文件的代码检查错误

Auto-fix fixable linting issues

自动修复可修复的代码检查问题

Unified Tooling Architecture

统一工具架构

Tooling Components

工具组件

Configuration Source

配置来源

CRITICAL: Configuration Policy

重要说明：配置策略

Strict Policy - Never Modify Without Approval

严格策略 - 未经批准请勿修改

Why This Policy Exists

该策略存在的原因

Proper Response to Linting Errors

处理代码检查错误的正确方式

CRITICAL: NO AUTOMATED SCRIPTS

重要说明：禁止使用自动化脚本

Why This Policy Exists

该策略存在的原因

Nested Code Blocks: A Critical Complexity

嵌套代码块：关键复杂性

Real-World Failure Example

实际失败示例

The ONLY Acceptable Approach

唯一可接受的方法

If You Even Consider Using a Script

MD040（fenced-code-language）特殊指导

MD040 (fenced-code-language) Special Guidance

在本地运行代码检查

重要：自动修复工作流

Running Linting Locally

前置条件

CRITICAL: Auto-Fix Workflow

Prerequisites