{"owner":"DavidAnson","repo":"markdownlint","hasSkills":true,"totalSkillsCount":1,"totalTokensCount":18278,"categories":["root-instruction"],"hasMcp":false,"mcpConfig":null,"found":["doc/Rules.md"],"skills":{"doc/Rules.md":"# Rules\n\nThis document contains a description of all rules, what they are checking for,\nas well as examples of documents that break the rule and corrected\nversions of the examples.\n\n\n\n## `MD001` - Heading levels should only increment by one level at a time\n\nTags: `headings`\n\nAliases: `heading-increment`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n\nThis rule is triggered when you skip heading levels in a Markdown document, for\nexample:\n\n```markdown\n# Heading 1\n\n### Heading 3\n\nWe skipped out a 2nd level heading in this document\n```\n\nWhen using multiple heading levels, nested headings should increase by only one\nlevel at a time:\n\n```markdown\n# Heading 1\n\n## Heading 2\n\n### Heading 3\n\n#### Heading 4\n\n## Another Heading 2\n\n### Another Heading 3\n```\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation if the actual first\nheading is not a level 2 heading. To use a different property name in the\nfront matter, specify the text of a regular expression via the\n`front_matter_title` parameter. To disable the use of front matter by this\nrule, specify `\"\"` for `front_matter_title`. When front matter is not present,\nthe first heading can be any level.\n\nRationale: Headings represent the structure of a document and can be confusing\nwhen skipped - especially for accessibility scenarios. More information:\n.\n\n\n\n## `MD003` - Heading style\n\nTags: `headings`\n\nAliases: `heading-style`\n\nParameters:\n\n- `style`: Heading style (`string`, default `consistent`, values `atx` /\n `atx_closed` / `consistent` / `setext` / `setext_with_atx` /\n `setext_with_atx_closed`)\n\nThis rule is triggered when different heading styles are used in the same\ndocument:\n\n```markdown\n# ATX style H1\n\n## Closed ATX style H2 ##\n\nSetext style H1\n===============\n```\n\nTo fix the issue, use consistent heading styles throughout the document:\n\n```markdown\n# ATX style H1\n\n## ATX style H2\n```\n\nThe `setext_with_atx` and `setext_with_atx_closed` settings allow ATX-style\nheadings of level 3 or more in documents with setext-style headings (which only\nsupport level 1 and 2 headings):\n\n```markdown\nSetext style H1\n===============\n\nSetext style H2\n---------------\n\n### ATX style H3\n```\n\nNote: The configured heading style can be a specific style to require (`atx`,\n`atx_closed`, `setext`, `setext_with_atx`, `setext_with_atx_closed`), or can\nrequire that all heading styles match the first heading style via `consistent`.\n\nNote: The placement of a horizontal rule directly below a line of text can\ntrigger this rule by turning that text into a level 2 setext-style heading:\n\n```markdown\nA line of text followed by a horizontal rule becomes a heading\n---\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD004` - Unordered list style\n\nTags: `bullet`, `ul`\n\nAliases: `ul-style`\n\nParameters:\n\n- `style`: List style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `dash` / `plus` / `sublist`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for unordered\nlist items do not match the configured unordered list style:\n\n```markdown\n* Item 1\n+ Item 2\n- Item 3\n```\n\nTo fix this issue, use the configured style for list items throughout the\ndocument:\n\n```markdown\n* Item 1\n* Item 2\n* Item 3\n```\n\nThe configured list style can ensure all list styling is a specific symbol\n(`asterisk`, `plus`, `dash`), ensure each sublist has a consistent symbol that\ndiffers from its parent list (`sublist`), or ensure all list styles match the\nfirst list style (`consistent`).\n\nFor example, the following is valid for the `sublist` style because the\nouter-most indent uses asterisk, the middle indent uses plus, and the inner-most\nindent uses dash:\n\n```markdown\n* Item 1\n + Item 2\n - Item 3\n + Item 4\n* Item 4\n + Item 5\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD005` - Inconsistent indentation for list items at the same level\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `list-indent`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are parsed as being at the same level,\nbut don't have the same indentation:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * A misaligned item\n```\n\nUsually, this rule will be triggered because of a typo. Correct the indentation\nfor the list to fix it:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * Nested Item 3\n```\n\nSequentially-ordered list markers are usually left-aligned such that all items\nhave the same starting column:\n\n```markdown\n...\n8. Item\n9. Item\n10. Item\n11. Item\n...\n```\n\nThis rule also supports right-alignment of list markers such that all items have\nthe same ending column:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n...\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD007` - Unordered list indentation\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `ul-indent`\n\nParameters:\n\n- `indent`: Spaces for indent (`integer`, default `2`)\n- `start_indent`: Spaces for first level indent (when start_indented is set)\n (`integer`, default `2`)\n- `start_indented`: Whether to indent the first level of the list (`boolean`,\n default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are not indented by the configured\nnumber of spaces (default: 2).\n\nExample:\n\n```markdown\n* List item\n * Nested list item indented by 3 spaces\n```\n\nCorrected Example:\n\n```markdown\n* List item\n * Nested list item indented by 2 spaces\n```\n\nNote: This rule applies to a sublist only if its parent lists are all also\nunordered (otherwise, extra indentation of ordered lists interferes with the\nrule).\n\nThe `start_indented` parameter allows the first level of lists to be indented by\nthe configured number of spaces rather than starting at zero. The `start_indent`\nparameter allows the first level of lists to be indented by a different number\nof spaces than the rest (ignored when `start_indented` is not set).\n\nRationale: Indenting by 2 spaces allows the content of a nested list to be in\nline with the start of the content of the parent list when a single space is\nused after the list marker. Indenting by 4 spaces is consistent with code blocks\nand simpler for editors to implement. Additionally, this can be a compatibility\nissue for other Markdown parsers, which require 4-space indents. More\ninformation: [Markdown Style Guide][markdown-style-guide].\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n[markdown-style-guide]: https://cirosantilli.com/markdown-style-guide#indentation-of-content-inside-lists\n\n\n\n## `MD009` - Trailing spaces\n\nTags: `whitespace`\n\nAliases: `no-trailing-spaces`\n\nParameters:\n\n- `br_spaces`: Spaces for line break (`integer`, default `2`)\n- `code_blocks`: Include code blocks (`boolean`, default `false`)\n- `list_item_empty_lines`: Allow spaces for empty lines in list items\n (`boolean`, default `false`)\n- `strict`: Include unnecessary breaks (`boolean`, default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any lines that end with unexpected whitespace. To fix\nthis, remove the trailing space from the end of the line.\n\nThe `br_spaces` parameter allows an exception to this rule for a specific number\nof trailing spaces, typically used to insert an explicit line break. The default\nvalue allows 2 spaces to indicate a hard break (\\
element). (You must set\n`br_spaces` to a value >= 2 for this parameter to take effect. Setting\n`br_spaces` to 1 behaves the same as 0, disallowing any trailing spaces.)\n\nBy default, trailing space is allowed in indented and fenced code blocks because\nsome programming languages require that. To report such instances, set the\n`code_blocks` parameter to `true`.\n\nBy default, this rule will not trigger when the allowed number of spaces is\nused, even when it doesn't create a hard break (for example, at the end of a\nparagraph). To report such instances, set the `strict` parameter to `true`.\n\n```markdown\nText text text\ntext[2 spaces]\n```\n\nUsing spaces to indent blank lines inside a list item is usually not necessary,\nbut some parsers require it. Set the `list_item_empty_lines` parameter to `true`\nto allow this (even when `strict` is `true`):\n\n```markdown\n- list item text\n [2 spaces]\n list item text\n```\n\nRationale: Except when being used to create a line break, trailing whitespace\nhas no purpose and does not affect the rendering of content.\n\n\n\n## `MD010` - Hard tabs\n\nTags: `hard_tab`, `whitespace`\n\nAliases: `no-hard-tabs`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `ignore_code_languages`: Fenced code languages to ignore (`string[]`, default\n `[]`)\n- `spaces_per_tab`: Number of spaces for each hard tab (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered by any lines that contain hard tab characters instead\nof using spaces for indentation. To fix this, replace any hard tab characters\nwith spaces instead.\n\nExample:\n\n\n\n```markdown\nSome text\n\n\t* hard tab character used to indent the list item\n```\n\n\n\nCorrected example:\n\n```markdown\nSome text\n\n * Spaces used to indent the list item instead\n```\n\nYou have the option to exclude this rule for code blocks and spans. To do so,\nset the `code_blocks` parameter to `false`. Code blocks and spans are included\nby default since handling of tabs by Markdown tools can be inconsistent (e.g.,\nusing 4 vs. 8 spaces).\n\nWhen code blocks are scanned (e.g., by default or if `code_blocks` is `true`),\nthe `ignore_code_languages` parameter can be set to a list of languages that\nshould be ignored (i.e., hard tabs will be allowed, though not required). This\nmakes it easier for documents to include code for languages that require hard\ntabs.\n\nBy default, violations of this rule are fixed by replacing the tab with 1 space\ncharacter. To use a different number of spaces, set the `spaces_per_tab`\nparameter to the desired value.\n\nRationale: Hard tabs are often rendered inconsistently by different editors and\ncan be harder to work with than spaces.\n\nMore information:\n\n- \n- \n\n\n\n## `MD011` - Reversed link syntax\n\nTags: `links`\n\nAliases: `no-reversed-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when text that appears to be a link is encountered, but\nwhere the syntax appears to have been reversed (the `[]` and `()` are\nreversed):\n\n```markdown\n(Incorrect link syntax)[https://www.example.com/]\n```\n\nTo fix this, swap the `[]` and `()` around:\n\n```markdown\n[Correct link syntax](https://www.example.com/)\n```\n\nNote: [Markdown Extra](https://wikipedia.org/wiki/Markdown_Extra)-style\nfootnotes do not trigger this rule:\n\n```markdown\nFor (example)[^1]\n```\n\nRationale: Reversed links are not rendered as usable links.\n\n\n\n## `MD012` - Multiple consecutive blank lines\n\nTags: `blank_lines`, `whitespace`\n\nAliases: `no-multiple-blanks`\n\nParameters:\n\n- `maximum`: Consecutive blank lines (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are multiple consecutive blank lines in the\ndocument:\n\n```markdown\nSome text here\n\n\nSome more text here\n```\n\nTo fix this, delete the offending lines:\n\n```markdown\nSome text here\n\nSome more text here\n```\n\nNote: this rule will not be triggered if there are multiple consecutive blank\nlines inside code blocks.\n\nNote: The `maximum` parameter can be used to configure the maximum number of\nconsecutive blank lines.\n\nRationale: Except in a code block, blank lines serve no purpose and do not\naffect the rendering of content.\n\n\n\n## `MD013` - Line length\n\nTags: `line_length`\n\nAliases: `line-length`\n\nParameters:\n\n- `code_block_line_length`: Number of characters for code blocks (`integer`,\n default `80`)\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `heading_line_length`: Number of characters for headings (`integer`, default\n `80`)\n- `headings`: Include headings (`boolean`, default `true`)\n- `line_length`: Number of characters (`integer`, default `80`)\n- `stern`: Stern length checking (`boolean`, default `false`)\n- `strict`: Strict length checking (`boolean`, default `false`)\n- `tables`: Include tables (`boolean`, default `true`)\n\nThis rule is triggered when there are lines that are longer than the\nconfigured `line_length` (default: 80 characters). To fix this, split the line\nup into multiple lines. To set a different maximum length for headings, use\n`heading_line_length`. To set a different maximum length for code blocks, use\n`code_block_line_length`\n\nThis rule has an exception when there is no whitespace beyond the configured\nline length. This allows you to include items such as long URLs without being\nforced to break them in the middle. To disable this exception, set the `strict`\nparameter to `true` and an issue will be reported when any line is too long. To\nwarn for lines that are too long and could be fixed but allow long lines\nwithout spaces, set the `stern` parameter to `true`.\n\nFor example (assuming normal behavior):\n\n```markdown\nIF THIS LINE IS THE MAXIMUM LENGTH\nThis line is okay because there are-no-spaces-beyond-that-length\nThis line is a violation because there are spaces beyond that length\nThis-line-is-okay-because-there-are-no-spaces-anywhere-within\n```\n\nIn `strict` mode, the last three lines above are all violations. In `stern`\nmode, the middle two lines above are both violations, but the last is okay.\n\nYou have the option to exclude this rule for code blocks, tables, or headings.\nTo do so, set the `code_blocks`, `tables`, or `headings` parameter(s) to false.\n\nCode blocks are included in this rule by default since it is often a\nrequirement for document readability, and tentatively compatible with code\nrules. Still, some languages do not lend themselves to short lines.\n\nLines with link/image reference definitions and standalone lines (i.e., not part\nof a paragraph) with only a link/image (possibly using (strong) emphasis) are\nalways exempted from this rule (even in `strict` mode) because there is often no\nway to split such lines without breaking the URL.\n\nRationale: Extremely long lines can be difficult to work with in some editors.\nMore information: .\n\n\n\n## `MD014` - Dollar signs used before commands without showing output\n\nTags: `code`\n\nAliases: `commands-show-output`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are code blocks showing shell commands to be\ntyped, and *all* of the shell commands are preceded by dollar signs ($):\n\n\n\n```markdown\n$ ls\n$ cat foo\n$ less bar\n```\n\n\n\nThe dollar signs are unnecessary in this situation, and should not be\nincluded:\n\n```markdown\nls\ncat foo\nless bar\n```\n\nShowing output for commands preceded by dollar signs does not trigger this rule:\n\n```markdown\n$ ls\nfoo bar\n$ cat foo\nHello world\n$ cat bar\nbaz\n```\n\nBecause some commands do not produce output, it is not a violation if *some*\ncommands do not have output:\n\n```markdown\n$ mkdir test\nmkdir: created directory 'test'\n$ ls test\n```\n\nRationale: It is easier to copy/paste and less noisy if the dollar signs\nare omitted when they are not needed. See\n\nfor more information.\n\n\n\n## `MD018` - No space after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-missing-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing after the hash characters\nin an atx style heading:\n\n```markdown\n#Heading 1\n\n##Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD019` - Multiple spaces after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-multiple-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in an atx style heading:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD020` - No space inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-missing-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing inside the hash characters\nin a closed atx style heading:\n\n```markdown\n#Heading 1#\n\n##Heading 2##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading is missing spaces.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD021` - Multiple spaces inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-multiple-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in a closed atx style heading:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading contains multiple\nspaces.\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD022` - Headings should be surrounded by blank lines\n\nTags: `blank_lines`, `headings`\n\nAliases: `blanks-around-headings`\n\nParameters:\n\n- `include_front_matter`: Include front matter content (`boolean`, default\n `false`)\n- `lines_above`: Blank lines above heading (`integer|integer[]`, default `1`)\n- `lines_below`: Blank lines below heading (`integer|integer[]`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when headings (any style) are either not preceded or not\nfollowed by at least one blank line:\n\n```markdown\n# Heading 1\nSome text\n\nSome more text\n## Heading 2\n```\n\nTo fix this, ensure that all headings have a blank line both before and after\n(except where the heading is at the beginning or end of the document):\n\n```markdown\n# Heading 1\n\nSome text\n\nSome more text\n\n## Heading 2\n```\n\nThe `lines_above` and `lines_below` parameters can be used to specify a\ndifferent number of blank lines (including `0`) above or below each heading.\nIf the value `-1` is used for either parameter, any number of blank lines is\nallowed. To customize the number of lines above or below each heading level\nindividually, specify a `number[]` where values correspond to heading levels\n1-6 (in order).\n\nNotes: If `lines_above` or `lines_below` are configured to require more than one\nblank line, [MD012/no-multiple-blanks](md012.md) should also be customized. This\nrule checks for *at least* as many blank lines as specified; any extra blank\nlines are ignored.\n\nBy default, [YAML](https://wikipedia.org/wiki/YAML) front matter is ignored, so\nthe following document reports no violations:\n\n```markdown\n---\ntitle: Title\n---\n## Heading\n```\n\nTo require the configured number of blank lines between front matter content and\na document's first heading, set the `include_front_matter` parameter to `true`.\n\nRationale: Aside from aesthetic reasons, some parsers, including `kramdown`,\nwill not parse headings that don't have a blank line before, and will parse them\nas regular text.\n\n\n\n## `MD023` - Headings must start at the beginning of the line\n\nTags: `headings`, `spaces`\n\nAliases: `heading-start-left`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a heading is indented by one or more spaces:\n\n```markdown\nSome text\n\n # Indented heading\n```\n\nTo fix this, ensure that all headings start at the beginning of the line:\n\n```markdown\nSome text\n\n# Heading\n```\n\nNote that scenarios like block quotes \"indent\" the start of the line, so the\nfollowing is also correct:\n\n```markdown\n> # Heading in Block Quote\n```\n\nRationale: Headings that don't start at the beginning of the line will not be\nparsed as headings, and will instead appear as regular text.\n\n\n\n## `MD024` - Multiple headings with the same content\n\nTags: `headings`\n\nAliases: `no-duplicate-heading`\n\nParameters:\n\n- `siblings_only`: Only check sibling headings (`boolean`, default `false`)\n\nThis rule is triggered if there are multiple headings in the document that have\nthe same text:\n\n```markdown\n# Some text\n\n## Some text\n```\n\nTo fix this, ensure that the content of each heading is different:\n\n```markdown\n# Some text\n\n## Some more text\n```\n\nIf the parameter `siblings_only` is set to `true`, duplication is allowed for\nheadings with different parents (as is common in changelogs):\n\n```markdown\n# Change log\n\n## 1.0.0\n\n### Features\n\n## 2.0.0\n\n### Features\n```\n\nRationale: Some Markdown parsers generate anchors for headings based on the\nheading name; headings with the same content can cause problems with that.\n\n\n\n## `MD025` - Multiple top-level headings in the same document\n\nTags: `headings`\n\nAliases: `single-h1`, `single-title`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is triggered when a top-level heading is in use (the first line of\nthe file is an h1 heading), and more than one h1 heading is in use in the\ndocument:\n\n```markdown\n# Top level heading\n\n# Another top-level heading\n```\n\nTo fix, structure your document so there is a single h1 heading that is\nthe title for the document. Subsequent headings must be\nlower-level headings (h2, h3, etc.):\n\n```markdown\n# Title\n\n## Heading\n\n## Another heading\n```\n\nNote: The `level` parameter can be used to change the top-level (ex: to h2) in\ncases where an h1 is added externally.\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation for any subsequent\ntop-level headings. To use a different property name in the front matter,\nspecify the text of a regular expression via the `front_matter_title` parameter.\nTo disable the use of front matter by this rule, specify `\"\"` for\n`front_matter_title`.\n\nRationale: A top-level heading is an h1 on the first line of the file, and\nserves as the title for the document. If this convention is in use, then there\ncan not be more than one title for the document, and the entire document should\nbe contained within this heading.\n\n\n\n## `MD026` - Trailing punctuation in heading\n\nTags: `headings`\n\nAliases: `no-trailing-punctuation`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!。，；：！`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any heading that has one of the specified normal or\nfull-width punctuation characters as the last character in the line:\n\n```markdown\n# This is a heading.\n```\n\nTo fix this, remove the trailing punctuation:\n\n```markdown\n# This is a heading\n```\n\nNote: The `punctuation` parameter can be used to specify what characters count\nas punctuation at the end of a heading. For example, you can change it to\n`\".,;:\"` to allow headings that end with an exclamation point. `?` is\nallowed by default because of how common it is in headings of FAQ-style\ndocuments. Setting the `punctuation` parameter to `\"\"` allows all characters -\nand is equivalent to disabling the rule.\n\nNote: The trailing semicolon of [HTML entity references][html-entity-references]\nlike `©`, `©`, and `©` is ignored by this rule.\n\nRationale: Headings are not meant to be full sentences. More information:\n[Punctuation at the end of headers][end-punctuation].\n\n[end-punctuation]: https://cirosantilli.com/markdown-style-guide#punctuation-at-the-end-of-headers\n[html-entity-references]: https://wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references\n\n\n\n## `MD027` - Multiple spaces after blockquote symbol\n\nTags: `blockquote`, `indentation`, `whitespace`\n\nAliases: `no-multiple-space-blockquote`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when blockquotes have more than one space after the\nblockquote (`>`) symbol:\n\n```markdown\n> This is a blockquote with bad indentation\n> there should only be one.\n```\n\nTo fix, remove any extraneous space:\n\n```markdown\n> This is a blockquote with correct\n> indentation.\n```\n\nInferring intended list indentation within a blockquote can be challenging;\nsetting the `list_items` parameter to `false` disables this rule for ordered\nand unordered list items.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD028` - Blank line inside blockquote\n\nTags: `blockquote`, `whitespace`\n\nAliases: `no-blanks-blockquote`\n\nThis rule is triggered when two blockquote blocks are separated by nothing\nbut a blank line:\n\n```markdown\n> This is a blockquote\n> which is immediately followed by\n\n> this blockquote. In some cases,\n> these may be merged into one blockquote.\n```\n\nTo fix this, ensure that consecutive blockquotes have text (or an HTML comment)\nin between:\n\n```markdown\n> This is a blockquote.\n\nThis is paragraph text.\n\n> This is a second blockquote.\n\n\n\n> This is a third blockquote.\n```\n\nIf they are meant to be a single quote, add the blockquote symbol at the\nbeginning of the blank line:\n\n```markdown\n> This is a blockquote.\n>\n> This is the same blockquote.\n```\n\nRationale: Some Markdown parsers will treat two blockquotes separated by one\nor more blank lines as the same blockquote, while others will treat them as\nseparate blockquotes.\n\n\n\n## `MD029` - Ordered list item prefix\n\nTags: `ol`\n\nAliases: `ol-prefix`\n\nParameters:\n\n- `style`: List style (`string`, default `one_or_ordered`, values `one` /\n `one_or_ordered` / `ordered` / `zero`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for ordered lists that do not either start with '1.' or\ndo not have a prefix that increases in numerical order (depending on the\nconfigured style). The less-common pattern of using '0.' as a first prefix or\nfor all prefixes is also supported.\n\nExample valid list if the style is configured as 'one':\n\n```markdown\n1. Do this.\n1. Do that.\n1. Done.\n```\n\nExamples of valid lists if the style is configured as 'ordered':\n\n```markdown\n1. Do this.\n2. Do that.\n3. Done.\n```\n\n```markdown\n0. Do this.\n1. Do that.\n2. Done.\n```\n\nAll three examples are valid when the style is configured as 'one_or_ordered'.\n\nExample valid list if the style is configured as 'zero':\n\n```markdown\n0. Do this.\n0. Do that.\n0. Done.\n```\n\nExample invalid list for all styles:\n\n```markdown\n1. Do this.\n3. Done.\n```\n\nThis rule supports 0-prefixing list items for uniform indentation and will\npreserve that when fixing:\n\n```markdown\n...\n08. Item\n09. Item\n10. Item\n11. Item\n```\n\nWhen list items appear to be right-aligned, fixes will maintain that alignment:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n```\n\nNote: This rule will report violations for cases like the following where an\nimproperly-indented code block (or similar) appears between two list items and\n\"breaks\" the list in two:\n\n\n\n~~~markdown\n1. First list\n\n```text\nCode block\n```\n\n1. Second list\n~~~\n\nThe fix is to indent the code block so it becomes part of the preceding list\nitem as intended:\n\n~~~markdown\n1. First list\n\n ```text\n Code block\n ```\n\n2. Still first list\n~~~\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD030` - Spaces after list markers\n\nTags: `ol`, `ul`, `whitespace`\n\nAliases: `list-marker-space`\n\nParameters:\n\n- `ol_multi`: Spaces for multi-line ordered list items (`integer`, default `1`)\n- `ol_single`: Spaces for single-line ordered list items (`integer`, default\n `1`)\n- `ul_multi`: Spaces for multi-line unordered list items (`integer`, default\n `1`)\n- `ul_single`: Spaces for single-line unordered list items (`integer`, default\n `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule checks for the number of spaces between a list marker (e.g. '`-`',\n'`*`', '`+`' or '`1.`') and the text of the list item.\n\nThe number of spaces checked for depends on the document style in use, but the\ndefault is 1 space after any list marker:\n\n```markdown\n* Foo\n* Bar\n* Baz\n\n1. Foo\n1. Bar\n1. Baz\n\n1. Foo\n * Bar\n1. Baz\n```\n\nA document style may change the number of spaces after unordered list items\nand ordered list items independently, as well as based on whether the content\nof every item in the list consists of a single paragraph or multiple\nparagraphs (including sub-lists and code blocks).\n\nFor example, the style guide at\n\nspecifies that 1 space after the list marker should be used if every item in\nthe list fits within a single paragraph, but to use 2 or 3 spaces (for ordered\nand unordered lists respectively) if there are multiple paragraphs of content\ninside the list:\n\n```markdown\n* Foo\n* Bar\n* Baz\n```\n\nvs.\n\n```markdown\n* Foo\n\n Second paragraph\n\n* Bar\n```\n\nor\n\n```markdown\n1. Foo\n\n Second paragraph\n\n1. Bar\n```\n\nTo fix this, ensure the correct number of spaces are used after the list marker\nfor your selected document style.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n\n\n## `MD031` - Fenced code blocks should be surrounded by blank lines\n\nTags: `blank_lines`, `code`\n\nAliases: `blanks-around-fences`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when fenced code blocks are either not preceded or not\nfollowed by a blank line:\n\n````markdown\nSome text\n```\nCode block\n```\n\n```\nAnother code block\n```\nSome more text\n````\n\nTo fix this, ensure that all fenced code blocks have a blank line both before\nand after (except where the block is at the beginning or end of the document):\n\n````markdown\nSome text\n\n```\nCode block\n```\n\n```\nAnother code block\n```\n\nSome more text\n````\n\nSet the `list_items` parameter to `false` to disable this rule for list items.\nDisabling this behavior for lists can be useful if it is necessary to create a\n[tight](https://spec.commonmark.org/0.29/#tight) list containing a code fence.\n\nRationale: Aside from aesthetic reasons, some parsers, including kramdown, will\nnot parse fenced code blocks that don't have blank lines before and after them.\n\n\n\n## `MD032` - Lists should be surrounded by blank lines\n\nTags: `blank_lines`, `bullet`, `ol`, `ul`\n\nAliases: `blanks-around-lists`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when lists (of any kind) are either not preceded or not\nfollowed by a blank line:\n\n```markdown\nSome text\n* List item\n* List item\n\n1. List item\n2. List item\n***\n```\n\nIn the first case above, text immediately precedes the unordered list. In the\nsecond case above, a thematic break immediately follows the ordered list. To fix\nviolations of this rule, ensure that all lists have a blank line both before and\nafter (except when the list is at the very beginning or end of the document):\n\n```markdown\nSome text\n\n* List item\n* List item\n\n1. List item\n2. List item\n\n***\n```\n\nNote that the following case is **not** a violation of this rule:\n\n```markdown\n1. List item\n More item 1\n2. List item\nMore item 2\n```\n\nAlthough it is not indented, the text \"More item 2\" is referred to as a\n[lazy continuation line][lazy-continuation] and considered part of the second\nlist item.\n\nRationale: In addition to aesthetic reasons, some parsers, including kramdown,\nwill not parse lists that don't have blank lines before and after them.\n\n[lazy-continuation]: https://spec.commonmark.org/0.30/#lazy-continuation-line\n\n\n\n## `MD033` - Inline HTML\n\nTags: `html`\n\nAliases: `no-inline-html`\n\nParameters:\n\n- `allowed_elements`: Allowed elements (`string[]`, default `[]`)\n- `table_allowed_elements`: Allowed elements in tables (`string[]`, default\n `[]`)\n\nThis rule is triggered whenever raw HTML is used in a Markdown document:\n\n```markdown\n

Inline HTML heading

\n```\n\nTo fix this, use 'pure' Markdown instead of including raw HTML:\n\n```markdown\n# Markdown heading\n```\n\nTo allow specific HTML elements anywhere in Markdown content, set the\n`allowed_elements` parameter to a list of HTML element names. To allow a\nspecific set of HTML elements within Markdown tables, set the\n`table_allowed_elements` parameter to a list of HTML element names. This can be\nused to permit the use of `
`-style line breaks only within Markdown tables.\n\nRationale: Raw HTML is allowed in Markdown, but this rule is included for\nthose who want their documents to only include \"pure\" Markdown, or for those\nwho are rendering Markdown documents into something other than HTML.\n\n\n\n## `MD034` - Bare URL used\n\nTags: `links`, `url`\n\nAliases: `no-bare-urls`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered whenever a URL or email address appears without\nsurrounding angle brackets:\n\n```markdown\nFor more info, visit https://www.example.com/ or email user@example.com.\n```\n\nTo fix this, add angle brackets around the URL or email address:\n\n```markdown\nFor more info, visit or email .\n```\n\nIf a URL or email address contains non-ASCII characters, it may be not be\nhandled as intended even when angle brackets are present. In such cases,\n[percent-encoding](https://wikipedia.org/wiki/Percent-encoding) can be used\nto comply with the required syntax for URL and email.\n\nNote: To include a bare URL or email without it being converted into a link,\nwrap it in a code span:\n\n```markdown\nNot a clickable link: `https://www.example.com`\n```\n\nNote: The following scenario does not trigger this rule because it could be a\nshortcut link:\n\n```markdown\n[https://www.example.com]\n```\n\nNote: The following syntax triggers this rule because the nested link could be\na shortcut link (which takes precedence):\n\n```markdown\n[text [shortcut] text](https://example.com)\n```\n\nTo avoid this, escape both inner brackets:\n\n```markdown\n[link \\[text\\] link](https://example.com)\n```\n\nRationale: Without angle brackets, a bare URL or email isn't converted into a\nlink by some Markdown parsers.\n\n\n\n## `MD035` - Horizontal rule style\n\nTags: `hr`\n\nAliases: `hr-style`\n\nParameters:\n\n- `style`: Horizontal rule style (`string`, default `consistent`)\n\nThis rule is triggered when inconsistent styles of horizontal rules (also known\nas \"thematic breaks\") are used in a document:\n\n```markdown\n---\n\n- - -\n\n***\n\n* * *\n\n****\n```\n\nTo fix this, use the same horizontal rule syntax everywhere:\n\n```markdown\n---\n\n---\n\n---\n```\n\nThe `style` parameter's default value `consistent` ensures all horizontal rules\nin a document match the first horizontal rule in that document. To enforce a\nspecific pattern of characters, set the `style` parameter to that string (e.g.,\n`\"* * *\"`).\n\nNote: In order to be recognized as a horizontal rule, a line must contain three\nor more matching `-`, `_`, or `*` characters with optional space between.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD036` - Emphasis used instead of a heading\n\nTags: `emphasis`, `headings`\n\nAliases: `no-emphasis-as-heading`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!?。，；：！？`)\n\nThis check looks for instances where emphasized (i.e. bold or italic) text is\nused to separate sections, where a heading should be used instead:\n\n```markdown\n**My document**\n\nLorem ipsum dolor sit amet...\n\n_Another section_\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nTo fix this, use Markdown headings instead of emphasized text to denote\nsections:\n\n```markdown\n# My document\n\nLorem ipsum dolor sit amet...\n\n## Another section\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nNote: This rule looks for single-line paragraphs that consist entirely\nof emphasized text. It won't fire on emphasis used within regular text,\nmulti-line emphasized paragraphs, or paragraphs ending in punctuation\n(normal or full-width). Similarly to rule MD026, you can configure what\ncharacters are recognized as punctuation.\n\nRationale: Using emphasis instead of a heading prevents tools from inferring\nthe structure of a document. More information:\n.\n\n\n\n## `MD037` - Spaces inside emphasis markers\n\nTags: `emphasis`, `whitespace`\n\nAliases: `no-space-in-emphasis`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when emphasis markers (bold, italic) are used, but they\nhave spaces between the markers and the text:\n\n```markdown\nHere is some ** bold ** text.\n\nHere is some * italic * text.\n\nHere is some more __ bold __ text.\n\nHere is some more _ italic _ text.\n```\n\nTo fix this, remove the spaces around the emphasis markers:\n\n```markdown\nHere is some **bold** text.\n\nHere is some *italic* text.\n\nHere is some more __bold__ text.\n\nHere is some more _italic_ text.\n```\n\nRationale: Emphasis is only parsed as such when the asterisks/underscores\naren't surrounded by spaces. This rule attempts to detect where\nthey were surrounded by spaces, but it appears that emphasized text was\nintended by the author.\n\n\n\n## `MD038` - Spaces inside code span elements\n\nTags: `code`, `whitespace`\n\nAliases: `no-space-in-code`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for code spans containing content with unnecessary space\nnext to the beginning or ending backticks:\n\n```markdown\n`some text `\n\n` some text`\n\n` some text `\n```\n\nTo fix this, remove the extra space characters from the beginning and ending:\n\n```markdown\n`some text`\n```\n\nNote: A single leading *and* trailing space is allowed by the specification and\ntrimmed by the parser to support code spans that begin or end with a backtick:\n\n```markdown\n`` `backticks` ``\n\n`` backtick` ``\n```\n\nNote: When single-space padding is present in the input, it will be preserved\n(even if unnecessary):\n\n```markdown\n` code `\n```\n\nNote: Code spans containing only spaces are allowed by the specification and are\nalso preserved:\n\n```markdown\n` `\n\n` `\n```\n\nRationale: Violations of this rule are usually unintentional and can lead to\nimproperly-rendered content.\n\n\n\n## `MD039` - Spaces inside link text\n\nTags: `links`, `whitespace`\n\nAliases: `no-space-in-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on links that have spaces surrounding the link text:\n\n```markdown\n[ a link ](https://www.example.com/)\n```\n\nTo fix this, remove the spaces surrounding the link text:\n\n```markdown\n[a link](https://www.example.com/)\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD040` - Fenced code blocks should have a language specified\n\nTags: `code`, `language`\n\nAliases: `fenced-code-language`\n\nParameters:\n\n- `allowed_languages`: List of languages (`string[]`, default `[]`)\n- `language_only`: Require language only (`boolean`, default `false`)\n\nThis rule is triggered when fenced code blocks are used, but a language isn't\nspecified:\n\n````markdown\n```\n#!/bin/bash\necho Hello world\n```\n````\n\nTo fix this, add a language specifier to the code block:\n\n````markdown\n```bash\n#!/bin/bash\necho Hello world\n```\n````\n\nTo display a code block without syntax highlighting, use:\n\n````markdown\n```text\nPlain text in a code block\n```\n````\n\nYou can configure the `allowed_languages` parameter to specify a list of\nlanguages code blocks could use. Languages are case sensitive. The default value\nis `[]` which means any language specifier is valid.\n\nYou can prevent extra data from being present in the info string of fenced code\nblocks. To do so, set the `language_only` parameter to `true`.\n\n\nInfo strings with leading/trailing whitespace (ex: `js `) or other content (ex:\n`ruby startline=3`) will trigger this rule.\n\nRationale: Specifying a language improves content rendering by using the\ncorrect syntax highlighting for code. More information:\n.\n\n\n\n## `MD041` - First line in a file should be a top-level heading\n\nTags: `headings`\n\nAliases: `first-line-h1`, `first-line-heading`\n\nParameters:\n\n- `allow_preamble`: Allow content before first heading (`boolean`, default\n `false`)\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is intended to ensure documents have a title and is triggered when\nthe first line in a document is not a top-level ([HTML][HTML] `h1`) heading:\n\n```markdown\nThis is a document without a heading\n```\n\nTo fix this, add a top-level heading to the beginning of the document:\n\n```markdown\n# Document Heading\n\nThis is a document with a top-level heading\n```\n\nBecause it is common for projects on GitHub to use an image for the heading of\n`README.md` and that pattern is not well-supported by Markdown, HTML headings\nare also permitted by this rule. For example:\n\n```markdown\n

\n\nThis is a document with a top-level HTML heading\n```\n\nIn some cases, a document's title heading may be preceded by text like a table\nof contents. This is not ideal for accessibility, but can be allowed by setting\nthe `allow_preamble` parameter to `true`.\n\n```markdown\nThis is a document with preamble text\n\n# Document Heading\n```\n\nIf [YAML][YAML] front matter is present and contains a `title` property\n(commonly used with blog posts), this rule will not report a violation. To use a\ndifferent property name in the front matter, specify the text of a [regular\nexpression][RegExp] via the `front_matter_title` parameter. To disable the use\nof front matter by this rule, specify `\"\"` for `front_matter_title`.\n\nThe `level` parameter can be used to change the top-level heading (ex: to `h2`)\nin cases where an `h1` is added externally.\n\nRationale: The top-level heading often acts as the title of a document. More\ninformation: .\n\n[HTML]: https://wikipedia.org/wiki/HTML\n[RegExp]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n[YAML]: https://wikipedia.org/wiki/YAML\n\n\n\n## `MD042` - No empty links\n\nTags: `links`\n\nAliases: `no-empty-links`\n\nThis rule is triggered when an empty link is encountered:\n\n```markdown\n[an empty link]()\n```\n\nTo fix the violation, provide a destination for the link:\n\n```markdown\n[a valid link](https://example.com/)\n```\n\nEmpty fragments will trigger this rule:\n\n```markdown\n[an empty fragment](#)\n\n[an empty link definition][empty]\n\n[empty]: #\n```\n\nBut non-empty fragments will not:\n\n```markdown\n[a valid fragment](#fragment)\n```\n\nEmpty link definitions\n\nRationale: Empty links do not lead anywhere and therefore don't function as\nlinks.\n\n\n\n## `MD043` - Required heading structure\n\nTags: `headings`\n\nAliases: `required-headings`\n\nParameters:\n\n- `headings`: List of headings (`string[]`, default `[]`)\n- `match_case`: Match case of headings (`boolean`, default `false`)\n\nThis rule is triggered when the headings in a file do not match the array of\nheadings passed to the rule. It can be used to enforce a standard heading\nstructure for a set of files.\n\nTo require exactly the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail\n```\n\nSet the `headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"### Detail\"\n]\n```\n\nTo allow optional headings as with the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail (optional)\n## Foot\n### Notes (optional)\n```\n\nUse the special value `\"*\"` meaning \"zero or more unspecified headings\" or the\nspecial value `\"+\"` meaning \"one or more unspecified headings\" and set the\n`headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"*\",\n \"## Foot\",\n \"*\"\n]\n```\n\nTo allow a single required heading to vary as with a project name:\n\n```markdown\n# Project Name\n## Description\n## Examples\n```\n\nUse the special value `\"?\"` meaning \"exactly one unspecified heading\":\n\n```json\n[\n \"?\",\n \"## Description\",\n \"## Examples\"\n]\n```\n\nWhen an error is detected, this rule outputs the line number of the first\nproblematic heading (otherwise, it outputs the last line number of the file).\n\nNote that while the `headings` parameter uses the \"## Text\" ATX heading style\nfor simplicity, a file may use any supported heading style.\n\nBy default, the case of headings in the document is not required to match that\nof `headings`. To require that case match exactly, set the `match_case`\nparameter to `true`.\n\nRationale: Projects may wish to enforce a consistent document structure across\na set of similar content.\n\n\n\n## `MD044` - Proper names should have the correct capitalization\n\nTags: `spelling`\n\nAliases: `proper-names`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `html_elements`: Include HTML elements (`boolean`, default `true`)\n- `names`: List of proper names (`string[]`, default `[]`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when any of the strings in the `names` array do not have\nthe specified capitalization. It can be used to enforce a standard letter case\nfor the names of projects and products.\n\nFor example, the language \"JavaScript\" is usually written with both the 'J' and\n'S' capitalized - though sometimes the 's' or 'j' appear in lower-case. To\nenforce the proper capitalization, specify the desired letter case in the\n`names` array:\n\n```json\n[\n \"JavaScript\"\n]\n```\n\nSometimes a proper name is capitalized differently in certain contexts. In such\ncases, add both forms to the `names` array:\n\n```json\n[\n \"GitHub\",\n \"github.com\"\n]\n```\n\nSet the `code_blocks` parameter to `false` to disable this rule for code blocks\nand spans. Set the `html_elements` parameter to `false` to disable this rule\nfor HTML elements and attributes (such as when using a proper name as part of\na path for `a`/`href` or `img`/`src`).\n\nRationale: Incorrect capitalization of proper names is usually a mistake.\n\n\n\n## `MD045` - Images should have alternate text (alt text)\n\nTags: `accessibility`, `images`\n\nAliases: `no-alt-text`\n\nThis rule reports a violation when an image is missing alternate text (alt text)\ninformation.\n\nAlternate text is commonly specified inline as:\n\n```markdown\n![Alternate text](image.jpg)\n```\n\nOr with reference syntax as:\n\n```markdown\n![Alternate text][ref]\n\n...\n\n[ref]: image.jpg \"Optional title\"\n```\n\nOr with HTML as:\n\n```html\n\"Alternate\n```\n\nNote: If the [HTML `aria-hidden` attribute][aria-hidden] is used to hide the\nimage from assistive technology, this rule does not report a violation:\n\n```html\n\n```\n\nGuidance for writing alternate text is available from the [W3C][w3c],\n[Wikipedia][wikipedia], and [other locations][phase2technology].\n\nRationale: Alternate text is important for accessibility and describes the\ncontent of an image for people who may not be able to see it.\n\n[aria-hidden]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-hidden\n[phase2technology]: https://www.phase2technology.com/blog/no-more-excuses\n[w3c]: https://www.w3.org/WAI/alt/\n[wikipedia]: https://wikipedia.org/wiki/Alt_attribute\n\n\n\n## `MD046` - Code block style\n\nTags: `code`\n\nAliases: `code-block-style`\n\nParameters:\n\n- `style`: Block style (`string`, default `consistent`, values `consistent` /\n `fenced` / `indented`)\n\nThis rule is triggered when unwanted or different code block styles are used in\nthe same document.\n\nIn the default configuration this rule reports a violation for the following\ndocument:\n\n\n\n Some text.\n\n # Indented code\n\n More text.\n\n ```ruby\n # Fenced code\n ```\n\n More text.\n\n\n\nTo fix violations of this rule, use a consistent style (either indenting or code\nfences).\n\nThe configured code block style can be specific (`fenced`, `indented`) or can\nrequire all code blocks match the first code block (`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD047` - Files should end with a single newline character\n\nTags: `blank_lines`\n\nAliases: `single-trailing-newline`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there is not a single newline character at the end\nof a file.\n\nAn example that triggers the rule:\n\n```markdown\n# Heading\n\nThis file ends without a newline.[EOF]\n```\n\nTo fix the violation, add a newline character to the end of the file:\n\n```markdown\n# Heading\n\nThis file ends with a newline.\n[EOF]\n```\n\nRationale: Some programs have trouble with files that do not end with a newline.\n\nMore information: [What's the point in adding a new line to the end of a\nfile?][stack-exchange]\n\n[stack-exchange]: https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file\n\n\n\n## `MD048` - Code fence style\n\nTags: `code`\n\nAliases: `code-fence-style`\n\nParameters:\n\n- `style`: Code fence style (`string`, default `consistent`, values `backtick`\n / `consistent` / `tilde`)\n\nThis rule is triggered when the symbols used in the document for fenced code\nblocks do not match the configured code fence style:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n~~~ruby\n# Fenced code\n~~~\n````\n\nTo fix this issue, use the configured code fence style throughout the\ndocument:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n```ruby\n# Fenced code\n```\n````\n\nThe configured code fence style can be a specific symbol to use (`backtick`,\n`tilde`) or it can require all code fences match the first code fence\n(`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD049` - Emphasis style\n\nTags: `emphasis`\n\nAliases: `emphasis-style`\n\nParameters:\n\n- `style`: Emphasis style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for emphasis do not\nmatch the configured emphasis style:\n\n```markdown\n*Text*\n_Text_\n```\n\nTo fix this issue, use the configured emphasis style throughout the document:\n\n```markdown\n*Text*\n*Text*\n```\n\nThe configured emphasis style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all emphasis matches the first emphasis\n(`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like_this_one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD050` - Strong style\n\nTags: `emphasis`\n\nAliases: `strong-style`\n\nParameters:\n\n- `style`: Strong style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for strong do not\nmatch the configured strong style:\n\n```markdown\n**Text**\n__Text__\n```\n\nTo fix this issue, use the configured strong style throughout the document:\n\n```markdown\n**Text**\n**Text**\n```\n\nThe configured strong style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all strong matches the first strong (`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like__this__one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD051` - Link fragments should be valid\n\nTags: `links`\n\nAliases: `link-fragments`\n\nParameters:\n\n- `ignore_case`: Ignore case of fragments (`boolean`, default `false`)\n- `ignored_pattern`: Pattern for ignoring additional fragments (`string`,\n default ``)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a link fragment does not match any of the fragments\nthat are automatically generated for headings in a document:\n\n```markdown\n# Heading Name\n\n[Link](#fragment)\n```\n\nTo fix this issue, change the link fragment to reference an existing heading's\ngenerated name (see below):\n\n```markdown\n# Heading Name\n\n[Link](#heading-name)\n```\n\nFor consistency, this rule requires fragments to exactly match the [GitHub\nheading algorithm][github-heading-algorithm] which converts letters to\nlowercase. Therefore, the following example is reported as a violation:\n\n```markdown\n# Heading Name\n\n[Link](#Heading-Name)\n```\n\nTo ignore case when comparing fragments with heading names, the `ignore_case`\nparameter can be set to `true`. In this configuration, the previous example is\nnot reported as a violation.\n\nAlternatively, some platforms allow the syntax `{#named-anchor}` to be used\nwithin a heading to provide a specific name (consisting of only lower-case\nletters, numbers, `-`, and `_`):\n\n```markdown\n# Heading Name {#custom-name}\n\n[Link](#custom-name)\n```\n\nAlternatively, any HTML tag with an `id` attribute or an `a` tag with a `name`\nattribute can be used to define a fragment:\n\n```markdown\n\n\n[Link](#bookmark)\n```\n\nAn `a` tag can be useful in scenarios where a heading is not appropriate or for\ncontrol over the text of the fragment identifier.\n\n[HTML links to `#top` scroll to the top of a document][html-top-fragment]. This\nrule allows that syntax (using lower-case for consistency):\n\n```markdown\n[Link](#top)\n```\n\nThis rule also recognizes the custom fragment syntax used by GitHub to highlight\n[specific content in a document][github-linking-to-content].\n\nFor example, this link to line 20:\n\n```markdown\n[Link](#L20)\n```\n\nAnd this link to content starting within line 19 running into line 21:\n\n```markdown\n[Link](#L19C5-L21C11)\n```\n\nSome Markdown generators dynamically create and insert headings when building\ndocuments, for example by combining a fixed prefix like `figure-` and an\nincrementing numeric counter. To ignore such generated fragments, set the\n`ignored_pattern` [regular expression][RegEx] parameter to a pattern that\nmatches (e.g., `^figure-`).\n\nRationale: [GitHub section links][github-section-links] are created\nautomatically for every heading when Markdown content is displayed on GitHub.\nThis makes it easy to link directly to different sections within a document.\nHowever, section links change if headings are renamed or removed. This rule\nhelps identify broken section links within a document.\n\nNote: Section links are **not** part of the CommonMark specification; this rule\nenforces the [GitHub heading algorithm][github-heading-algorithm]:\n\n1. Convert text to lowercase\n2. Remove punctuation characters\n3. Convert spaces to dashes\n4. Append an incrementing integer (as needed for uniqueness)\n5. [URI-encode][encodeURIComponent] the result\n\n[encodeURIComponent]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent\n[github-section-links]: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#section-links\n[github-heading-algorithm]: https://github.com/gjtorikian/html-pipeline/blob/f13a1534cb650ba17af400d1acd3a22c28004c09/lib/html/pipeline/toc_filter.rb\n[github-linking-to-content]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet#linking-to-markdown\n[html-top-fragment]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment\n[RegEx]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n\n\n\n## `MD052` - Reference links and images should use a label that is defined\n\nTags: `images`, `links`\n\nAliases: `reference-links-images`\n\nParameters:\n\n- `ignored_labels`: Ignored link labels (`string[]`, default `[\"x\"]`)\n- `shortcut_syntax`: Include shortcut syntax (`boolean`, default `false`)\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can define it elsewhere and use a label for reference.\nThe reference format is convenient for keeping paragraph text clutter-free\nand makes it easy to reuse the same URL in multiple places.\n\nThere are three kinds of reference links and images:\n\n```markdown\nFull: [text][label]\nCollapsed: [label][]\nShortcut: [label]\n\nFull: ![text][image]\nCollapsed: ![image][]\nShortcut: ![image]\n\n[label]: https://example.com/label\n[image]: https://example.com/image\n```\n\nA link or image renders correctly when the corresponding label is defined, but\ndisplays as text with brackets when the label is not present. By default, this\nrule warns of undefined labels for \"full\" and \"collapsed\" reference syntax but\nnot for \"shortcut\" syntax because it is ambiguous.\n\nThe text `[example]` could be a shortcut link or the text \"example\" in brackets,\nso \"shortcut\" syntax is ignored by default. To include \"shortcut\" syntax, set\nthe `include_shortcut` parameter to `true`. Note that doing so produces warnings\nfor *all* text in the document that *could* be a shortcut. If bracketed text is\nintentional, brackets can be escaped with the `\\` character: `\\[example\\]`.\n\nIf there are link labels that are deliberately unreferenced, they can be ignored\nby setting the `ignored_labels` parameter to the list of strings to ignore. The\ndefault value of this parameter ignores the checkbox syntax used by\n[GitHub Flavored Markdown task list items][gfm-tasklist]:\n\n```markdown\n- [x] Checked task list item\n```\n\n[gfm-tasklist]: https://github.github.com/gfm/#task-list-items-extension-\n\n\n\n## `MD053` - Link and image reference definitions should be needed\n\nTags: `images`, `links`\n\nAliases: `link-image-reference-definitions`\n\nParameters:\n\n- `ignored_definitions`: Ignored definitions (`string[]`, default `[\"//\"]`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can use a label to reference a definition elsewhere in\nthe document. The latter reference format is convenient for keeping paragraph\ntext clutter-free and makes it easy to reuse the same URL in multiple places.\n\nBecause link and image reference definitions are located separately from\nwhere they are used, there are two scenarios where a definition can be\nunnecessary:\n\n1. If a label is not referenced by any link or image in a document, that\n definition is unused and can be deleted.\n2. If a label is defined multiple times in a document, the first definition is\n used and the others can be deleted.\n\nThis rule considers a reference definition to be used if any link or image\nreference has the corresponding label. The \"full\", \"collapsed\", and \"shortcut\"\nformats are all supported.\n\nIf there are reference definitions that are deliberately unreferenced, they can\nbe ignored by setting the `ignored_definitions` parameter to the list of strings\nto ignore. The default value of this parameter ignores the following convention\nfor adding non-HTML comments to Markdown:\n\n```markdown\n[//]: # (This behaves like a comment)\n```\n\n\n\n## `MD054` - Link and image style\n\nTags: `images`, `links`\n\nAliases: `link-image-style`\n\nParameters:\n\n- `autolink`: Allow autolinks (`boolean`, default `true`)\n- `collapsed`: Allow collapsed reference links and images (`boolean`, default\n `true`)\n- `full`: Allow full reference links and images (`boolean`, default `true`)\n- `inline`: Allow inline links and images (`boolean`, default `true`)\n- `shortcut`: Allow shortcut reference links and images (`boolean`, default\n `true`)\n- `url_inline`: Allow URLs as inline links (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source at\nthe time of use or can use a label to reference a definition elsewhere in the\ndocument. The three reference formats are convenient for keeping paragraph text\nclutter-free and make it easy to reuse the same URL in multiple places.\n\nBy default, this rule allows all link/image styles.\n\nSetting the `autolink` parameter to `false` disables autolinks:\n\n```markdown\n\n```\n\nSetting the `inline` parameter to `false` disables inline links and images:\n\n```markdown\n[link](https://example.com)\n\n![image](https://example.com)\n```\n\nSetting the `full` parameter to `false` disables full reference links and\nimages:\n\n```markdown\n[link][url]\n\n![image][url]\n\n[url]: https://example.com\n```\n\nSetting the `collapsed` parameter to `false` disables collapsed reference links\nand images:\n\n```markdown\n[url][]\n\n![url][]\n\n[url]: https://example.com\n```\n\nSetting the `shortcut` parameter to `false` disables shortcut reference links\nand images:\n\n```markdown\n[url]\n\n![url]\n\n[url]: https://example.com\n```\n\nTo fix violations of this rule, change the link or image to use an allowed\nstyle. This rule can automatically fix violations when a link or image can be\nconverted to the `inline` style (preferred) or a link can be converted to the\n`autolink` style (which does not support images and must be an absolute URL).\nThis rule does *not* fix scenarios that require converting a link or image to\nthe `full`, `collapsed`, or `shortcut` reference styles because that involves\nnaming the reference and determining where to insert it in the document.\n\nSetting the `url_inline` parameter to `false` prevents the use of inline links\nwith the same absolute URL text/destination and no title because such links can\nbe converted to autolinks:\n\n```markdown\n[https://example.com](https://example.com)\n```\n\nTo fix `url_inline` violations, use the simpler autolink syntax instead:\n\n```markdown\n\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\nAutolinks are concise, but appear as URLs which can be long and confusing.\nInline links and images can include descriptive text, but take up more space in\nMarkdown form. Reference links and images can be easier to read and manipulate\nin Markdown form, but require a separate link reference definition.\n\n\n\n## `MD055` - Table pipe style\n\nTags: `table`\n\nAliases: `table-pipe-style`\n\nParameters:\n\n- `style`: Table pipe style (`string`, default `consistent`, values\n `consistent` / `leading_and_trailing` / `leading_only` /\n `no_leading_or_trailing` / `trailing_only`)\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-055]\nis inconsistent about its use of leading and trailing pipe characters (`|`).\n\nBy default (`consistent` style), the header row of the first table in a document\nis used to determine the style that is enforced for every table in the document.\nA specific style can be used instead (`leading_and_trailing`, `leading_only`,\n`no_leading_or_trailing`, `trailing_only`).\n\nThis table's header row has leading and trailing pipes, but its delimiter row is\nmissing the trailing pipe and its first row of cells is missing the leading\npipe:\n\n```markdown\n| Header | Header |\n| ------ | ------\n Cell | Cell |\n```\n\nTo fix these issues, make sure there is a pipe character at the beginning and\nend of every row:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and may also\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table\n```\n\nRationale: Some parsers have difficulty with tables that are missing their\nleading or trailing pipe characters. The use of leading/trailing pipes can also\nhelp provide visual clarity.\n\n[gfm-table-055]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD056` - Table column count\n\nTags: `table`\n\nAliases: `table-column-count`\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-056]\ndoes not have the same number of cells in every row.\n\nThis table's second data row has too few cells and its third data row has too\nmany cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell |\n| Cell | Cell | Cell |\n```\n\nTo fix these issues, ensure every row has the same number of cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell | Cell |\n| Cell | Cell |\n```\n\nNote that a table's header row and its delimiter row must have the same number\nof cells or it will not be recognized as a table (per specification).\n\nRationale: Extra cells in a row are usually not shown, so their data is lost.\nMissing cells in a row create holes in the table and suggest an omission.\n\n[gfm-table-056]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD058` - Tables should be surrounded by blank lines\n\nTags: `table`\n\nAliases: `blanks-around-tables`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when tables are either not preceded or not followed by a\nblank line:\n\n```markdown\nSome text\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n> Blockquote\n```\n\nTo fix violations of this rule, ensure that all tables have a blank line both\nbefore and after (except when the table is at the very beginning or end of the\ndocument):\n\n```markdown\nSome text\n\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n\n> Blockquote\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and will not\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table and the next line is blank\n\nSome text\n```\n\nRationale: In addition to aesthetic reasons, some parsers will incorrectly parse\ntables that don't have blank lines before and after them.\n\n\n\n## `MD059` - Link text should be descriptive\n\nTags: `accessibility`, `links`\n\nAliases: `descriptive-link-text`\n\nParameters:\n\n- `prohibited_texts`: Prohibited link texts (`string[]`, default `[\"click\n here\",\"here\",\"link\",\"more\"]`)\n\nThis rule is triggered when a link has generic text like `[click here](...)` or\n`[link](...)`.\n\nLink text should be descriptive and communicate the purpose of the link (e.g.,\n`[Download the budget document](...)` or `[CommonMark Specification](...)`).\nThis is especially important for screen readers which sometimes present links\nwithout context.\n\nBy default, this rule prohibits a small number of common English words/phrases.\nTo customize that list of words/phrases, set the `prohibited_texts` parameter to\nan `Array` of `string`s.\n\nNote: For languages other than English, use the `prohibited_texts` parameter to\ncustomize the list for that language. It is *not* a goal for this rule to have\ntranslations for every language.\n\nNote: This rule checks Markdown links; HTML links are ignored.\n\nMore information:\n\n- \n- \n\n\n\n## `MD060` - Table column style\n\nTags: `table`\n\nAliases: `table-column-style`\n\nParameters:\n\n- `aligned_delimiter`: Aligned delimiter columns (`boolean`, default `false`)\n- `style`: Table column style (`string`, default `any`, values `aligned` /\n `any` / `compact` / `tight`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the column separator pipe characters (`|`) of a\n[GitHub Flavored Markdown table][gfm-table-060] are used inconsistently.\n\nThis rule recognizes three table column styles based on popular use.\n\nStyle `aligned` ensures pipe characters are vertically aligned:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nThe `aligned` style ignores cell content, so the following is also valid:\n\n```markdown\n| Character | Meaning |\n|-----------|---------|\n| Y | Yes |\n| N | No |\n```\n\nStyle `compact` avoids extra padding with a single space around cell content:\n\n```markdown\n| Character | Meaning |\n| --- | --- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` uses no padding at all for cell content:\n\n```markdown\n|Character|Meaning|\n|---|---|\n|Y|Yes|\n|N|No|\n```\n\nWhen this rule's `style` parameter is set to `aligned`, `compact`, or `tight`,\nevery table must match the corresponding pattern and any violations will be\nreported. By default, or when the `any` style is used, each table is analyzed to\nsee if it satisfies any supported style. If so, no violations are reported. If\nnot, violations are be reported for whichever style would produce the *fewest*\nissues (i.e., whichever style is the closest match).\n\nSetting the `aligned_delimiter` parameter to `true` requires pipe characters in\nthe delimiter row to align with those in the header row. This can be used with\n`compact` and `tight` tables to make the header text more obvious. (It's already\nrequired for tables with style `aligned`.)\n\nStyle `compact` with `aligned_delimiter`:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` with `aligned_delimiter`:\n\n```markdown\n|Character|Meaning|\n|---------|-------|\n|Y|Yes|\n|N|No|\n```\n\nViolations for styles `compact` and `tight` are simple/independent and can be\nfixed automatically. However, fixing even single violations for style `aligned`\nmay require modifying the entire table, and therefore are not automatic:\n\n```markdown\n|Alpha |Delta|\n|------|-----|\n|Charlie|Beta|\n```\n\n**Note**: This rule does not require leading/trailing pipe characters, so this\nis also a valid table for style `compact`:\n\n```markdown\nCharacter | Meaning\n--- | ---\nY | Yes\nN | No\n```\n\n**Note**: Pipe alignment for the `aligned` style is based on visual appearance\nand not character count. Because editors typically render [emoji][emoji] and\n[CJK characters][cjk-characters] at *twice* the width of\n[Latin characters][latin-script], this rule takes that into account for tables\nusing the `aligned` style. The following table is correctly formatted and will\nappear aligned in most editors and monospaced fonts:\n\n\n\n\n```markdown\n| Response | Emoji |\n| -------- | ----- |\n| Yes | ✅ |\n| No | ❎ |\n```\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n[cjk-characters]: https://wikipedia.org/wiki/CJK_characters\n[emoji]: https://wikipedia.org/wiki/Emoji\n[gfm-table-060]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n[latin-script]: https://wikipedia.org/wiki/Latin_script\n\n\n"},"files":{"doc/Rules.md":"# Rules\n\nThis document contains a description of all rules, what they are checking for,\nas well as examples of documents that break the rule and corrected\nversions of the examples.\n\n\n\n## `MD001` - Heading levels should only increment by one level at a time\n\nTags: `headings`\n\nAliases: `heading-increment`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n\nThis rule is triggered when you skip heading levels in a Markdown document, for\nexample:\n\n```markdown\n# Heading 1\n\n### Heading 3\n\nWe skipped out a 2nd level heading in this document\n```\n\nWhen using multiple heading levels, nested headings should increase by only one\nlevel at a time:\n\n```markdown\n# Heading 1\n\n## Heading 2\n\n### Heading 3\n\n#### Heading 4\n\n## Another Heading 2\n\n### Another Heading 3\n```\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation if the actual first\nheading is not a level 2 heading. To use a different property name in the\nfront matter, specify the text of a regular expression via the\n`front_matter_title` parameter. To disable the use of front matter by this\nrule, specify `\"\"` for `front_matter_title`. When front matter is not present,\nthe first heading can be any level.\n\nRationale: Headings represent the structure of a document and can be confusing\nwhen skipped - especially for accessibility scenarios. More information:\n.\n\n\n\n## `MD003` - Heading style\n\nTags: `headings`\n\nAliases: `heading-style`\n\nParameters:\n\n- `style`: Heading style (`string`, default `consistent`, values `atx` /\n `atx_closed` / `consistent` / `setext` / `setext_with_atx` /\n `setext_with_atx_closed`)\n\nThis rule is triggered when different heading styles are used in the same\ndocument:\n\n```markdown\n# ATX style H1\n\n## Closed ATX style H2 ##\n\nSetext style H1\n===============\n```\n\nTo fix the issue, use consistent heading styles throughout the document:\n\n```markdown\n# ATX style H1\n\n## ATX style H2\n```\n\nThe `setext_with_atx` and `setext_with_atx_closed` settings allow ATX-style\nheadings of level 3 or more in documents with setext-style headings (which only\nsupport level 1 and 2 headings):\n\n```markdown\nSetext style H1\n===============\n\nSetext style H2\n---------------\n\n### ATX style H3\n```\n\nNote: The configured heading style can be a specific style to require (`atx`,\n`atx_closed`, `setext`, `setext_with_atx`, `setext_with_atx_closed`), or can\nrequire that all heading styles match the first heading style via `consistent`.\n\nNote: The placement of a horizontal rule directly below a line of text can\ntrigger this rule by turning that text into a level 2 setext-style heading:\n\n```markdown\nA line of text followed by a horizontal rule becomes a heading\n---\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD004` - Unordered list style\n\nTags: `bullet`, `ul`\n\nAliases: `ul-style`\n\nParameters:\n\n- `style`: List style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `dash` / `plus` / `sublist`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for unordered\nlist items do not match the configured unordered list style:\n\n```markdown\n* Item 1\n+ Item 2\n- Item 3\n```\n\nTo fix this issue, use the configured style for list items throughout the\ndocument:\n\n```markdown\n* Item 1\n* Item 2\n* Item 3\n```\n\nThe configured list style can ensure all list styling is a specific symbol\n(`asterisk`, `plus`, `dash`), ensure each sublist has a consistent symbol that\ndiffers from its parent list (`sublist`), or ensure all list styles match the\nfirst list style (`consistent`).\n\nFor example, the following is valid for the `sublist` style because the\nouter-most indent uses asterisk, the middle indent uses plus, and the inner-most\nindent uses dash:\n\n```markdown\n* Item 1\n + Item 2\n - Item 3\n + Item 4\n* Item 4\n + Item 5\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD005` - Inconsistent indentation for list items at the same level\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `list-indent`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are parsed as being at the same level,\nbut don't have the same indentation:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * A misaligned item\n```\n\nUsually, this rule will be triggered because of a typo. Correct the indentation\nfor the list to fix it:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * Nested Item 3\n```\n\nSequentially-ordered list markers are usually left-aligned such that all items\nhave the same starting column:\n\n```markdown\n...\n8. Item\n9. Item\n10. Item\n11. Item\n...\n```\n\nThis rule also supports right-alignment of list markers such that all items have\nthe same ending column:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n...\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD007` - Unordered list indentation\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `ul-indent`\n\nParameters:\n\n- `indent`: Spaces for indent (`integer`, default `2`)\n- `start_indent`: Spaces for first level indent (when start_indented is set)\n (`integer`, default `2`)\n- `start_indented`: Whether to indent the first level of the list (`boolean`,\n default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are not indented by the configured\nnumber of spaces (default: 2).\n\nExample:\n\n```markdown\n* List item\n * Nested list item indented by 3 spaces\n```\n\nCorrected Example:\n\n```markdown\n* List item\n * Nested list item indented by 2 spaces\n```\n\nNote: This rule applies to a sublist only if its parent lists are all also\nunordered (otherwise, extra indentation of ordered lists interferes with the\nrule).\n\nThe `start_indented` parameter allows the first level of lists to be indented by\nthe configured number of spaces rather than starting at zero. The `start_indent`\nparameter allows the first level of lists to be indented by a different number\nof spaces than the rest (ignored when `start_indented` is not set).\n\nRationale: Indenting by 2 spaces allows the content of a nested list to be in\nline with the start of the content of the parent list when a single space is\nused after the list marker. Indenting by 4 spaces is consistent with code blocks\nand simpler for editors to implement. Additionally, this can be a compatibility\nissue for other Markdown parsers, which require 4-space indents. More\ninformation: [Markdown Style Guide][markdown-style-guide].\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n[markdown-style-guide]: https://cirosantilli.com/markdown-style-guide#indentation-of-content-inside-lists\n\n\n\n## `MD009` - Trailing spaces\n\nTags: `whitespace`\n\nAliases: `no-trailing-spaces`\n\nParameters:\n\n- `br_spaces`: Spaces for line break (`integer`, default `2`)\n- `code_blocks`: Include code blocks (`boolean`, default `false`)\n- `list_item_empty_lines`: Allow spaces for empty lines in list items\n (`boolean`, default `false`)\n- `strict`: Include unnecessary breaks (`boolean`, default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any lines that end with unexpected whitespace. To fix\nthis, remove the trailing space from the end of the line.\n\nThe `br_spaces` parameter allows an exception to this rule for a specific number\nof trailing spaces, typically used to insert an explicit line break. The default\nvalue allows 2 spaces to indicate a hard break (\\
element). (You must set\n`br_spaces` to a value >= 2 for this parameter to take effect. Setting\n`br_spaces` to 1 behaves the same as 0, disallowing any trailing spaces.)\n\nBy default, trailing space is allowed in indented and fenced code blocks because\nsome programming languages require that. To report such instances, set the\n`code_blocks` parameter to `true`.\n\nBy default, this rule will not trigger when the allowed number of spaces is\nused, even when it doesn't create a hard break (for example, at the end of a\nparagraph). To report such instances, set the `strict` parameter to `true`.\n\n```markdown\nText text text\ntext[2 spaces]\n```\n\nUsing spaces to indent blank lines inside a list item is usually not necessary,\nbut some parsers require it. Set the `list_item_empty_lines` parameter to `true`\nto allow this (even when `strict` is `true`):\n\n```markdown\n- list item text\n [2 spaces]\n list item text\n```\n\nRationale: Except when being used to create a line break, trailing whitespace\nhas no purpose and does not affect the rendering of content.\n\n\n\n## `MD010` - Hard tabs\n\nTags: `hard_tab`, `whitespace`\n\nAliases: `no-hard-tabs`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `ignore_code_languages`: Fenced code languages to ignore (`string[]`, default\n `[]`)\n- `spaces_per_tab`: Number of spaces for each hard tab (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered by any lines that contain hard tab characters instead\nof using spaces for indentation. To fix this, replace any hard tab characters\nwith spaces instead.\n\nExample:\n\n\n\n```markdown\nSome text\n\n\t* hard tab character used to indent the list item\n```\n\n\n\nCorrected example:\n\n```markdown\nSome text\n\n * Spaces used to indent the list item instead\n```\n\nYou have the option to exclude this rule for code blocks and spans. To do so,\nset the `code_blocks` parameter to `false`. Code blocks and spans are included\nby default since handling of tabs by Markdown tools can be inconsistent (e.g.,\nusing 4 vs. 8 spaces).\n\nWhen code blocks are scanned (e.g., by default or if `code_blocks` is `true`),\nthe `ignore_code_languages` parameter can be set to a list of languages that\nshould be ignored (i.e., hard tabs will be allowed, though not required). This\nmakes it easier for documents to include code for languages that require hard\ntabs.\n\nBy default, violations of this rule are fixed by replacing the tab with 1 space\ncharacter. To use a different number of spaces, set the `spaces_per_tab`\nparameter to the desired value.\n\nRationale: Hard tabs are often rendered inconsistently by different editors and\ncan be harder to work with than spaces.\n\nMore information:\n\n- \n- \n\n\n\n## `MD011` - Reversed link syntax\n\nTags: `links`\n\nAliases: `no-reversed-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when text that appears to be a link is encountered, but\nwhere the syntax appears to have been reversed (the `[]` and `()` are\nreversed):\n\n```markdown\n(Incorrect link syntax)[https://www.example.com/]\n```\n\nTo fix this, swap the `[]` and `()` around:\n\n```markdown\n[Correct link syntax](https://www.example.com/)\n```\n\nNote: [Markdown Extra](https://wikipedia.org/wiki/Markdown_Extra)-style\nfootnotes do not trigger this rule:\n\n```markdown\nFor (example)[^1]\n```\n\nRationale: Reversed links are not rendered as usable links.\n\n\n\n## `MD012` - Multiple consecutive blank lines\n\nTags: `blank_lines`, `whitespace`\n\nAliases: `no-multiple-blanks`\n\nParameters:\n\n- `maximum`: Consecutive blank lines (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are multiple consecutive blank lines in the\ndocument:\n\n```markdown\nSome text here\n\n\nSome more text here\n```\n\nTo fix this, delete the offending lines:\n\n```markdown\nSome text here\n\nSome more text here\n```\n\nNote: this rule will not be triggered if there are multiple consecutive blank\nlines inside code blocks.\n\nNote: The `maximum` parameter can be used to configure the maximum number of\nconsecutive blank lines.\n\nRationale: Except in a code block, blank lines serve no purpose and do not\naffect the rendering of content.\n\n\n\n## `MD013` - Line length\n\nTags: `line_length`\n\nAliases: `line-length`\n\nParameters:\n\n- `code_block_line_length`: Number of characters for code blocks (`integer`,\n default `80`)\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `heading_line_length`: Number of characters for headings (`integer`, default\n `80`)\n- `headings`: Include headings (`boolean`, default `true`)\n- `line_length`: Number of characters (`integer`, default `80`)\n- `stern`: Stern length checking (`boolean`, default `false`)\n- `strict`: Strict length checking (`boolean`, default `false`)\n- `tables`: Include tables (`boolean`, default `true`)\n\nThis rule is triggered when there are lines that are longer than the\nconfigured `line_length` (default: 80 characters). To fix this, split the line\nup into multiple lines. To set a different maximum length for headings, use\n`heading_line_length`. To set a different maximum length for code blocks, use\n`code_block_line_length`\n\nThis rule has an exception when there is no whitespace beyond the configured\nline length. This allows you to include items such as long URLs without being\nforced to break them in the middle. To disable this exception, set the `strict`\nparameter to `true` and an issue will be reported when any line is too long. To\nwarn for lines that are too long and could be fixed but allow long lines\nwithout spaces, set the `stern` parameter to `true`.\n\nFor example (assuming normal behavior):\n\n```markdown\nIF THIS LINE IS THE MAXIMUM LENGTH\nThis line is okay because there are-no-spaces-beyond-that-length\nThis line is a violation because there are spaces beyond that length\nThis-line-is-okay-because-there-are-no-spaces-anywhere-within\n```\n\nIn `strict` mode, the last three lines above are all violations. In `stern`\nmode, the middle two lines above are both violations, but the last is okay.\n\nYou have the option to exclude this rule for code blocks, tables, or headings.\nTo do so, set the `code_blocks`, `tables`, or `headings` parameter(s) to false.\n\nCode blocks are included in this rule by default since it is often a\nrequirement for document readability, and tentatively compatible with code\nrules. Still, some languages do not lend themselves to short lines.\n\nLines with link/image reference definitions and standalone lines (i.e., not part\nof a paragraph) with only a link/image (possibly using (strong) emphasis) are\nalways exempted from this rule (even in `strict` mode) because there is often no\nway to split such lines without breaking the URL.\n\nRationale: Extremely long lines can be difficult to work with in some editors.\nMore information: .\n\n\n\n## `MD014` - Dollar signs used before commands without showing output\n\nTags: `code`\n\nAliases: `commands-show-output`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are code blocks showing shell commands to be\ntyped, and *all* of the shell commands are preceded by dollar signs ($):\n\n\n\n```markdown\n$ ls\n$ cat foo\n$ less bar\n```\n\n\n\nThe dollar signs are unnecessary in this situation, and should not be\nincluded:\n\n```markdown\nls\ncat foo\nless bar\n```\n\nShowing output for commands preceded by dollar signs does not trigger this rule:\n\n```markdown\n$ ls\nfoo bar\n$ cat foo\nHello world\n$ cat bar\nbaz\n```\n\nBecause some commands do not produce output, it is not a violation if *some*\ncommands do not have output:\n\n```markdown\n$ mkdir test\nmkdir: created directory 'test'\n$ ls test\n```\n\nRationale: It is easier to copy/paste and less noisy if the dollar signs\nare omitted when they are not needed. See\n\nfor more information.\n\n\n\n## `MD018` - No space after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-missing-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing after the hash characters\nin an atx style heading:\n\n```markdown\n#Heading 1\n\n##Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD019` - Multiple spaces after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-multiple-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in an atx style heading:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD020` - No space inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-missing-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing inside the hash characters\nin a closed atx style heading:\n\n```markdown\n#Heading 1#\n\n##Heading 2##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading is missing spaces.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD021` - Multiple spaces inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-multiple-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in a closed atx style heading:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading contains multiple\nspaces.\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD022` - Headings should be surrounded by blank lines\n\nTags: `blank_lines`, `headings`\n\nAliases: `blanks-around-headings`\n\nParameters:\n\n- `include_front_matter`: Include front matter content (`boolean`, default\n `false`)\n- `lines_above`: Blank lines above heading (`integer|integer[]`, default `1`)\n- `lines_below`: Blank lines below heading (`integer|integer[]`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when headings (any style) are either not preceded or not\nfollowed by at least one blank line:\n\n```markdown\n# Heading 1\nSome text\n\nSome more text\n## Heading 2\n```\n\nTo fix this, ensure that all headings have a blank line both before and after\n(except where the heading is at the beginning or end of the document):\n\n```markdown\n# Heading 1\n\nSome text\n\nSome more text\n\n## Heading 2\n```\n\nThe `lines_above` and `lines_below` parameters can be used to specify a\ndifferent number of blank lines (including `0`) above or below each heading.\nIf the value `-1` is used for either parameter, any number of blank lines is\nallowed. To customize the number of lines above or below each heading level\nindividually, specify a `number[]` where values correspond to heading levels\n1-6 (in order).\n\nNotes: If `lines_above` or `lines_below` are configured to require more than one\nblank line, [MD012/no-multiple-blanks](md012.md) should also be customized. This\nrule checks for *at least* as many blank lines as specified; any extra blank\nlines are ignored.\n\nBy default, [YAML](https://wikipedia.org/wiki/YAML) front matter is ignored, so\nthe following document reports no violations:\n\n```markdown\n---\ntitle: Title\n---\n## Heading\n```\n\nTo require the configured number of blank lines between front matter content and\na document's first heading, set the `include_front_matter` parameter to `true`.\n\nRationale: Aside from aesthetic reasons, some parsers, including `kramdown`,\nwill not parse headings that don't have a blank line before, and will parse them\nas regular text.\n\n\n\n## `MD023` - Headings must start at the beginning of the line\n\nTags: `headings`, `spaces`\n\nAliases: `heading-start-left`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a heading is indented by one or more spaces:\n\n```markdown\nSome text\n\n # Indented heading\n```\n\nTo fix this, ensure that all headings start at the beginning of the line:\n\n```markdown\nSome text\n\n# Heading\n```\n\nNote that scenarios like block quotes \"indent\" the start of the line, so the\nfollowing is also correct:\n\n```markdown\n> # Heading in Block Quote\n```\n\nRationale: Headings that don't start at the beginning of the line will not be\nparsed as headings, and will instead appear as regular text.\n\n\n\n## `MD024` - Multiple headings with the same content\n\nTags: `headings`\n\nAliases: `no-duplicate-heading`\n\nParameters:\n\n- `siblings_only`: Only check sibling headings (`boolean`, default `false`)\n\nThis rule is triggered if there are multiple headings in the document that have\nthe same text:\n\n```markdown\n# Some text\n\n## Some text\n```\n\nTo fix this, ensure that the content of each heading is different:\n\n```markdown\n# Some text\n\n## Some more text\n```\n\nIf the parameter `siblings_only` is set to `true`, duplication is allowed for\nheadings with different parents (as is common in changelogs):\n\n```markdown\n# Change log\n\n## 1.0.0\n\n### Features\n\n## 2.0.0\n\n### Features\n```\n\nRationale: Some Markdown parsers generate anchors for headings based on the\nheading name; headings with the same content can cause problems with that.\n\n\n\n## `MD025` - Multiple top-level headings in the same document\n\nTags: `headings`\n\nAliases: `single-h1`, `single-title`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is triggered when a top-level heading is in use (the first line of\nthe file is an h1 heading), and more than one h1 heading is in use in the\ndocument:\n\n```markdown\n# Top level heading\n\n# Another top-level heading\n```\n\nTo fix, structure your document so there is a single h1 heading that is\nthe title for the document. Subsequent headings must be\nlower-level headings (h2, h3, etc.):\n\n```markdown\n# Title\n\n## Heading\n\n## Another heading\n```\n\nNote: The `level` parameter can be used to change the top-level (ex: to h2) in\ncases where an h1 is added externally.\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation for any subsequent\ntop-level headings. To use a different property name in the front matter,\nspecify the text of a regular expression via the `front_matter_title` parameter.\nTo disable the use of front matter by this rule, specify `\"\"` for\n`front_matter_title`.\n\nRationale: A top-level heading is an h1 on the first line of the file, and\nserves as the title for the document. If this convention is in use, then there\ncan not be more than one title for the document, and the entire document should\nbe contained within this heading.\n\n\n\n## `MD026` - Trailing punctuation in heading\n\nTags: `headings`\n\nAliases: `no-trailing-punctuation`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!。，；：！`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any heading that has one of the specified normal or\nfull-width punctuation characters as the last character in the line:\n\n```markdown\n# This is a heading.\n```\n\nTo fix this, remove the trailing punctuation:\n\n```markdown\n# This is a heading\n```\n\nNote: The `punctuation` parameter can be used to specify what characters count\nas punctuation at the end of a heading. For example, you can change it to\n`\".,;:\"` to allow headings that end with an exclamation point. `?` is\nallowed by default because of how common it is in headings of FAQ-style\ndocuments. Setting the `punctuation` parameter to `\"\"` allows all characters -\nand is equivalent to disabling the rule.\n\nNote: The trailing semicolon of [HTML entity references][html-entity-references]\nlike `©`, `©`, and `©` is ignored by this rule.\n\nRationale: Headings are not meant to be full sentences. More information:\n[Punctuation at the end of headers][end-punctuation].\n\n[end-punctuation]: https://cirosantilli.com/markdown-style-guide#punctuation-at-the-end-of-headers\n[html-entity-references]: https://wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references\n\n\n\n## `MD027` - Multiple spaces after blockquote symbol\n\nTags: `blockquote`, `indentation`, `whitespace`\n\nAliases: `no-multiple-space-blockquote`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when blockquotes have more than one space after the\nblockquote (`>`) symbol:\n\n```markdown\n> This is a blockquote with bad indentation\n> there should only be one.\n```\n\nTo fix, remove any extraneous space:\n\n```markdown\n> This is a blockquote with correct\n> indentation.\n```\n\nInferring intended list indentation within a blockquote can be challenging;\nsetting the `list_items` parameter to `false` disables this rule for ordered\nand unordered list items.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD028` - Blank line inside blockquote\n\nTags: `blockquote`, `whitespace`\n\nAliases: `no-blanks-blockquote`\n\nThis rule is triggered when two blockquote blocks are separated by nothing\nbut a blank line:\n\n```markdown\n> This is a blockquote\n> which is immediately followed by\n\n> this blockquote. In some cases,\n> these may be merged into one blockquote.\n```\n\nTo fix this, ensure that consecutive blockquotes have text (or an HTML comment)\nin between:\n\n```markdown\n> This is a blockquote.\n\nThis is paragraph text.\n\n> This is a second blockquote.\n\n\n\n> This is a third blockquote.\n```\n\nIf they are meant to be a single quote, add the blockquote symbol at the\nbeginning of the blank line:\n\n```markdown\n> This is a blockquote.\n>\n> This is the same blockquote.\n```\n\nRationale: Some Markdown parsers will treat two blockquotes separated by one\nor more blank lines as the same blockquote, while others will treat them as\nseparate blockquotes.\n\n\n\n## `MD029` - Ordered list item prefix\n\nTags: `ol`\n\nAliases: `ol-prefix`\n\nParameters:\n\n- `style`: List style (`string`, default `one_or_ordered`, values `one` /\n `one_or_ordered` / `ordered` / `zero`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for ordered lists that do not either start with '1.' or\ndo not have a prefix that increases in numerical order (depending on the\nconfigured style). The less-common pattern of using '0.' as a first prefix or\nfor all prefixes is also supported.\n\nExample valid list if the style is configured as 'one':\n\n```markdown\n1. Do this.\n1. Do that.\n1. Done.\n```\n\nExamples of valid lists if the style is configured as 'ordered':\n\n```markdown\n1. Do this.\n2. Do that.\n3. Done.\n```\n\n```markdown\n0. Do this.\n1. Do that.\n2. Done.\n```\n\nAll three examples are valid when the style is configured as 'one_or_ordered'.\n\nExample valid list if the style is configured as 'zero':\n\n```markdown\n0. Do this.\n0. Do that.\n0. Done.\n```\n\nExample invalid list for all styles:\n\n```markdown\n1. Do this.\n3. Done.\n```\n\nThis rule supports 0-prefixing list items for uniform indentation and will\npreserve that when fixing:\n\n```markdown\n...\n08. Item\n09. Item\n10. Item\n11. Item\n```\n\nWhen list items appear to be right-aligned, fixes will maintain that alignment:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n```\n\nNote: This rule will report violations for cases like the following where an\nimproperly-indented code block (or similar) appears between two list items and\n\"breaks\" the list in two:\n\n\n\n~~~markdown\n1. First list\n\n```text\nCode block\n```\n\n1. Second list\n~~~\n\nThe fix is to indent the code block so it becomes part of the preceding list\nitem as intended:\n\n~~~markdown\n1. First list\n\n ```text\n Code block\n ```\n\n2. Still first list\n~~~\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD030` - Spaces after list markers\n\nTags: `ol`, `ul`, `whitespace`\n\nAliases: `list-marker-space`\n\nParameters:\n\n- `ol_multi`: Spaces for multi-line ordered list items (`integer`, default `1`)\n- `ol_single`: Spaces for single-line ordered list items (`integer`, default\n `1`)\n- `ul_multi`: Spaces for multi-line unordered list items (`integer`, default\n `1`)\n- `ul_single`: Spaces for single-line unordered list items (`integer`, default\n `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule checks for the number of spaces between a list marker (e.g. '`-`',\n'`*`', '`+`' or '`1.`') and the text of the list item.\n\nThe number of spaces checked for depends on the document style in use, but the\ndefault is 1 space after any list marker:\n\n```markdown\n* Foo\n* Bar\n* Baz\n\n1. Foo\n1. Bar\n1. Baz\n\n1. Foo\n * Bar\n1. Baz\n```\n\nA document style may change the number of spaces after unordered list items\nand ordered list items independently, as well as based on whether the content\nof every item in the list consists of a single paragraph or multiple\nparagraphs (including sub-lists and code blocks).\n\nFor example, the style guide at\n\nspecifies that 1 space after the list marker should be used if every item in\nthe list fits within a single paragraph, but to use 2 or 3 spaces (for ordered\nand unordered lists respectively) if there are multiple paragraphs of content\ninside the list:\n\n```markdown\n* Foo\n* Bar\n* Baz\n```\n\nvs.\n\n```markdown\n* Foo\n\n Second paragraph\n\n* Bar\n```\n\nor\n\n```markdown\n1. Foo\n\n Second paragraph\n\n1. Bar\n```\n\nTo fix this, ensure the correct number of spaces are used after the list marker\nfor your selected document style.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n\n\n## `MD031` - Fenced code blocks should be surrounded by blank lines\n\nTags: `blank_lines`, `code`\n\nAliases: `blanks-around-fences`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when fenced code blocks are either not preceded or not\nfollowed by a blank line:\n\n````markdown\nSome text\n```\nCode block\n```\n\n```\nAnother code block\n```\nSome more text\n````\n\nTo fix this, ensure that all fenced code blocks have a blank line both before\nand after (except where the block is at the beginning or end of the document):\n\n````markdown\nSome text\n\n```\nCode block\n```\n\n```\nAnother code block\n```\n\nSome more text\n````\n\nSet the `list_items` parameter to `false` to disable this rule for list items.\nDisabling this behavior for lists can be useful if it is necessary to create a\n[tight](https://spec.commonmark.org/0.29/#tight) list containing a code fence.\n\nRationale: Aside from aesthetic reasons, some parsers, including kramdown, will\nnot parse fenced code blocks that don't have blank lines before and after them.\n\n\n\n## `MD032` - Lists should be surrounded by blank lines\n\nTags: `blank_lines`, `bullet`, `ol`, `ul`\n\nAliases: `blanks-around-lists`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when lists (of any kind) are either not preceded or not\nfollowed by a blank line:\n\n```markdown\nSome text\n* List item\n* List item\n\n1. List item\n2. List item\n***\n```\n\nIn the first case above, text immediately precedes the unordered list. In the\nsecond case above, a thematic break immediately follows the ordered list. To fix\nviolations of this rule, ensure that all lists have a blank line both before and\nafter (except when the list is at the very beginning or end of the document):\n\n```markdown\nSome text\n\n* List item\n* List item\n\n1. List item\n2. List item\n\n***\n```\n\nNote that the following case is **not** a violation of this rule:\n\n```markdown\n1. List item\n More item 1\n2. List item\nMore item 2\n```\n\nAlthough it is not indented, the text \"More item 2\" is referred to as a\n[lazy continuation line][lazy-continuation] and considered part of the second\nlist item.\n\nRationale: In addition to aesthetic reasons, some parsers, including kramdown,\nwill not parse lists that don't have blank lines before and after them.\n\n[lazy-continuation]: https://spec.commonmark.org/0.30/#lazy-continuation-line\n\n\n\n## `MD033` - Inline HTML\n\nTags: `html`\n\nAliases: `no-inline-html`\n\nParameters:\n\n- `allowed_elements`: Allowed elements (`string[]`, default `[]`)\n- `table_allowed_elements`: Allowed elements in tables (`string[]`, default\n `[]`)\n\nThis rule is triggered whenever raw HTML is used in a Markdown document:\n\n```markdown\n

Inline HTML heading

\n```\n\nTo fix this, use 'pure' Markdown instead of including raw HTML:\n\n```markdown\n# Markdown heading\n```\n\nTo allow specific HTML elements anywhere in Markdown content, set the\n`allowed_elements` parameter to a list of HTML element names. To allow a\nspecific set of HTML elements within Markdown tables, set the\n`table_allowed_elements` parameter to a list of HTML element names. This can be\nused to permit the use of `
`-style line breaks only within Markdown tables.\n\nRationale: Raw HTML is allowed in Markdown, but this rule is included for\nthose who want their documents to only include \"pure\" Markdown, or for those\nwho are rendering Markdown documents into something other than HTML.\n\n\n\n## `MD034` - Bare URL used\n\nTags: `links`, `url`\n\nAliases: `no-bare-urls`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered whenever a URL or email address appears without\nsurrounding angle brackets:\n\n```markdown\nFor more info, visit https://www.example.com/ or email user@example.com.\n```\n\nTo fix this, add angle brackets around the URL or email address:\n\n```markdown\nFor more info, visit or email .\n```\n\nIf a URL or email address contains non-ASCII characters, it may be not be\nhandled as intended even when angle brackets are present. In such cases,\n[percent-encoding](https://wikipedia.org/wiki/Percent-encoding) can be used\nto comply with the required syntax for URL and email.\n\nNote: To include a bare URL or email without it being converted into a link,\nwrap it in a code span:\n\n```markdown\nNot a clickable link: `https://www.example.com`\n```\n\nNote: The following scenario does not trigger this rule because it could be a\nshortcut link:\n\n```markdown\n[https://www.example.com]\n```\n\nNote: The following syntax triggers this rule because the nested link could be\na shortcut link (which takes precedence):\n\n```markdown\n[text [shortcut] text](https://example.com)\n```\n\nTo avoid this, escape both inner brackets:\n\n```markdown\n[link \\[text\\] link](https://example.com)\n```\n\nRationale: Without angle brackets, a bare URL or email isn't converted into a\nlink by some Markdown parsers.\n\n\n\n## `MD035` - Horizontal rule style\n\nTags: `hr`\n\nAliases: `hr-style`\n\nParameters:\n\n- `style`: Horizontal rule style (`string`, default `consistent`)\n\nThis rule is triggered when inconsistent styles of horizontal rules (also known\nas \"thematic breaks\") are used in a document:\n\n```markdown\n---\n\n- - -\n\n***\n\n* * *\n\n****\n```\n\nTo fix this, use the same horizontal rule syntax everywhere:\n\n```markdown\n---\n\n---\n\n---\n```\n\nThe `style` parameter's default value `consistent` ensures all horizontal rules\nin a document match the first horizontal rule in that document. To enforce a\nspecific pattern of characters, set the `style` parameter to that string (e.g.,\n`\"* * *\"`).\n\nNote: In order to be recognized as a horizontal rule, a line must contain three\nor more matching `-`, `_`, or `*` characters with optional space between.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD036` - Emphasis used instead of a heading\n\nTags: `emphasis`, `headings`\n\nAliases: `no-emphasis-as-heading`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!?。，；：！？`)\n\nThis check looks for instances where emphasized (i.e. bold or italic) text is\nused to separate sections, where a heading should be used instead:\n\n```markdown\n**My document**\n\nLorem ipsum dolor sit amet...\n\n_Another section_\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nTo fix this, use Markdown headings instead of emphasized text to denote\nsections:\n\n```markdown\n# My document\n\nLorem ipsum dolor sit amet...\n\n## Another section\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nNote: This rule looks for single-line paragraphs that consist entirely\nof emphasized text. It won't fire on emphasis used within regular text,\nmulti-line emphasized paragraphs, or paragraphs ending in punctuation\n(normal or full-width). Similarly to rule MD026, you can configure what\ncharacters are recognized as punctuation.\n\nRationale: Using emphasis instead of a heading prevents tools from inferring\nthe structure of a document. More information:\n.\n\n\n\n## `MD037` - Spaces inside emphasis markers\n\nTags: `emphasis`, `whitespace`\n\nAliases: `no-space-in-emphasis`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when emphasis markers (bold, italic) are used, but they\nhave spaces between the markers and the text:\n\n```markdown\nHere is some ** bold ** text.\n\nHere is some * italic * text.\n\nHere is some more __ bold __ text.\n\nHere is some more _ italic _ text.\n```\n\nTo fix this, remove the spaces around the emphasis markers:\n\n```markdown\nHere is some **bold** text.\n\nHere is some *italic* text.\n\nHere is some more __bold__ text.\n\nHere is some more _italic_ text.\n```\n\nRationale: Emphasis is only parsed as such when the asterisks/underscores\naren't surrounded by spaces. This rule attempts to detect where\nthey were surrounded by spaces, but it appears that emphasized text was\nintended by the author.\n\n\n\n## `MD038` - Spaces inside code span elements\n\nTags: `code`, `whitespace`\n\nAliases: `no-space-in-code`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for code spans containing content with unnecessary space\nnext to the beginning or ending backticks:\n\n```markdown\n`some text `\n\n` some text`\n\n` some text `\n```\n\nTo fix this, remove the extra space characters from the beginning and ending:\n\n```markdown\n`some text`\n```\n\nNote: A single leading *and* trailing space is allowed by the specification and\ntrimmed by the parser to support code spans that begin or end with a backtick:\n\n```markdown\n`` `backticks` ``\n\n`` backtick` ``\n```\n\nNote: When single-space padding is present in the input, it will be preserved\n(even if unnecessary):\n\n```markdown\n` code `\n```\n\nNote: Code spans containing only spaces are allowed by the specification and are\nalso preserved:\n\n```markdown\n` `\n\n` `\n```\n\nRationale: Violations of this rule are usually unintentional and can lead to\nimproperly-rendered content.\n\n\n\n## `MD039` - Spaces inside link text\n\nTags: `links`, `whitespace`\n\nAliases: `no-space-in-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on links that have spaces surrounding the link text:\n\n```markdown\n[ a link ](https://www.example.com/)\n```\n\nTo fix this, remove the spaces surrounding the link text:\n\n```markdown\n[a link](https://www.example.com/)\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD040` - Fenced code blocks should have a language specified\n\nTags: `code`, `language`\n\nAliases: `fenced-code-language`\n\nParameters:\n\n- `allowed_languages`: List of languages (`string[]`, default `[]`)\n- `language_only`: Require language only (`boolean`, default `false`)\n\nThis rule is triggered when fenced code blocks are used, but a language isn't\nspecified:\n\n````markdown\n```\n#!/bin/bash\necho Hello world\n```\n````\n\nTo fix this, add a language specifier to the code block:\n\n````markdown\n```bash\n#!/bin/bash\necho Hello world\n```\n````\n\nTo display a code block without syntax highlighting, use:\n\n````markdown\n```text\nPlain text in a code block\n```\n````\n\nYou can configure the `allowed_languages` parameter to specify a list of\nlanguages code blocks could use. Languages are case sensitive. The default value\nis `[]` which means any language specifier is valid.\n\nYou can prevent extra data from being present in the info string of fenced code\nblocks. To do so, set the `language_only` parameter to `true`.\n\n\nInfo strings with leading/trailing whitespace (ex: `js `) or other content (ex:\n`ruby startline=3`) will trigger this rule.\n\nRationale: Specifying a language improves content rendering by using the\ncorrect syntax highlighting for code. More information:\n.\n\n\n\n## `MD041` - First line in a file should be a top-level heading\n\nTags: `headings`\n\nAliases: `first-line-h1`, `first-line-heading`\n\nParameters:\n\n- `allow_preamble`: Allow content before first heading (`boolean`, default\n `false`)\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is intended to ensure documents have a title and is triggered when\nthe first line in a document is not a top-level ([HTML][HTML] `h1`) heading:\n\n```markdown\nThis is a document without a heading\n```\n\nTo fix this, add a top-level heading to the beginning of the document:\n\n```markdown\n# Document Heading\n\nThis is a document with a top-level heading\n```\n\nBecause it is common for projects on GitHub to use an image for the heading of\n`README.md` and that pattern is not well-supported by Markdown, HTML headings\nare also permitted by this rule. For example:\n\n```markdown\n

\n\nThis is a document with a top-level HTML heading\n```\n\nIn some cases, a document's title heading may be preceded by text like a table\nof contents. This is not ideal for accessibility, but can be allowed by setting\nthe `allow_preamble` parameter to `true`.\n\n```markdown\nThis is a document with preamble text\n\n# Document Heading\n```\n\nIf [YAML][YAML] front matter is present and contains a `title` property\n(commonly used with blog posts), this rule will not report a violation. To use a\ndifferent property name in the front matter, specify the text of a [regular\nexpression][RegExp] via the `front_matter_title` parameter. To disable the use\nof front matter by this rule, specify `\"\"` for `front_matter_title`.\n\nThe `level` parameter can be used to change the top-level heading (ex: to `h2`)\nin cases where an `h1` is added externally.\n\nRationale: The top-level heading often acts as the title of a document. More\ninformation: .\n\n[HTML]: https://wikipedia.org/wiki/HTML\n[RegExp]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n[YAML]: https://wikipedia.org/wiki/YAML\n\n\n\n## `MD042` - No empty links\n\nTags: `links`\n\nAliases: `no-empty-links`\n\nThis rule is triggered when an empty link is encountered:\n\n```markdown\n[an empty link]()\n```\n\nTo fix the violation, provide a destination for the link:\n\n```markdown\n[a valid link](https://example.com/)\n```\n\nEmpty fragments will trigger this rule:\n\n```markdown\n[an empty fragment](#)\n\n[an empty link definition][empty]\n\n[empty]: #\n```\n\nBut non-empty fragments will not:\n\n```markdown\n[a valid fragment](#fragment)\n```\n\nEmpty link definitions\n\nRationale: Empty links do not lead anywhere and therefore don't function as\nlinks.\n\n\n\n## `MD043` - Required heading structure\n\nTags: `headings`\n\nAliases: `required-headings`\n\nParameters:\n\n- `headings`: List of headings (`string[]`, default `[]`)\n- `match_case`: Match case of headings (`boolean`, default `false`)\n\nThis rule is triggered when the headings in a file do not match the array of\nheadings passed to the rule. It can be used to enforce a standard heading\nstructure for a set of files.\n\nTo require exactly the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail\n```\n\nSet the `headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"### Detail\"\n]\n```\n\nTo allow optional headings as with the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail (optional)\n## Foot\n### Notes (optional)\n```\n\nUse the special value `\"*\"` meaning \"zero or more unspecified headings\" or the\nspecial value `\"+\"` meaning \"one or more unspecified headings\" and set the\n`headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"*\",\n \"## Foot\",\n \"*\"\n]\n```\n\nTo allow a single required heading to vary as with a project name:\n\n```markdown\n# Project Name\n## Description\n## Examples\n```\n\nUse the special value `\"?\"` meaning \"exactly one unspecified heading\":\n\n```json\n[\n \"?\",\n \"## Description\",\n \"## Examples\"\n]\n```\n\nWhen an error is detected, this rule outputs the line number of the first\nproblematic heading (otherwise, it outputs the last line number of the file).\n\nNote that while the `headings` parameter uses the \"## Text\" ATX heading style\nfor simplicity, a file may use any supported heading style.\n\nBy default, the case of headings in the document is not required to match that\nof `headings`. To require that case match exactly, set the `match_case`\nparameter to `true`.\n\nRationale: Projects may wish to enforce a consistent document structure across\na set of similar content.\n\n\n\n## `MD044` - Proper names should have the correct capitalization\n\nTags: `spelling`\n\nAliases: `proper-names`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `html_elements`: Include HTML elements (`boolean`, default `true`)\n- `names`: List of proper names (`string[]`, default `[]`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when any of the strings in the `names` array do not have\nthe specified capitalization. It can be used to enforce a standard letter case\nfor the names of projects and products.\n\nFor example, the language \"JavaScript\" is usually written with both the 'J' and\n'S' capitalized - though sometimes the 's' or 'j' appear in lower-case. To\nenforce the proper capitalization, specify the desired letter case in the\n`names` array:\n\n```json\n[\n \"JavaScript\"\n]\n```\n\nSometimes a proper name is capitalized differently in certain contexts. In such\ncases, add both forms to the `names` array:\n\n```json\n[\n \"GitHub\",\n \"github.com\"\n]\n```\n\nSet the `code_blocks` parameter to `false` to disable this rule for code blocks\nand spans. Set the `html_elements` parameter to `false` to disable this rule\nfor HTML elements and attributes (such as when using a proper name as part of\na path for `a`/`href` or `img`/`src`).\n\nRationale: Incorrect capitalization of proper names is usually a mistake.\n\n\n\n## `MD045` - Images should have alternate text (alt text)\n\nTags: `accessibility`, `images`\n\nAliases: `no-alt-text`\n\nThis rule reports a violation when an image is missing alternate text (alt text)\ninformation.\n\nAlternate text is commonly specified inline as:\n\n```markdown\n![Alternate text](image.jpg)\n```\n\nOr with reference syntax as:\n\n```markdown\n![Alternate text][ref]\n\n...\n\n[ref]: image.jpg \"Optional title\"\n```\n\nOr with HTML as:\n\n```html\n\"Alternate\n```\n\nNote: If the [HTML `aria-hidden` attribute][aria-hidden] is used to hide the\nimage from assistive technology, this rule does not report a violation:\n\n```html\n\n```\n\nGuidance for writing alternate text is available from the [W3C][w3c],\n[Wikipedia][wikipedia], and [other locations][phase2technology].\n\nRationale: Alternate text is important for accessibility and describes the\ncontent of an image for people who may not be able to see it.\n\n[aria-hidden]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-hidden\n[phase2technology]: https://www.phase2technology.com/blog/no-more-excuses\n[w3c]: https://www.w3.org/WAI/alt/\n[wikipedia]: https://wikipedia.org/wiki/Alt_attribute\n\n\n\n## `MD046` - Code block style\n\nTags: `code`\n\nAliases: `code-block-style`\n\nParameters:\n\n- `style`: Block style (`string`, default `consistent`, values `consistent` /\n `fenced` / `indented`)\n\nThis rule is triggered when unwanted or different code block styles are used in\nthe same document.\n\nIn the default configuration this rule reports a violation for the following\ndocument:\n\n\n\n Some text.\n\n # Indented code\n\n More text.\n\n ```ruby\n # Fenced code\n ```\n\n More text.\n\n\n\nTo fix violations of this rule, use a consistent style (either indenting or code\nfences).\n\nThe configured code block style can be specific (`fenced`, `indented`) or can\nrequire all code blocks match the first code block (`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD047` - Files should end with a single newline character\n\nTags: `blank_lines`\n\nAliases: `single-trailing-newline`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there is not a single newline character at the end\nof a file.\n\nAn example that triggers the rule:\n\n```markdown\n# Heading\n\nThis file ends without a newline.[EOF]\n```\n\nTo fix the violation, add a newline character to the end of the file:\n\n```markdown\n# Heading\n\nThis file ends with a newline.\n[EOF]\n```\n\nRationale: Some programs have trouble with files that do not end with a newline.\n\nMore information: [What's the point in adding a new line to the end of a\nfile?][stack-exchange]\n\n[stack-exchange]: https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file\n\n\n\n## `MD048` - Code fence style\n\nTags: `code`\n\nAliases: `code-fence-style`\n\nParameters:\n\n- `style`: Code fence style (`string`, default `consistent`, values `backtick`\n / `consistent` / `tilde`)\n\nThis rule is triggered when the symbols used in the document for fenced code\nblocks do not match the configured code fence style:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n~~~ruby\n# Fenced code\n~~~\n````\n\nTo fix this issue, use the configured code fence style throughout the\ndocument:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n```ruby\n# Fenced code\n```\n````\n\nThe configured code fence style can be a specific symbol to use (`backtick`,\n`tilde`) or it can require all code fences match the first code fence\n(`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD049` - Emphasis style\n\nTags: `emphasis`\n\nAliases: `emphasis-style`\n\nParameters:\n\n- `style`: Emphasis style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for emphasis do not\nmatch the configured emphasis style:\n\n```markdown\n*Text*\n_Text_\n```\n\nTo fix this issue, use the configured emphasis style throughout the document:\n\n```markdown\n*Text*\n*Text*\n```\n\nThe configured emphasis style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all emphasis matches the first emphasis\n(`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like_this_one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD050` - Strong style\n\nTags: `emphasis`\n\nAliases: `strong-style`\n\nParameters:\n\n- `style`: Strong style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for strong do not\nmatch the configured strong style:\n\n```markdown\n**Text**\n__Text__\n```\n\nTo fix this issue, use the configured strong style throughout the document:\n\n```markdown\n**Text**\n**Text**\n```\n\nThe configured strong style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all strong matches the first strong (`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like__this__one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD051` - Link fragments should be valid\n\nTags: `links`\n\nAliases: `link-fragments`\n\nParameters:\n\n- `ignore_case`: Ignore case of fragments (`boolean`, default `false`)\n- `ignored_pattern`: Pattern for ignoring additional fragments (`string`,\n default ``)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a link fragment does not match any of the fragments\nthat are automatically generated for headings in a document:\n\n```markdown\n# Heading Name\n\n[Link](#fragment)\n```\n\nTo fix this issue, change the link fragment to reference an existing heading's\ngenerated name (see below):\n\n```markdown\n# Heading Name\n\n[Link](#heading-name)\n```\n\nFor consistency, this rule requires fragments to exactly match the [GitHub\nheading algorithm][github-heading-algorithm] which converts letters to\nlowercase. Therefore, the following example is reported as a violation:\n\n```markdown\n# Heading Name\n\n[Link](#Heading-Name)\n```\n\nTo ignore case when comparing fragments with heading names, the `ignore_case`\nparameter can be set to `true`. In this configuration, the previous example is\nnot reported as a violation.\n\nAlternatively, some platforms allow the syntax `{#named-anchor}` to be used\nwithin a heading to provide a specific name (consisting of only lower-case\nletters, numbers, `-`, and `_`):\n\n```markdown\n# Heading Name {#custom-name}\n\n[Link](#custom-name)\n```\n\nAlternatively, any HTML tag with an `id` attribute or an `a` tag with a `name`\nattribute can be used to define a fragment:\n\n```markdown\n\n\n[Link](#bookmark)\n```\n\nAn `a` tag can be useful in scenarios where a heading is not appropriate or for\ncontrol over the text of the fragment identifier.\n\n[HTML links to `#top` scroll to the top of a document][html-top-fragment]. This\nrule allows that syntax (using lower-case for consistency):\n\n```markdown\n[Link](#top)\n```\n\nThis rule also recognizes the custom fragment syntax used by GitHub to highlight\n[specific content in a document][github-linking-to-content].\n\nFor example, this link to line 20:\n\n```markdown\n[Link](#L20)\n```\n\nAnd this link to content starting within line 19 running into line 21:\n\n```markdown\n[Link](#L19C5-L21C11)\n```\n\nSome Markdown generators dynamically create and insert headings when building\ndocuments, for example by combining a fixed prefix like `figure-` and an\nincrementing numeric counter. To ignore such generated fragments, set the\n`ignored_pattern` [regular expression][RegEx] parameter to a pattern that\nmatches (e.g., `^figure-`).\n\nRationale: [GitHub section links][github-section-links] are created\nautomatically for every heading when Markdown content is displayed on GitHub.\nThis makes it easy to link directly to different sections within a document.\nHowever, section links change if headings are renamed or removed. This rule\nhelps identify broken section links within a document.\n\nNote: Section links are **not** part of the CommonMark specification; this rule\nenforces the [GitHub heading algorithm][github-heading-algorithm]:\n\n1. Convert text to lowercase\n2. Remove punctuation characters\n3. Convert spaces to dashes\n4. Append an incrementing integer (as needed for uniqueness)\n5. [URI-encode][encodeURIComponent] the result\n\n[encodeURIComponent]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent\n[github-section-links]: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#section-links\n[github-heading-algorithm]: https://github.com/gjtorikian/html-pipeline/blob/f13a1534cb650ba17af400d1acd3a22c28004c09/lib/html/pipeline/toc_filter.rb\n[github-linking-to-content]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet#linking-to-markdown\n[html-top-fragment]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment\n[RegEx]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n\n\n\n## `MD052` - Reference links and images should use a label that is defined\n\nTags: `images`, `links`\n\nAliases: `reference-links-images`\n\nParameters:\n\n- `ignored_labels`: Ignored link labels (`string[]`, default `[\"x\"]`)\n- `shortcut_syntax`: Include shortcut syntax (`boolean`, default `false`)\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can define it elsewhere and use a label for reference.\nThe reference format is convenient for keeping paragraph text clutter-free\nand makes it easy to reuse the same URL in multiple places.\n\nThere are three kinds of reference links and images:\n\n```markdown\nFull: [text][label]\nCollapsed: [label][]\nShortcut: [label]\n\nFull: ![text][image]\nCollapsed: ![image][]\nShortcut: ![image]\n\n[label]: https://example.com/label\n[image]: https://example.com/image\n```\n\nA link or image renders correctly when the corresponding label is defined, but\ndisplays as text with brackets when the label is not present. By default, this\nrule warns of undefined labels for \"full\" and \"collapsed\" reference syntax but\nnot for \"shortcut\" syntax because it is ambiguous.\n\nThe text `[example]` could be a shortcut link or the text \"example\" in brackets,\nso \"shortcut\" syntax is ignored by default. To include \"shortcut\" syntax, set\nthe `include_shortcut` parameter to `true`. Note that doing so produces warnings\nfor *all* text in the document that *could* be a shortcut. If bracketed text is\nintentional, brackets can be escaped with the `\\` character: `\\[example\\]`.\n\nIf there are link labels that are deliberately unreferenced, they can be ignored\nby setting the `ignored_labels` parameter to the list of strings to ignore. The\ndefault value of this parameter ignores the checkbox syntax used by\n[GitHub Flavored Markdown task list items][gfm-tasklist]:\n\n```markdown\n- [x] Checked task list item\n```\n\n[gfm-tasklist]: https://github.github.com/gfm/#task-list-items-extension-\n\n\n\n## `MD053` - Link and image reference definitions should be needed\n\nTags: `images`, `links`\n\nAliases: `link-image-reference-definitions`\n\nParameters:\n\n- `ignored_definitions`: Ignored definitions (`string[]`, default `[\"//\"]`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can use a label to reference a definition elsewhere in\nthe document. The latter reference format is convenient for keeping paragraph\ntext clutter-free and makes it easy to reuse the same URL in multiple places.\n\nBecause link and image reference definitions are located separately from\nwhere they are used, there are two scenarios where a definition can be\nunnecessary:\n\n1. If a label is not referenced by any link or image in a document, that\n definition is unused and can be deleted.\n2. If a label is defined multiple times in a document, the first definition is\n used and the others can be deleted.\n\nThis rule considers a reference definition to be used if any link or image\nreference has the corresponding label. The \"full\", \"collapsed\", and \"shortcut\"\nformats are all supported.\n\nIf there are reference definitions that are deliberately unreferenced, they can\nbe ignored by setting the `ignored_definitions` parameter to the list of strings\nto ignore. The default value of this parameter ignores the following convention\nfor adding non-HTML comments to Markdown:\n\n```markdown\n[//]: # (This behaves like a comment)\n```\n\n\n\n## `MD054` - Link and image style\n\nTags: `images`, `links`\n\nAliases: `link-image-style`\n\nParameters:\n\n- `autolink`: Allow autolinks (`boolean`, default `true`)\n- `collapsed`: Allow collapsed reference links and images (`boolean`, default\n `true`)\n- `full`: Allow full reference links and images (`boolean`, default `true`)\n- `inline`: Allow inline links and images (`boolean`, default `true`)\n- `shortcut`: Allow shortcut reference links and images (`boolean`, default\n `true`)\n- `url_inline`: Allow URLs as inline links (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source at\nthe time of use or can use a label to reference a definition elsewhere in the\ndocument. The three reference formats are convenient for keeping paragraph text\nclutter-free and make it easy to reuse the same URL in multiple places.\n\nBy default, this rule allows all link/image styles.\n\nSetting the `autolink` parameter to `false` disables autolinks:\n\n```markdown\n\n```\n\nSetting the `inline` parameter to `false` disables inline links and images:\n\n```markdown\n[link](https://example.com)\n\n![image](https://example.com)\n```\n\nSetting the `full` parameter to `false` disables full reference links and\nimages:\n\n```markdown\n[link][url]\n\n![image][url]\n\n[url]: https://example.com\n```\n\nSetting the `collapsed` parameter to `false` disables collapsed reference links\nand images:\n\n```markdown\n[url][]\n\n![url][]\n\n[url]: https://example.com\n```\n\nSetting the `shortcut` parameter to `false` disables shortcut reference links\nand images:\n\n```markdown\n[url]\n\n![url]\n\n[url]: https://example.com\n```\n\nTo fix violations of this rule, change the link or image to use an allowed\nstyle. This rule can automatically fix violations when a link or image can be\nconverted to the `inline` style (preferred) or a link can be converted to the\n`autolink` style (which does not support images and must be an absolute URL).\nThis rule does *not* fix scenarios that require converting a link or image to\nthe `full`, `collapsed`, or `shortcut` reference styles because that involves\nnaming the reference and determining where to insert it in the document.\n\nSetting the `url_inline` parameter to `false` prevents the use of inline links\nwith the same absolute URL text/destination and no title because such links can\nbe converted to autolinks:\n\n```markdown\n[https://example.com](https://example.com)\n```\n\nTo fix `url_inline` violations, use the simpler autolink syntax instead:\n\n```markdown\n\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\nAutolinks are concise, but appear as URLs which can be long and confusing.\nInline links and images can include descriptive text, but take up more space in\nMarkdown form. Reference links and images can be easier to read and manipulate\nin Markdown form, but require a separate link reference definition.\n\n\n\n## `MD055` - Table pipe style\n\nTags: `table`\n\nAliases: `table-pipe-style`\n\nParameters:\n\n- `style`: Table pipe style (`string`, default `consistent`, values\n `consistent` / `leading_and_trailing` / `leading_only` /\n `no_leading_or_trailing` / `trailing_only`)\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-055]\nis inconsistent about its use of leading and trailing pipe characters (`|`).\n\nBy default (`consistent` style), the header row of the first table in a document\nis used to determine the style that is enforced for every table in the document.\nA specific style can be used instead (`leading_and_trailing`, `leading_only`,\n`no_leading_or_trailing`, `trailing_only`).\n\nThis table's header row has leading and trailing pipes, but its delimiter row is\nmissing the trailing pipe and its first row of cells is missing the leading\npipe:\n\n```markdown\n| Header | Header |\n| ------ | ------\n Cell | Cell |\n```\n\nTo fix these issues, make sure there is a pipe character at the beginning and\nend of every row:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and may also\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table\n```\n\nRationale: Some parsers have difficulty with tables that are missing their\nleading or trailing pipe characters. The use of leading/trailing pipes can also\nhelp provide visual clarity.\n\n[gfm-table-055]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD056` - Table column count\n\nTags: `table`\n\nAliases: `table-column-count`\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-056]\ndoes not have the same number of cells in every row.\n\nThis table's second data row has too few cells and its third data row has too\nmany cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell |\n| Cell | Cell | Cell |\n```\n\nTo fix these issues, ensure every row has the same number of cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell | Cell |\n| Cell | Cell |\n```\n\nNote that a table's header row and its delimiter row must have the same number\nof cells or it will not be recognized as a table (per specification).\n\nRationale: Extra cells in a row are usually not shown, so their data is lost.\nMissing cells in a row create holes in the table and suggest an omission.\n\n[gfm-table-056]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD058` - Tables should be surrounded by blank lines\n\nTags: `table`\n\nAliases: `blanks-around-tables`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when tables are either not preceded or not followed by a\nblank line:\n\n```markdown\nSome text\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n> Blockquote\n```\n\nTo fix violations of this rule, ensure that all tables have a blank line both\nbefore and after (except when the table is at the very beginning or end of the\ndocument):\n\n```markdown\nSome text\n\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n\n> Blockquote\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and will not\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table and the next line is blank\n\nSome text\n```\n\nRationale: In addition to aesthetic reasons, some parsers will incorrectly parse\ntables that don't have blank lines before and after them.\n\n\n\n## `MD059` - Link text should be descriptive\n\nTags: `accessibility`, `links`\n\nAliases: `descriptive-link-text`\n\nParameters:\n\n- `prohibited_texts`: Prohibited link texts (`string[]`, default `[\"click\n here\",\"here\",\"link\",\"more\"]`)\n\nThis rule is triggered when a link has generic text like `[click here](...)` or\n`[link](...)`.\n\nLink text should be descriptive and communicate the purpose of the link (e.g.,\n`[Download the budget document](...)` or `[CommonMark Specification](...)`).\nThis is especially important for screen readers which sometimes present links\nwithout context.\n\nBy default, this rule prohibits a small number of common English words/phrases.\nTo customize that list of words/phrases, set the `prohibited_texts` parameter to\nan `Array` of `string`s.\n\nNote: For languages other than English, use the `prohibited_texts` parameter to\ncustomize the list for that language. It is *not* a goal for this rule to have\ntranslations for every language.\n\nNote: This rule checks Markdown links; HTML links are ignored.\n\nMore information:\n\n- \n- \n\n\n\n## `MD060` - Table column style\n\nTags: `table`\n\nAliases: `table-column-style`\n\nParameters:\n\n- `aligned_delimiter`: Aligned delimiter columns (`boolean`, default `false`)\n- `style`: Table column style (`string`, default `any`, values `aligned` /\n `any` / `compact` / `tight`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the column separator pipe characters (`|`) of a\n[GitHub Flavored Markdown table][gfm-table-060] are used inconsistently.\n\nThis rule recognizes three table column styles based on popular use.\n\nStyle `aligned` ensures pipe characters are vertically aligned:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nThe `aligned` style ignores cell content, so the following is also valid:\n\n```markdown\n| Character | Meaning |\n|-----------|---------|\n| Y | Yes |\n| N | No |\n```\n\nStyle `compact` avoids extra padding with a single space around cell content:\n\n```markdown\n| Character | Meaning |\n| --- | --- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` uses no padding at all for cell content:\n\n```markdown\n|Character|Meaning|\n|---|---|\n|Y|Yes|\n|N|No|\n```\n\nWhen this rule's `style` parameter is set to `aligned`, `compact`, or `tight`,\nevery table must match the corresponding pattern and any violations will be\nreported. By default, or when the `any` style is used, each table is analyzed to\nsee if it satisfies any supported style. If so, no violations are reported. If\nnot, violations are be reported for whichever style would produce the *fewest*\nissues (i.e., whichever style is the closest match).\n\nSetting the `aligned_delimiter` parameter to `true` requires pipe characters in\nthe delimiter row to align with those in the header row. This can be used with\n`compact` and `tight` tables to make the header text more obvious. (It's already\nrequired for tables with style `aligned`.)\n\nStyle `compact` with `aligned_delimiter`:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` with `aligned_delimiter`:\n\n```markdown\n|Character|Meaning|\n|---------|-------|\n|Y|Yes|\n|N|No|\n```\n\nViolations for styles `compact` and `tight` are simple/independent and can be\nfixed automatically. However, fixing even single violations for style `aligned`\nmay require modifying the entire table, and therefore are not automatic:\n\n```markdown\n|Alpha |Delta|\n|------|-----|\n|Charlie|Beta|\n```\n\n**Note**: This rule does not require leading/trailing pipe characters, so this\nis also a valid table for style `compact`:\n\n```markdown\nCharacter | Meaning\n--- | ---\nY | Yes\nN | No\n```\n\n**Note**: Pipe alignment for the `aligned` style is based on visual appearance\nand not character count. Because editors typically render [emoji][emoji] and\n[CJK characters][cjk-characters] at *twice* the width of\n[Latin characters][latin-script], this rule takes that into account for tables\nusing the `aligned` style. The following table is correctly formatted and will\nappear aligned in most editors and monospaced fonts:\n\n\n\n\n```markdown\n| Response | Emoji |\n| -------- | ----- |\n| Yes | ✅ |\n| No | ❎ |\n```\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n[cjk-characters]: https://wikipedia.org/wiki/CJK_characters\n[emoji]: https://wikipedia.org/wiki/Emoji\n[gfm-table-060]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n[latin-script]: https://wikipedia.org/wiki/Latin_script\n\n\n"},"items":[{"name":"Rules.md","path":"doc/Rules.md","rawUrl":"https://raw.githubusercontent.com/DavidAnson/markdownlint/HEAD/doc/Rules.md","title":"doc - Development & Architecture Rules","category":"root-instruction","format":"markdown","content":"# Rules\n\nThis document contains a description of all rules, what they are checking for,\nas well as examples of documents that break the rule and corrected\nversions of the examples.\n\n\n\n## `MD001` - Heading levels should only increment by one level at a time\n\nTags: `headings`\n\nAliases: `heading-increment`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n\nThis rule is triggered when you skip heading levels in a Markdown document, for\nexample:\n\n```markdown\n# Heading 1\n\n### Heading 3\n\nWe skipped out a 2nd level heading in this document\n```\n\nWhen using multiple heading levels, nested headings should increase by only one\nlevel at a time:\n\n```markdown\n# Heading 1\n\n## Heading 2\n\n### Heading 3\n\n#### Heading 4\n\n## Another Heading 2\n\n### Another Heading 3\n```\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation if the actual first\nheading is not a level 2 heading. To use a different property name in the\nfront matter, specify the text of a regular expression via the\n`front_matter_title` parameter. To disable the use of front matter by this\nrule, specify `\"\"` for `front_matter_title`. When front matter is not present,\nthe first heading can be any level.\n\nRationale: Headings represent the structure of a document and can be confusing\nwhen skipped - especially for accessibility scenarios. More information:\n.\n\n\n\n## `MD003` - Heading style\n\nTags: `headings`\n\nAliases: `heading-style`\n\nParameters:\n\n- `style`: Heading style (`string`, default `consistent`, values `atx` /\n `atx_closed` / `consistent` / `setext` / `setext_with_atx` /\n `setext_with_atx_closed`)\n\nThis rule is triggered when different heading styles are used in the same\ndocument:\n\n```markdown\n# ATX style H1\n\n## Closed ATX style H2 ##\n\nSetext style H1\n===============\n```\n\nTo fix the issue, use consistent heading styles throughout the document:\n\n```markdown\n# ATX style H1\n\n## ATX style H2\n```\n\nThe `setext_with_atx` and `setext_with_atx_closed` settings allow ATX-style\nheadings of level 3 or more in documents with setext-style headings (which only\nsupport level 1 and 2 headings):\n\n```markdown\nSetext style H1\n===============\n\nSetext style H2\n---------------\n\n### ATX style H3\n```\n\nNote: The configured heading style can be a specific style to require (`atx`,\n`atx_closed`, `setext`, `setext_with_atx`, `setext_with_atx_closed`), or can\nrequire that all heading styles match the first heading style via `consistent`.\n\nNote: The placement of a horizontal rule directly below a line of text can\ntrigger this rule by turning that text into a level 2 setext-style heading:\n\n```markdown\nA line of text followed by a horizontal rule becomes a heading\n---\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD004` - Unordered list style\n\nTags: `bullet`, `ul`\n\nAliases: `ul-style`\n\nParameters:\n\n- `style`: List style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `dash` / `plus` / `sublist`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for unordered\nlist items do not match the configured unordered list style:\n\n```markdown\n* Item 1\n+ Item 2\n- Item 3\n```\n\nTo fix this issue, use the configured style for list items throughout the\ndocument:\n\n```markdown\n* Item 1\n* Item 2\n* Item 3\n```\n\nThe configured list style can ensure all list styling is a specific symbol\n(`asterisk`, `plus`, `dash`), ensure each sublist has a consistent symbol that\ndiffers from its parent list (`sublist`), or ensure all list styles match the\nfirst list style (`consistent`).\n\nFor example, the following is valid for the `sublist` style because the\nouter-most indent uses asterisk, the middle indent uses plus, and the inner-most\nindent uses dash:\n\n```markdown\n* Item 1\n + Item 2\n - Item 3\n + Item 4\n* Item 4\n + Item 5\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD005` - Inconsistent indentation for list items at the same level\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `list-indent`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are parsed as being at the same level,\nbut don't have the same indentation:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * A misaligned item\n```\n\nUsually, this rule will be triggered because of a typo. Correct the indentation\nfor the list to fix it:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * Nested Item 3\n```\n\nSequentially-ordered list markers are usually left-aligned such that all items\nhave the same starting column:\n\n```markdown\n...\n8. Item\n9. Item\n10. Item\n11. Item\n...\n```\n\nThis rule also supports right-alignment of list markers such that all items have\nthe same ending column:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n...\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD007` - Unordered list indentation\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `ul-indent`\n\nParameters:\n\n- `indent`: Spaces for indent (`integer`, default `2`)\n- `start_indent`: Spaces for first level indent (when start_indented is set)\n (`integer`, default `2`)\n- `start_indented`: Whether to indent the first level of the list (`boolean`,\n default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are not indented by the configured\nnumber of spaces (default: 2).\n\nExample:\n\n```markdown\n* List item\n * Nested list item indented by 3 spaces\n```\n\nCorrected Example:\n\n```markdown\n* List item\n * Nested list item indented by 2 spaces\n```\n\nNote: This rule applies to a sublist only if its parent lists are all also\nunordered (otherwise, extra indentation of ordered lists interferes with the\nrule).\n\nThe `start_indented` parameter allows the first level of lists to be indented by\nthe configured number of spaces rather than starting at zero. The `start_indent`\nparameter allows the first level of lists to be indented by a different number\nof spaces than the rest (ignored when `start_indented` is not set).\n\nRationale: Indenting by 2 spaces allows the content of a nested list to be in\nline with the start of the content of the parent list when a single space is\nused after the list marker. Indenting by 4 spaces is consistent with code blocks\nand simpler for editors to implement. Additionally, this can be a compatibility\nissue for other Markdown parsers, which require 4-space indents. More\ninformation: [Markdown Style Guide][markdown-style-guide].\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n[markdown-style-guide]: https://cirosantilli.com/markdown-style-guide#indentation-of-content-inside-lists\n\n\n\n## `MD009` - Trailing spaces\n\nTags: `whitespace`\n\nAliases: `no-trailing-spaces`\n\nParameters:\n\n- `br_spaces`: Spaces for line break (`integer`, default `2`)\n- `code_blocks`: Include code blocks (`boolean`, default `false`)\n- `list_item_empty_lines`: Allow spaces for empty lines in list items\n (`boolean`, default `false`)\n- `strict`: Include unnecessary breaks (`boolean`, default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any lines that end with unexpected whitespace. To fix\nthis, remove the trailing space from the end of the line.\n\nThe `br_spaces` parameter allows an exception to this rule for a specific number\nof trailing spaces, typically used to insert an explicit line break. The default\nvalue allows 2 spaces to indicate a hard break (\\
element). (You must set\n`br_spaces` to a value >= 2 for this parameter to take effect. Setting\n`br_spaces` to 1 behaves the same as 0, disallowing any trailing spaces.)\n\nBy default, trailing space is allowed in indented and fenced code blocks because\nsome programming languages require that. To report such instances, set the\n`code_blocks` parameter to `true`.\n\nBy default, this rule will not trigger when the allowed number of spaces is\nused, even when it doesn't create a hard break (for example, at the end of a\nparagraph). To report such instances, set the `strict` parameter to `true`.\n\n```markdown\nText text text\ntext[2 spaces]\n```\n\nUsing spaces to indent blank lines inside a list item is usually not necessary,\nbut some parsers require it. Set the `list_item_empty_lines` parameter to `true`\nto allow this (even when `strict` is `true`):\n\n```markdown\n- list item text\n [2 spaces]\n list item text\n```\n\nRationale: Except when being used to create a line break, trailing whitespace\nhas no purpose and does not affect the rendering of content.\n\n\n\n## `MD010` - Hard tabs\n\nTags: `hard_tab`, `whitespace`\n\nAliases: `no-hard-tabs`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `ignore_code_languages`: Fenced code languages to ignore (`string[]`, default\n `[]`)\n- `spaces_per_tab`: Number of spaces for each hard tab (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered by any lines that contain hard tab characters instead\nof using spaces for indentation. To fix this, replace any hard tab characters\nwith spaces instead.\n\nExample:\n\n\n\n```markdown\nSome text\n\n\t* hard tab character used to indent the list item\n```\n\n\n\nCorrected example:\n\n```markdown\nSome text\n\n * Spaces used to indent the list item instead\n```\n\nYou have the option to exclude this rule for code blocks and spans. To do so,\nset the `code_blocks` parameter to `false`. Code blocks and spans are included\nby default since handling of tabs by Markdown tools can be inconsistent (e.g.,\nusing 4 vs. 8 spaces).\n\nWhen code blocks are scanned (e.g., by default or if `code_blocks` is `true`),\nthe `ignore_code_languages` parameter can be set to a list of languages that\nshould be ignored (i.e., hard tabs will be allowed, though not required). This\nmakes it easier for documents to include code for languages that require hard\ntabs.\n\nBy default, violations of this rule are fixed by replacing the tab with 1 space\ncharacter. To use a different number of spaces, set the `spaces_per_tab`\nparameter to the desired value.\n\nRationale: Hard tabs are often rendered inconsistently by different editors and\ncan be harder to work with than spaces.\n\nMore information:\n\n- \n- \n\n\n\n## `MD011` - Reversed link syntax\n\nTags: `links`\n\nAliases: `no-reversed-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when text that appears to be a link is encountered, but\nwhere the syntax appears to have been reversed (the `[]` and `()` are\nreversed):\n\n```markdown\n(Incorrect link syntax)[https://www.example.com/]\n```\n\nTo fix this, swap the `[]` and `()` around:\n\n```markdown\n[Correct link syntax](https://www.example.com/)\n```\n\nNote: [Markdown Extra](https://wikipedia.org/wiki/Markdown_Extra)-style\nfootnotes do not trigger this rule:\n\n```markdown\nFor (example)[^1]\n```\n\nRationale: Reversed links are not rendered as usable links.\n\n\n\n## `MD012` - Multiple consecutive blank lines\n\nTags: `blank_lines`, `whitespace`\n\nAliases: `no-multiple-blanks`\n\nParameters:\n\n- `maximum`: Consecutive blank lines (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are multiple consecutive blank lines in the\ndocument:\n\n```markdown\nSome text here\n\n\nSome more text here\n```\n\nTo fix this, delete the offending lines:\n\n```markdown\nSome text here\n\nSome more text here\n```\n\nNote: this rule will not be triggered if there are multiple consecutive blank\nlines inside code blocks.\n\nNote: The `maximum` parameter can be used to configure the maximum number of\nconsecutive blank lines.\n\nRationale: Except in a code block, blank lines serve no purpose and do not\naffect the rendering of content.\n\n\n\n## `MD013` - Line length\n\nTags: `line_length`\n\nAliases: `line-length`\n\nParameters:\n\n- `code_block_line_length`: Number of characters for code blocks (`integer`,\n default `80`)\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `heading_line_length`: Number of characters for headings (`integer`, default\n `80`)\n- `headings`: Include headings (`boolean`, default `true`)\n- `line_length`: Number of characters (`integer`, default `80`)\n- `stern`: Stern length checking (`boolean`, default `false`)\n- `strict`: Strict length checking (`boolean`, default `false`)\n- `tables`: Include tables (`boolean`, default `true`)\n\nThis rule is triggered when there are lines that are longer than the\nconfigured `line_length` (default: 80 characters). To fix this, split the line\nup into multiple lines. To set a different maximum length for headings, use\n`heading_line_length`. To set a different maximum length for code blocks, use\n`code_block_line_length`\n\nThis rule has an exception when there is no whitespace beyond the configured\nline length. This allows you to include items such as long URLs without being\nforced to break them in the middle. To disable this exception, set the `strict`\nparameter to `true` and an issue will be reported when any line is too long. To\nwarn for lines that are too long and could be fixed but allow long lines\nwithout spaces, set the `stern` parameter to `true`.\n\nFor example (assuming normal behavior):\n\n```markdown\nIF THIS LINE IS THE MAXIMUM LENGTH\nThis line is okay because there are-no-spaces-beyond-that-length\nThis line is a violation because there are spaces beyond that length\nThis-line-is-okay-because-there-are-no-spaces-anywhere-within\n```\n\nIn `strict` mode, the last three lines above are all violations. In `stern`\nmode, the middle two lines above are both violations, but the last is okay.\n\nYou have the option to exclude this rule for code blocks, tables, or headings.\nTo do so, set the `code_blocks`, `tables`, or `headings` parameter(s) to false.\n\nCode blocks are included in this rule by default since it is often a\nrequirement for document readability, and tentatively compatible with code\nrules. Still, some languages do not lend themselves to short lines.\n\nLines with link/image reference definitions and standalone lines (i.e., not part\nof a paragraph) with only a link/image (possibly using (strong) emphasis) are\nalways exempted from this rule (even in `strict` mode) because there is often no\nway to split such lines without breaking the URL.\n\nRationale: Extremely long lines can be difficult to work with in some editors.\nMore information: .\n\n\n\n## `MD014` - Dollar signs used before commands without showing output\n\nTags: `code`\n\nAliases: `commands-show-output`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are code blocks showing shell commands to be\ntyped, and *all* of the shell commands are preceded by dollar signs ($):\n\n\n\n```markdown\n$ ls\n$ cat foo\n$ less bar\n```\n\n\n\nThe dollar signs are unnecessary in this situation, and should not be\nincluded:\n\n```markdown\nls\ncat foo\nless bar\n```\n\nShowing output for commands preceded by dollar signs does not trigger this rule:\n\n```markdown\n$ ls\nfoo bar\n$ cat foo\nHello world\n$ cat bar\nbaz\n```\n\nBecause some commands do not produce output, it is not a violation if *some*\ncommands do not have output:\n\n```markdown\n$ mkdir test\nmkdir: created directory 'test'\n$ ls test\n```\n\nRationale: It is easier to copy/paste and less noisy if the dollar signs\nare omitted when they are not needed. See\n\nfor more information.\n\n\n\n## `MD018` - No space after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-missing-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing after the hash characters\nin an atx style heading:\n\n```markdown\n#Heading 1\n\n##Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD019` - Multiple spaces after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-multiple-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in an atx style heading:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD020` - No space inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-missing-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing inside the hash characters\nin a closed atx style heading:\n\n```markdown\n#Heading 1#\n\n##Heading 2##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading is missing spaces.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD021` - Multiple spaces inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-multiple-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in a closed atx style heading:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading contains multiple\nspaces.\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD022` - Headings should be surrounded by blank lines\n\nTags: `blank_lines`, `headings`\n\nAliases: `blanks-around-headings`\n\nParameters:\n\n- `include_front_matter`: Include front matter content (`boolean`, default\n `false`)\n- `lines_above`: Blank lines above heading (`integer|integer[]`, default `1`)\n- `lines_below`: Blank lines below heading (`integer|integer[]`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when headings (any style) are either not preceded or not\nfollowed by at least one blank line:\n\n```markdown\n# Heading 1\nSome text\n\nSome more text\n## Heading 2\n```\n\nTo fix this, ensure that all headings have a blank line both before and after\n(except where the heading is at the beginning or end of the document):\n\n```markdown\n# Heading 1\n\nSome text\n\nSome more text\n\n## Heading 2\n```\n\nThe `lines_above` and `lines_below` parameters can be used to specify a\ndifferent number of blank lines (including `0`) above or below each heading.\nIf the value `-1` is used for either parameter, any number of blank lines is\nallowed. To customize the number of lines above or below each heading level\nindividually, specify a `number[]` where values correspond to heading levels\n1-6 (in order).\n\nNotes: If `lines_above` or `lines_below` are configured to require more than one\nblank line, [MD012/no-multiple-blanks](md012.md) should also be customized. This\nrule checks for *at least* as many blank lines as specified; any extra blank\nlines are ignored.\n\nBy default, [YAML](https://wikipedia.org/wiki/YAML) front matter is ignored, so\nthe following document reports no violations:\n\n```markdown\n---\ntitle: Title\n---\n## Heading\n```\n\nTo require the configured number of blank lines between front matter content and\na document's first heading, set the `include_front_matter` parameter to `true`.\n\nRationale: Aside from aesthetic reasons, some parsers, including `kramdown`,\nwill not parse headings that don't have a blank line before, and will parse them\nas regular text.\n\n\n\n## `MD023` - Headings must start at the beginning of the line\n\nTags: `headings`, `spaces`\n\nAliases: `heading-start-left`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a heading is indented by one or more spaces:\n\n```markdown\nSome text\n\n # Indented heading\n```\n\nTo fix this, ensure that all headings start at the beginning of the line:\n\n```markdown\nSome text\n\n# Heading\n```\n\nNote that scenarios like block quotes \"indent\" the start of the line, so the\nfollowing is also correct:\n\n```markdown\n> # Heading in Block Quote\n```\n\nRationale: Headings that don't start at the beginning of the line will not be\nparsed as headings, and will instead appear as regular text.\n\n\n\n## `MD024` - Multiple headings with the same content\n\nTags: `headings`\n\nAliases: `no-duplicate-heading`\n\nParameters:\n\n- `siblings_only`: Only check sibling headings (`boolean`, default `false`)\n\nThis rule is triggered if there are multiple headings in the document that have\nthe same text:\n\n```markdown\n# Some text\n\n## Some text\n```\n\nTo fix this, ensure that the content of each heading is different:\n\n```markdown\n# Some text\n\n## Some more text\n```\n\nIf the parameter `siblings_only` is set to `true`, duplication is allowed for\nheadings with different parents (as is common in changelogs):\n\n```markdown\n# Change log\n\n## 1.0.0\n\n### Features\n\n## 2.0.0\n\n### Features\n```\n\nRationale: Some Markdown parsers generate anchors for headings based on the\nheading name; headings with the same content can cause problems with that.\n\n\n\n## `MD025` - Multiple top-level headings in the same document\n\nTags: `headings`\n\nAliases: `single-h1`, `single-title`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is triggered when a top-level heading is in use (the first line of\nthe file is an h1 heading), and more than one h1 heading is in use in the\ndocument:\n\n```markdown\n# Top level heading\n\n# Another top-level heading\n```\n\nTo fix, structure your document so there is a single h1 heading that is\nthe title for the document. Subsequent headings must be\nlower-level headings (h2, h3, etc.):\n\n```markdown\n# Title\n\n## Heading\n\n## Another heading\n```\n\nNote: The `level` parameter can be used to change the top-level (ex: to h2) in\ncases where an h1 is added externally.\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation for any subsequent\ntop-level headings. To use a different property name in the front matter,\nspecify the text of a regular expression via the `front_matter_title` parameter.\nTo disable the use of front matter by this rule, specify `\"\"` for\n`front_matter_title`.\n\nRationale: A top-level heading is an h1 on the first line of the file, and\nserves as the title for the document. If this convention is in use, then there\ncan not be more than one title for the document, and the entire document should\nbe contained within this heading.\n\n\n\n## `MD026` - Trailing punctuation in heading\n\nTags: `headings`\n\nAliases: `no-trailing-punctuation`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!。，；：！`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any heading that has one of the specified normal or\nfull-width punctuation characters as the last character in the line:\n\n```markdown\n# This is a heading.\n```\n\nTo fix this, remove the trailing punctuation:\n\n```markdown\n# This is a heading\n```\n\nNote: The `punctuation` parameter can be used to specify what characters count\nas punctuation at the end of a heading. For example, you can change it to\n`\".,;:\"` to allow headings that end with an exclamation point. `?` is\nallowed by default because of how common it is in headings of FAQ-style\ndocuments. Setting the `punctuation` parameter to `\"\"` allows all characters -\nand is equivalent to disabling the rule.\n\nNote: The trailing semicolon of [HTML entity references][html-entity-references]\nlike `©`, `©`, and `©` is ignored by this rule.\n\nRationale: Headings are not meant to be full sentences. More information:\n[Punctuation at the end of headers][end-punctuation].\n\n[end-punctuation]: https://cirosantilli.com/markdown-style-guide#punctuation-at-the-end-of-headers\n[html-entity-references]: https://wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references\n\n\n\n## `MD027` - Multiple spaces after blockquote symbol\n\nTags: `blockquote`, `indentation`, `whitespace`\n\nAliases: `no-multiple-space-blockquote`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when blockquotes have more than one space after the\nblockquote (`>`) symbol:\n\n```markdown\n> This is a blockquote with bad indentation\n> there should only be one.\n```\n\nTo fix, remove any extraneous space:\n\n```markdown\n> This is a blockquote with correct\n> indentation.\n```\n\nInferring intended list indentation within a blockquote can be challenging;\nsetting the `list_items` parameter to `false` disables this rule for ordered\nand unordered list items.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD028` - Blank line inside blockquote\n\nTags: `blockquote`, `whitespace`\n\nAliases: `no-blanks-blockquote`\n\nThis rule is triggered when two blockquote blocks are separated by nothing\nbut a blank line:\n\n```markdown\n> This is a blockquote\n> which is immediately followed by\n\n> this blockquote. In some cases,\n> these may be merged into one blockquote.\n```\n\nTo fix this, ensure that consecutive blockquotes have text (or an HTML comment)\nin between:\n\n```markdown\n> This is a blockquote.\n\nThis is paragraph text.\n\n> This is a second blockquote.\n\n\n\n> This is a third blockquote.\n```\n\nIf they are meant to be a single quote, add the blockquote symbol at the\nbeginning of the blank line:\n\n```markdown\n> This is a blockquote.\n>\n> This is the same blockquote.\n```\n\nRationale: Some Markdown parsers will treat two blockquotes separated by one\nor more blank lines as the same blockquote, while others will treat them as\nseparate blockquotes.\n\n\n\n## `MD029` - Ordered list item prefix\n\nTags: `ol`\n\nAliases: `ol-prefix`\n\nParameters:\n\n- `style`: List style (`string`, default `one_or_ordered`, values `one` /\n `one_or_ordered` / `ordered` / `zero`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for ordered lists that do not either start with '1.' or\ndo not have a prefix that increases in numerical order (depending on the\nconfigured style). The less-common pattern of using '0.' as a first prefix or\nfor all prefixes is also supported.\n\nExample valid list if the style is configured as 'one':\n\n```markdown\n1. Do this.\n1. Do that.\n1. Done.\n```\n\nExamples of valid lists if the style is configured as 'ordered':\n\n```markdown\n1. Do this.\n2. Do that.\n3. Done.\n```\n\n```markdown\n0. Do this.\n1. Do that.\n2. Done.\n```\n\nAll three examples are valid when the style is configured as 'one_or_ordered'.\n\nExample valid list if the style is configured as 'zero':\n\n```markdown\n0. Do this.\n0. Do that.\n0. Done.\n```\n\nExample invalid list for all styles:\n\n```markdown\n1. Do this.\n3. Done.\n```\n\nThis rule supports 0-prefixing list items for uniform indentation and will\npreserve that when fixing:\n\n```markdown\n...\n08. Item\n09. Item\n10. Item\n11. Item\n```\n\nWhen list items appear to be right-aligned, fixes will maintain that alignment:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n```\n\nNote: This rule will report violations for cases like the following where an\nimproperly-indented code block (or similar) appears between two list items and\n\"breaks\" the list in two:\n\n\n\n~~~markdown\n1. First list\n\n```text\nCode block\n```\n\n1. Second list\n~~~\n\nThe fix is to indent the code block so it becomes part of the preceding list\nitem as intended:\n\n~~~markdown\n1. First list\n\n ```text\n Code block\n ```\n\n2. Still first list\n~~~\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD030` - Spaces after list markers\n\nTags: `ol`, `ul`, `whitespace`\n\nAliases: `list-marker-space`\n\nParameters:\n\n- `ol_multi`: Spaces for multi-line ordered list items (`integer`, default `1`)\n- `ol_single`: Spaces for single-line ordered list items (`integer`, default\n `1`)\n- `ul_multi`: Spaces for multi-line unordered list items (`integer`, default\n `1`)\n- `ul_single`: Spaces for single-line unordered list items (`integer`, default\n `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule checks for the number of spaces between a list marker (e.g. '`-`',\n'`*`', '`+`' or '`1.`') and the text of the list item.\n\nThe number of spaces checked for depends on the document style in use, but the\ndefault is 1 space after any list marker:\n\n```markdown\n* Foo\n* Bar\n* Baz\n\n1. Foo\n1. Bar\n1. Baz\n\n1. Foo\n * Bar\n1. Baz\n```\n\nA document style may change the number of spaces after unordered list items\nand ordered list items independently, as well as based on whether the content\nof every item in the list consists of a single paragraph or multiple\nparagraphs (including sub-lists and code blocks).\n\nFor example, the style guide at\n\nspecifies that 1 space after the list marker should be used if every item in\nthe list fits within a single paragraph, but to use 2 or 3 spaces (for ordered\nand unordered lists respectively) if there are multiple paragraphs of content\ninside the list:\n\n```markdown\n* Foo\n* Bar\n* Baz\n```\n\nvs.\n\n```markdown\n* Foo\n\n Second paragraph\n\n* Bar\n```\n\nor\n\n```markdown\n1. Foo\n\n Second paragraph\n\n1. Bar\n```\n\nTo fix this, ensure the correct number of spaces are used after the list marker\nfor your selected document style.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n\n\n## `MD031` - Fenced code blocks should be surrounded by blank lines\n\nTags: `blank_lines`, `code`\n\nAliases: `blanks-around-fences`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when fenced code blocks are either not preceded or not\nfollowed by a blank line:\n\n````markdown\nSome text\n```\nCode block\n```\n\n```\nAnother code block\n```\nSome more text\n````\n\nTo fix this, ensure that all fenced code blocks have a blank line both before\nand after (except where the block is at the beginning or end of the document):\n\n````markdown\nSome text\n\n```\nCode block\n```\n\n```\nAnother code block\n```\n\nSome more text\n````\n\nSet the `list_items` parameter to `false` to disable this rule for list items.\nDisabling this behavior for lists can be useful if it is necessary to create a\n[tight](https://spec.commonmark.org/0.29/#tight) list containing a code fence.\n\nRationale: Aside from aesthetic reasons, some parsers, including kramdown, will\nnot parse fenced code blocks that don't have blank lines before and after them.\n\n\n\n## `MD032` - Lists should be surrounded by blank lines\n\nTags: `blank_lines`, `bullet`, `ol`, `ul`\n\nAliases: `blanks-around-lists`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when lists (of any kind) are either not preceded or not\nfollowed by a blank line:\n\n```markdown\nSome text\n* List item\n* List item\n\n1. List item\n2. List item\n***\n```\n\nIn the first case above, text immediately precedes the unordered list. In the\nsecond case above, a thematic break immediately follows the ordered list. To fix\nviolations of this rule, ensure that all lists have a blank line both before and\nafter (except when the list is at the very beginning or end of the document):\n\n```markdown\nSome text\n\n* List item\n* List item\n\n1. List item\n2. List item\n\n***\n```\n\nNote that the following case is **not** a violation of this rule:\n\n```markdown\n1. List item\n More item 1\n2. List item\nMore item 2\n```\n\nAlthough it is not indented, the text \"More item 2\" is referred to as a\n[lazy continuation line][lazy-continuation] and considered part of the second\nlist item.\n\nRationale: In addition to aesthetic reasons, some parsers, including kramdown,\nwill not parse lists that don't have blank lines before and after them.\n\n[lazy-continuation]: https://spec.commonmark.org/0.30/#lazy-continuation-line\n\n\n\n## `MD033` - Inline HTML\n\nTags: `html`\n\nAliases: `no-inline-html`\n\nParameters:\n\n- `allowed_elements`: Allowed elements (`string[]`, default `[]`)\n- `table_allowed_elements`: Allowed elements in tables (`string[]`, default\n `[]`)\n\nThis rule is triggered whenever raw HTML is used in a Markdown document:\n\n```markdown\n

Inline HTML heading

\n```\n\nTo fix this, use 'pure' Markdown instead of including raw HTML:\n\n```markdown\n# Markdown heading\n```\n\nTo allow specific HTML elements anywhere in Markdown content, set the\n`allowed_elements` parameter to a list of HTML element names. To allow a\nspecific set of HTML elements within Markdown tables, set the\n`table_allowed_elements` parameter to a list of HTML element names. This can be\nused to permit the use of `
`-style line breaks only within Markdown tables.\n\nRationale: Raw HTML is allowed in Markdown, but this rule is included for\nthose who want their documents to only include \"pure\" Markdown, or for those\nwho are rendering Markdown documents into something other than HTML.\n\n\n\n## `MD034` - Bare URL used\n\nTags: `links`, `url`\n\nAliases: `no-bare-urls`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered whenever a URL or email address appears without\nsurrounding angle brackets:\n\n```markdown\nFor more info, visit https://www.example.com/ or email user@example.com.\n```\n\nTo fix this, add angle brackets around the URL or email address:\n\n```markdown\nFor more info, visit or email .\n```\n\nIf a URL or email address contains non-ASCII characters, it may be not be\nhandled as intended even when angle brackets are present. In such cases,\n[percent-encoding](https://wikipedia.org/wiki/Percent-encoding) can be used\nto comply with the required syntax for URL and email.\n\nNote: To include a bare URL or email without it being converted into a link,\nwrap it in a code span:\n\n```markdown\nNot a clickable link: `https://www.example.com`\n```\n\nNote: The following scenario does not trigger this rule because it could be a\nshortcut link:\n\n```markdown\n[https://www.example.com]\n```\n\nNote: The following syntax triggers this rule because the nested link could be\na shortcut link (which takes precedence):\n\n```markdown\n[text [shortcut] text](https://example.com)\n```\n\nTo avoid this, escape both inner brackets:\n\n```markdown\n[link \\[text\\] link](https://example.com)\n```\n\nRationale: Without angle brackets, a bare URL or email isn't converted into a\nlink by some Markdown parsers.\n\n\n\n## `MD035` - Horizontal rule style\n\nTags: `hr`\n\nAliases: `hr-style`\n\nParameters:\n\n- `style`: Horizontal rule style (`string`, default `consistent`)\n\nThis rule is triggered when inconsistent styles of horizontal rules (also known\nas \"thematic breaks\") are used in a document:\n\n```markdown\n---\n\n- - -\n\n***\n\n* * *\n\n****\n```\n\nTo fix this, use the same horizontal rule syntax everywhere:\n\n```markdown\n---\n\n---\n\n---\n```\n\nThe `style` parameter's default value `consistent` ensures all horizontal rules\nin a document match the first horizontal rule in that document. To enforce a\nspecific pattern of characters, set the `style` parameter to that string (e.g.,\n`\"* * *\"`).\n\nNote: In order to be recognized as a horizontal rule, a line must contain three\nor more matching `-`, `_`, or `*` characters with optional space between.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD036` - Emphasis used instead of a heading\n\nTags: `emphasis`, `headings`\n\nAliases: `no-emphasis-as-heading`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!?。，；：！？`)\n\nThis check looks for instances where emphasized (i.e. bold or italic) text is\nused to separate sections, where a heading should be used instead:\n\n```markdown\n**My document**\n\nLorem ipsum dolor sit amet...\n\n_Another section_\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nTo fix this, use Markdown headings instead of emphasized text to denote\nsections:\n\n```markdown\n# My document\n\nLorem ipsum dolor sit amet...\n\n## Another section\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nNote: This rule looks for single-line paragraphs that consist entirely\nof emphasized text. It won't fire on emphasis used within regular text,\nmulti-line emphasized paragraphs, or paragraphs ending in punctuation\n(normal or full-width). Similarly to rule MD026, you can configure what\ncharacters are recognized as punctuation.\n\nRationale: Using emphasis instead of a heading prevents tools from inferring\nthe structure of a document. More information:\n.\n\n\n\n## `MD037` - Spaces inside emphasis markers\n\nTags: `emphasis`, `whitespace`\n\nAliases: `no-space-in-emphasis`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when emphasis markers (bold, italic) are used, but they\nhave spaces between the markers and the text:\n\n```markdown\nHere is some ** bold ** text.\n\nHere is some * italic * text.\n\nHere is some more __ bold __ text.\n\nHere is some more _ italic _ text.\n```\n\nTo fix this, remove the spaces around the emphasis markers:\n\n```markdown\nHere is some **bold** text.\n\nHere is some *italic* text.\n\nHere is some more __bold__ text.\n\nHere is some more _italic_ text.\n```\n\nRationale: Emphasis is only parsed as such when the asterisks/underscores\naren't surrounded by spaces. This rule attempts to detect where\nthey were surrounded by spaces, but it appears that emphasized text was\nintended by the author.\n\n\n\n## `MD038` - Spaces inside code span elements\n\nTags: `code`, `whitespace`\n\nAliases: `no-space-in-code`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for code spans containing content with unnecessary space\nnext to the beginning or ending backticks:\n\n```markdown\n`some text `\n\n` some text`\n\n` some text `\n```\n\nTo fix this, remove the extra space characters from the beginning and ending:\n\n```markdown\n`some text`\n```\n\nNote: A single leading *and* trailing space is allowed by the specification and\ntrimmed by the parser to support code spans that begin or end with a backtick:\n\n```markdown\n`` `backticks` ``\n\n`` backtick` ``\n```\n\nNote: When single-space padding is present in the input, it will be preserved\n(even if unnecessary):\n\n```markdown\n` code `\n```\n\nNote: Code spans containing only spaces are allowed by the specification and are\nalso preserved:\n\n```markdown\n` `\n\n` `\n```\n\nRationale: Violations of this rule are usually unintentional and can lead to\nimproperly-rendered content.\n\n\n\n## `MD039` - Spaces inside link text\n\nTags: `links`, `whitespace`\n\nAliases: `no-space-in-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on links that have spaces surrounding the link text:\n\n```markdown\n[ a link ](https://www.example.com/)\n```\n\nTo fix this, remove the spaces surrounding the link text:\n\n```markdown\n[a link](https://www.example.com/)\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD040` - Fenced code blocks should have a language specified\n\nTags: `code`, `language`\n\nAliases: `fenced-code-language`\n\nParameters:\n\n- `allowed_languages`: List of languages (`string[]`, default `[]`)\n- `language_only`: Require language only (`boolean`, default `false`)\n\nThis rule is triggered when fenced code blocks are used, but a language isn't\nspecified:\n\n````markdown\n```\n#!/bin/bash\necho Hello world\n```\n````\n\nTo fix this, add a language specifier to the code block:\n\n````markdown\n```bash\n#!/bin/bash\necho Hello world\n```\n````\n\nTo display a code block without syntax highlighting, use:\n\n````markdown\n```text\nPlain text in a code block\n```\n````\n\nYou can configure the `allowed_languages` parameter to specify a list of\nlanguages code blocks could use. Languages are case sensitive. The default value\nis `[]` which means any language specifier is valid.\n\nYou can prevent extra data from being present in the info string of fenced code\nblocks. To do so, set the `language_only` parameter to `true`.\n\n\nInfo strings with leading/trailing whitespace (ex: `js `) or other content (ex:\n`ruby startline=3`) will trigger this rule.\n\nRationale: Specifying a language improves content rendering by using the\ncorrect syntax highlighting for code. More information:\n.\n\n\n\n## `MD041` - First line in a file should be a top-level heading\n\nTags: `headings`\n\nAliases: `first-line-h1`, `first-line-heading`\n\nParameters:\n\n- `allow_preamble`: Allow content before first heading (`boolean`, default\n `false`)\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is intended to ensure documents have a title and is triggered when\nthe first line in a document is not a top-level ([HTML][HTML] `h1`) heading:\n\n```markdown\nThis is a document without a heading\n```\n\nTo fix this, add a top-level heading to the beginning of the document:\n\n```markdown\n# Document Heading\n\nThis is a document with a top-level heading\n```\n\nBecause it is common for projects on GitHub to use an image for the heading of\n`README.md` and that pattern is not well-supported by Markdown, HTML headings\nare also permitted by this rule. For example:\n\n```markdown\n

\n\nThis is a document with a top-level HTML heading\n```\n\nIn some cases, a document's title heading may be preceded by text like a table\nof contents. This is not ideal for accessibility, but can be allowed by setting\nthe `allow_preamble` parameter to `true`.\n\n```markdown\nThis is a document with preamble text\n\n# Document Heading\n```\n\nIf [YAML][YAML] front matter is present and contains a `title` property\n(commonly used with blog posts), this rule will not report a violation. To use a\ndifferent property name in the front matter, specify the text of a [regular\nexpression][RegExp] via the `front_matter_title` parameter. To disable the use\nof front matter by this rule, specify `\"\"` for `front_matter_title`.\n\nThe `level` parameter can be used to change the top-level heading (ex: to `h2`)\nin cases where an `h1` is added externally.\n\nRationale: The top-level heading often acts as the title of a document. More\ninformation: .\n\n[HTML]: https://wikipedia.org/wiki/HTML\n[RegExp]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n[YAML]: https://wikipedia.org/wiki/YAML\n\n\n\n## `MD042` - No empty links\n\nTags: `links`\n\nAliases: `no-empty-links`\n\nThis rule is triggered when an empty link is encountered:\n\n```markdown\n[an empty link]()\n```\n\nTo fix the violation, provide a destination for the link:\n\n```markdown\n[a valid link](https://example.com/)\n```\n\nEmpty fragments will trigger this rule:\n\n```markdown\n[an empty fragment](#)\n\n[an empty link definition][empty]\n\n[empty]: #\n```\n\nBut non-empty fragments will not:\n\n```markdown\n[a valid fragment](#fragment)\n```\n\nEmpty link definitions\n\nRationale: Empty links do not lead anywhere and therefore don't function as\nlinks.\n\n\n\n## `MD043` - Required heading structure\n\nTags: `headings`\n\nAliases: `required-headings`\n\nParameters:\n\n- `headings`: List of headings (`string[]`, default `[]`)\n- `match_case`: Match case of headings (`boolean`, default `false`)\n\nThis rule is triggered when the headings in a file do not match the array of\nheadings passed to the rule. It can be used to enforce a standard heading\nstructure for a set of files.\n\nTo require exactly the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail\n```\n\nSet the `headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"### Detail\"\n]\n```\n\nTo allow optional headings as with the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail (optional)\n## Foot\n### Notes (optional)\n```\n\nUse the special value `\"*\"` meaning \"zero or more unspecified headings\" or the\nspecial value `\"+\"` meaning \"one or more unspecified headings\" and set the\n`headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"*\",\n \"## Foot\",\n \"*\"\n]\n```\n\nTo allow a single required heading to vary as with a project name:\n\n```markdown\n# Project Name\n## Description\n## Examples\n```\n\nUse the special value `\"?\"` meaning \"exactly one unspecified heading\":\n\n```json\n[\n \"?\",\n \"## Description\",\n \"## Examples\"\n]\n```\n\nWhen an error is detected, this rule outputs the line number of the first\nproblematic heading (otherwise, it outputs the last line number of the file).\n\nNote that while the `headings` parameter uses the \"## Text\" ATX heading style\nfor simplicity, a file may use any supported heading style.\n\nBy default, the case of headings in the document is not required to match that\nof `headings`. To require that case match exactly, set the `match_case`\nparameter to `true`.\n\nRationale: Projects may wish to enforce a consistent document structure across\na set of similar content.\n\n\n\n## `MD044` - Proper names should have the correct capitalization\n\nTags: `spelling`\n\nAliases: `proper-names`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `html_elements`: Include HTML elements (`boolean`, default `true`)\n- `names`: List of proper names (`string[]`, default `[]`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when any of the strings in the `names` array do not have\nthe specified capitalization. It can be used to enforce a standard letter case\nfor the names of projects and products.\n\nFor example, the language \"JavaScript\" is usually written with both the 'J' and\n'S' capitalized - though sometimes the 's' or 'j' appear in lower-case. To\nenforce the proper capitalization, specify the desired letter case in the\n`names` array:\n\n```json\n[\n \"JavaScript\"\n]\n```\n\nSometimes a proper name is capitalized differently in certain contexts. In such\ncases, add both forms to the `names` array:\n\n```json\n[\n \"GitHub\",\n \"github.com\"\n]\n```\n\nSet the `code_blocks` parameter to `false` to disable this rule for code blocks\nand spans. Set the `html_elements` parameter to `false` to disable this rule\nfor HTML elements and attributes (such as when using a proper name as part of\na path for `a`/`href` or `img`/`src`).\n\nRationale: Incorrect capitalization of proper names is usually a mistake.\n\n\n\n## `MD045` - Images should have alternate text (alt text)\n\nTags: `accessibility`, `images`\n\nAliases: `no-alt-text`\n\nThis rule reports a violation when an image is missing alternate text (alt text)\ninformation.\n\nAlternate text is commonly specified inline as:\n\n```markdown\n![Alternate text](image.jpg)\n```\n\nOr with reference syntax as:\n\n```markdown\n![Alternate text][ref]\n\n...\n\n[ref]: image.jpg \"Optional title\"\n```\n\nOr with HTML as:\n\n```html\n\"Alternate\n```\n\nNote: If the [HTML `aria-hidden` attribute][aria-hidden] is used to hide the\nimage from assistive technology, this rule does not report a violation:\n\n```html\n\n```\n\nGuidance for writing alternate text is available from the [W3C][w3c],\n[Wikipedia][wikipedia], and [other locations][phase2technology].\n\nRationale: Alternate text is important for accessibility and describes the\ncontent of an image for people who may not be able to see it.\n\n[aria-hidden]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-hidden\n[phase2technology]: https://www.phase2technology.com/blog/no-more-excuses\n[w3c]: https://www.w3.org/WAI/alt/\n[wikipedia]: https://wikipedia.org/wiki/Alt_attribute\n\n\n\n## `MD046` - Code block style\n\nTags: `code`\n\nAliases: `code-block-style`\n\nParameters:\n\n- `style`: Block style (`string`, default `consistent`, values `consistent` /\n `fenced` / `indented`)\n\nThis rule is triggered when unwanted or different code block styles are used in\nthe same document.\n\nIn the default configuration this rule reports a violation for the following\ndocument:\n\n\n\n Some text.\n\n # Indented code\n\n More text.\n\n ```ruby\n # Fenced code\n ```\n\n More text.\n\n\n\nTo fix violations of this rule, use a consistent style (either indenting or code\nfences).\n\nThe configured code block style can be specific (`fenced`, `indented`) or can\nrequire all code blocks match the first code block (`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD047` - Files should end with a single newline character\n\nTags: `blank_lines`\n\nAliases: `single-trailing-newline`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there is not a single newline character at the end\nof a file.\n\nAn example that triggers the rule:\n\n```markdown\n# Heading\n\nThis file ends without a newline.[EOF]\n```\n\nTo fix the violation, add a newline character to the end of the file:\n\n```markdown\n# Heading\n\nThis file ends with a newline.\n[EOF]\n```\n\nRationale: Some programs have trouble with files that do not end with a newline.\n\nMore information: [What's the point in adding a new line to the end of a\nfile?][stack-exchange]\n\n[stack-exchange]: https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file\n\n\n\n## `MD048` - Code fence style\n\nTags: `code`\n\nAliases: `code-fence-style`\n\nParameters:\n\n- `style`: Code fence style (`string`, default `consistent`, values `backtick`\n / `consistent` / `tilde`)\n\nThis rule is triggered when the symbols used in the document for fenced code\nblocks do not match the configured code fence style:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n~~~ruby\n# Fenced code\n~~~\n````\n\nTo fix this issue, use the configured code fence style throughout the\ndocument:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n```ruby\n# Fenced code\n```\n````\n\nThe configured code fence style can be a specific symbol to use (`backtick`,\n`tilde`) or it can require all code fences match the first code fence\n(`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD049` - Emphasis style\n\nTags: `emphasis`\n\nAliases: `emphasis-style`\n\nParameters:\n\n- `style`: Emphasis style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for emphasis do not\nmatch the configured emphasis style:\n\n```markdown\n*Text*\n_Text_\n```\n\nTo fix this issue, use the configured emphasis style throughout the document:\n\n```markdown\n*Text*\n*Text*\n```\n\nThe configured emphasis style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all emphasis matches the first emphasis\n(`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like_this_one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD050` - Strong style\n\nTags: `emphasis`\n\nAliases: `strong-style`\n\nParameters:\n\n- `style`: Strong style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for strong do not\nmatch the configured strong style:\n\n```markdown\n**Text**\n__Text__\n```\n\nTo fix this issue, use the configured strong style throughout the document:\n\n```markdown\n**Text**\n**Text**\n```\n\nThe configured strong style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all strong matches the first strong (`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like__this__one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD051` - Link fragments should be valid\n\nTags: `links`\n\nAliases: `link-fragments`\n\nParameters:\n\n- `ignore_case`: Ignore case of fragments (`boolean`, default `false`)\n- `ignored_pattern`: Pattern for ignoring additional fragments (`string`,\n default ``)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a link fragment does not match any of the fragments\nthat are automatically generated for headings in a document:\n\n```markdown\n# Heading Name\n\n[Link](#fragment)\n```\n\nTo fix this issue, change the link fragment to reference an existing heading's\ngenerated name (see below):\n\n```markdown\n# Heading Name\n\n[Link](#heading-name)\n```\n\nFor consistency, this rule requires fragments to exactly match the [GitHub\nheading algorithm][github-heading-algorithm] which converts letters to\nlowercase. Therefore, the following example is reported as a violation:\n\n```markdown\n# Heading Name\n\n[Link](#Heading-Name)\n```\n\nTo ignore case when comparing fragments with heading names, the `ignore_case`\nparameter can be set to `true`. In this configuration, the previous example is\nnot reported as a violation.\n\nAlternatively, some platforms allow the syntax `{#named-anchor}` to be used\nwithin a heading to provide a specific name (consisting of only lower-case\nletters, numbers, `-`, and `_`):\n\n```markdown\n# Heading Name {#custom-name}\n\n[Link](#custom-name)\n```\n\nAlternatively, any HTML tag with an `id` attribute or an `a` tag with a `name`\nattribute can be used to define a fragment:\n\n```markdown\n\n\n[Link](#bookmark)\n```\n\nAn `a` tag can be useful in scenarios where a heading is not appropriate or for\ncontrol over the text of the fragment identifier.\n\n[HTML links to `#top` scroll to the top of a document][html-top-fragment]. This\nrule allows that syntax (using lower-case for consistency):\n\n```markdown\n[Link](#top)\n```\n\nThis rule also recognizes the custom fragment syntax used by GitHub to highlight\n[specific content in a document][github-linking-to-content].\n\nFor example, this link to line 20:\n\n```markdown\n[Link](#L20)\n```\n\nAnd this link to content starting within line 19 running into line 21:\n\n```markdown\n[Link](#L19C5-L21C11)\n```\n\nSome Markdown generators dynamically create and insert headings when building\ndocuments, for example by combining a fixed prefix like `figure-` and an\nincrementing numeric counter. To ignore such generated fragments, set the\n`ignored_pattern` [regular expression][RegEx] parameter to a pattern that\nmatches (e.g., `^figure-`).\n\nRationale: [GitHub section links][github-section-links] are created\nautomatically for every heading when Markdown content is displayed on GitHub.\nThis makes it easy to link directly to different sections within a document.\nHowever, section links change if headings are renamed or removed. This rule\nhelps identify broken section links within a document.\n\nNote: Section links are **not** part of the CommonMark specification; this rule\nenforces the [GitHub heading algorithm][github-heading-algorithm]:\n\n1. Convert text to lowercase\n2. Remove punctuation characters\n3. Convert spaces to dashes\n4. Append an incrementing integer (as needed for uniqueness)\n5. [URI-encode][encodeURIComponent] the result\n\n[encodeURIComponent]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent\n[github-section-links]: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#section-links\n[github-heading-algorithm]: https://github.com/gjtorikian/html-pipeline/blob/f13a1534cb650ba17af400d1acd3a22c28004c09/lib/html/pipeline/toc_filter.rb\n[github-linking-to-content]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet#linking-to-markdown\n[html-top-fragment]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment\n[RegEx]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n\n\n\n## `MD052` - Reference links and images should use a label that is defined\n\nTags: `images`, `links`\n\nAliases: `reference-links-images`\n\nParameters:\n\n- `ignored_labels`: Ignored link labels (`string[]`, default `[\"x\"]`)\n- `shortcut_syntax`: Include shortcut syntax (`boolean`, default `false`)\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can define it elsewhere and use a label for reference.\nThe reference format is convenient for keeping paragraph text clutter-free\nand makes it easy to reuse the same URL in multiple places.\n\nThere are three kinds of reference links and images:\n\n```markdown\nFull: [text][label]\nCollapsed: [label][]\nShortcut: [label]\n\nFull: ![text][image]\nCollapsed: ![image][]\nShortcut: ![image]\n\n[label]: https://example.com/label\n[image]: https://example.com/image\n```\n\nA link or image renders correctly when the corresponding label is defined, but\ndisplays as text with brackets when the label is not present. By default, this\nrule warns of undefined labels for \"full\" and \"collapsed\" reference syntax but\nnot for \"shortcut\" syntax because it is ambiguous.\n\nThe text `[example]` could be a shortcut link or the text \"example\" in brackets,\nso \"shortcut\" syntax is ignored by default. To include \"shortcut\" syntax, set\nthe `include_shortcut` parameter to `true`. Note that doing so produces warnings\nfor *all* text in the document that *could* be a shortcut. If bracketed text is\nintentional, brackets can be escaped with the `\\` character: `\\[example\\]`.\n\nIf there are link labels that are deliberately unreferenced, they can be ignored\nby setting the `ignored_labels` parameter to the list of strings to ignore. The\ndefault value of this parameter ignores the checkbox syntax used by\n[GitHub Flavored Markdown task list items][gfm-tasklist]:\n\n```markdown\n- [x] Checked task list item\n```\n\n[gfm-tasklist]: https://github.github.com/gfm/#task-list-items-extension-\n\n\n\n## `MD053` - Link and image reference definitions should be needed\n\nTags: `images`, `links`\n\nAliases: `link-image-reference-definitions`\n\nParameters:\n\n- `ignored_definitions`: Ignored definitions (`string[]`, default `[\"//\"]`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can use a label to reference a definition elsewhere in\nthe document. The latter reference format is convenient for keeping paragraph\ntext clutter-free and makes it easy to reuse the same URL in multiple places.\n\nBecause link and image reference definitions are located separately from\nwhere they are used, there are two scenarios where a definition can be\nunnecessary:\n\n1. If a label is not referenced by any link or image in a document, that\n definition is unused and can be deleted.\n2. If a label is defined multiple times in a document, the first definition is\n used and the others can be deleted.\n\nThis rule considers a reference definition to be used if any link or image\nreference has the corresponding label. The \"full\", \"collapsed\", and \"shortcut\"\nformats are all supported.\n\nIf there are reference definitions that are deliberately unreferenced, they can\nbe ignored by setting the `ignored_definitions` parameter to the list of strings\nto ignore. The default value of this parameter ignores the following convention\nfor adding non-HTML comments to Markdown:\n\n```markdown\n[//]: # (This behaves like a comment)\n```\n\n\n\n## `MD054` - Link and image style\n\nTags: `images`, `links`\n\nAliases: `link-image-style`\n\nParameters:\n\n- `autolink`: Allow autolinks (`boolean`, default `true`)\n- `collapsed`: Allow collapsed reference links and images (`boolean`, default\n `true`)\n- `full`: Allow full reference links and images (`boolean`, default `true`)\n- `inline`: Allow inline links and images (`boolean`, default `true`)\n- `shortcut`: Allow shortcut reference links and images (`boolean`, default\n `true`)\n- `url_inline`: Allow URLs as inline links (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source at\nthe time of use or can use a label to reference a definition elsewhere in the\ndocument. The three reference formats are convenient for keeping paragraph text\nclutter-free and make it easy to reuse the same URL in multiple places.\n\nBy default, this rule allows all link/image styles.\n\nSetting the `autolink` parameter to `false` disables autolinks:\n\n```markdown\n\n```\n\nSetting the `inline` parameter to `false` disables inline links and images:\n\n```markdown\n[link](https://example.com)\n\n![image](https://example.com)\n```\n\nSetting the `full` parameter to `false` disables full reference links and\nimages:\n\n```markdown\n[link][url]\n\n![image][url]\n\n[url]: https://example.com\n```\n\nSetting the `collapsed` parameter to `false` disables collapsed reference links\nand images:\n\n```markdown\n[url][]\n\n![url][]\n\n[url]: https://example.com\n```\n\nSetting the `shortcut` parameter to `false` disables shortcut reference links\nand images:\n\n```markdown\n[url]\n\n![url]\n\n[url]: https://example.com\n```\n\nTo fix violations of this rule, change the link or image to use an allowed\nstyle. This rule can automatically fix violations when a link or image can be\nconverted to the `inline` style (preferred) or a link can be converted to the\n`autolink` style (which does not support images and must be an absolute URL).\nThis rule does *not* fix scenarios that require converting a link or image to\nthe `full`, `collapsed`, or `shortcut` reference styles because that involves\nnaming the reference and determining where to insert it in the document.\n\nSetting the `url_inline` parameter to `false` prevents the use of inline links\nwith the same absolute URL text/destination and no title because such links can\nbe converted to autolinks:\n\n```markdown\n[https://example.com](https://example.com)\n```\n\nTo fix `url_inline` violations, use the simpler autolink syntax instead:\n\n```markdown\n\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\nAutolinks are concise, but appear as URLs which can be long and confusing.\nInline links and images can include descriptive text, but take up more space in\nMarkdown form. Reference links and images can be easier to read and manipulate\nin Markdown form, but require a separate link reference definition.\n\n\n\n## `MD055` - Table pipe style\n\nTags: `table`\n\nAliases: `table-pipe-style`\n\nParameters:\n\n- `style`: Table pipe style (`string`, default `consistent`, values\n `consistent` / `leading_and_trailing` / `leading_only` /\n `no_leading_or_trailing` / `trailing_only`)\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-055]\nis inconsistent about its use of leading and trailing pipe characters (`|`).\n\nBy default (`consistent` style), the header row of the first table in a document\nis used to determine the style that is enforced for every table in the document.\nA specific style can be used instead (`leading_and_trailing`, `leading_only`,\n`no_leading_or_trailing`, `trailing_only`).\n\nThis table's header row has leading and trailing pipes, but its delimiter row is\nmissing the trailing pipe and its first row of cells is missing the leading\npipe:\n\n```markdown\n| Header | Header |\n| ------ | ------\n Cell | Cell |\n```\n\nTo fix these issues, make sure there is a pipe character at the beginning and\nend of every row:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and may also\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table\n```\n\nRationale: Some parsers have difficulty with tables that are missing their\nleading or trailing pipe characters. The use of leading/trailing pipes can also\nhelp provide visual clarity.\n\n[gfm-table-055]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD056` - Table column count\n\nTags: `table`\n\nAliases: `table-column-count`\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-056]\ndoes not have the same number of cells in every row.\n\nThis table's second data row has too few cells and its third data row has too\nmany cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell |\n| Cell | Cell | Cell |\n```\n\nTo fix these issues, ensure every row has the same number of cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell | Cell |\n| Cell | Cell |\n```\n\nNote that a table's header row and its delimiter row must have the same number\nof cells or it will not be recognized as a table (per specification).\n\nRationale: Extra cells in a row are usually not shown, so their data is lost.\nMissing cells in a row create holes in the table and suggest an omission.\n\n[gfm-table-056]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD058` - Tables should be surrounded by blank lines\n\nTags: `table`\n\nAliases: `blanks-around-tables`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when tables are either not preceded or not followed by a\nblank line:\n\n```markdown\nSome text\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n> Blockquote\n```\n\nTo fix violations of this rule, ensure that all tables have a blank line both\nbefore and after (except when the table is at the very beginning or end of the\ndocument):\n\n```markdown\nSome text\n\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n\n> Blockquote\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and will not\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table and the next line is blank\n\nSome text\n```\n\nRationale: In addition to aesthetic reasons, some parsers will incorrectly parse\ntables that don't have blank lines before and after them.\n\n\n\n## `MD059` - Link text should be descriptive\n\nTags: `accessibility`, `links`\n\nAliases: `descriptive-link-text`\n\nParameters:\n\n- `prohibited_texts`: Prohibited link texts (`string[]`, default `[\"click\n here\",\"here\",\"link\",\"more\"]`)\n\nThis rule is triggered when a link has generic text like `[click here](...)` or\n`[link](...)`.\n\nLink text should be descriptive and communicate the purpose of the link (e.g.,\n`[Download the budget document](...)` or `[CommonMark Specification](...)`).\nThis is especially important for screen readers which sometimes present links\nwithout context.\n\nBy default, this rule prohibits a small number of common English words/phrases.\nTo customize that list of words/phrases, set the `prohibited_texts` parameter to\nan `Array` of `string`s.\n\nNote: For languages other than English, use the `prohibited_texts` parameter to\ncustomize the list for that language. It is *not* a goal for this rule to have\ntranslations for every language.\n\nNote: This rule checks Markdown links; HTML links are ignored.\n\nMore information:\n\n- \n- \n\n\n\n## `MD060` - Table column style\n\nTags: `table`\n\nAliases: `table-column-style`\n\nParameters:\n\n- `aligned_delimiter`: Aligned delimiter columns (`boolean`, default `false`)\n- `style`: Table column style (`string`, default `any`, values `aligned` /\n `any` / `compact` / `tight`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the column separator pipe characters (`|`) of a\n[GitHub Flavored Markdown table][gfm-table-060] are used inconsistently.\n\nThis rule recognizes three table column styles based on popular use.\n\nStyle `aligned` ensures pipe characters are vertically aligned:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nThe `aligned` style ignores cell content, so the following is also valid:\n\n```markdown\n| Character | Meaning |\n|-----------|---------|\n| Y | Yes |\n| N | No |\n```\n\nStyle `compact` avoids extra padding with a single space around cell content:\n\n```markdown\n| Character | Meaning |\n| --- | --- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` uses no padding at all for cell content:\n\n```markdown\n|Character|Meaning|\n|---|---|\n|Y|Yes|\n|N|No|\n```\n\nWhen this rule's `style` parameter is set to `aligned`, `compact`, or `tight`,\nevery table must match the corresponding pattern and any violations will be\nreported. By default, or when the `any` style is used, each table is analyzed to\nsee if it satisfies any supported style. If so, no violations are reported. If\nnot, violations are be reported for whichever style would produce the *fewest*\nissues (i.e., whichever style is the closest match).\n\nSetting the `aligned_delimiter` parameter to `true` requires pipe characters in\nthe delimiter row to align with those in the header row. This can be used with\n`compact` and `tight` tables to make the header text more obvious. (It's already\nrequired for tables with style `aligned`.)\n\nStyle `compact` with `aligned_delimiter`:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` with `aligned_delimiter`:\n\n```markdown\n|Character|Meaning|\n|---------|-------|\n|Y|Yes|\n|N|No|\n```\n\nViolations for styles `compact` and `tight` are simple/independent and can be\nfixed automatically. However, fixing even single violations for style `aligned`\nmay require modifying the entire table, and therefore are not automatic:\n\n```markdown\n|Alpha |Delta|\n|------|-----|\n|Charlie|Beta|\n```\n\n**Note**: This rule does not require leading/trailing pipe characters, so this\nis also a valid table for style `compact`:\n\n```markdown\nCharacter | Meaning\n--- | ---\nY | Yes\nN | No\n```\n\n**Note**: Pipe alignment for the `aligned` style is based on visual appearance\nand not character count. Because editors typically render [emoji][emoji] and\n[CJK characters][cjk-characters] at *twice* the width of\n[Latin characters][latin-script], this rule takes that into account for tables\nusing the `aligned` style. The following table is correctly formatted and will\nappear aligned in most editors and monospaced fonts:\n\n\n\n\n```markdown\n| Response | Emoji |\n| -------- | ----- |\n| Yes | ✅ |\n| No | ❎ |\n```\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n[cjk-characters]: https://wikipedia.org/wiki/CJK_characters\n[emoji]: https://wikipedia.org/wiki/Emoji\n[gfm-table-060]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n[latin-script]: https://wikipedia.org/wiki/Latin_script\n\n\n","isInternal":false,"tokens":18278,"sizeBytes":73137}],"systemPromptSnippet":"\n\n\n# Rules\n\nThis document contains a description of all rules, what they are checking for,\nas well as examples of documents that break the rule and corrected\nversions of the examples.\n\n\n\n## `MD001` - Heading levels should only increment by one level at a time\n\nTags: `headings`\n\nAliases: `heading-increment`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n\nThis rule is triggered when you skip heading levels in a Markdown document, for\nexample:\n\n```markdown\n# Heading 1\n\n### Heading 3\n\nWe skipped out a 2nd level heading in this document\n```\n\nWhen using multiple heading levels, nested headings should increase by only one\nlevel at a time:\n\n```markdown\n# Heading 1\n\n## Heading 2\n\n### Heading 3\n\n#### Heading 4\n\n## Another Heading 2\n\n### Another Heading 3\n```\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation if the actual first\nheading is not a level 2 heading. To use a different property name in the\nfront matter, specify the text of a regular expression via the\n`front_matter_title` parameter. To disable the use of front matter by this\nrule, specify `\"\"` for `front_matter_title`. When front matter is not present,\nthe first heading can be any level.\n\nRationale: Headings represent the structure of a document and can be confusing\nwhen skipped - especially for accessibility scenarios. More information:\n.\n\n\n\n## `MD003` - Heading style\n\nTags: `headings`\n\nAliases: `heading-style`\n\nParameters:\n\n- `style`: Heading style (`string`, default `consistent`, values `atx` /\n `atx_closed` / `consistent` / `setext` / `setext_with_atx` /\n `setext_with_atx_closed`)\n\nThis rule is triggered when different heading styles are used in the same\ndocument:\n\n```markdown\n# ATX style H1\n\n## Closed ATX style H2 ##\n\nSetext style H1\n===============\n```\n\nTo fix the issue, use consistent heading styles throughout the document:\n\n```markdown\n# ATX style H1\n\n## ATX style H2\n```\n\nThe `setext_with_atx` and `setext_with_atx_closed` settings allow ATX-style\nheadings of level 3 or more in documents with setext-style headings (which only\nsupport level 1 and 2 headings):\n\n```markdown\nSetext style H1\n===============\n\nSetext style H2\n---------------\n\n### ATX style H3\n```\n\nNote: The configured heading style can be a specific style to require (`atx`,\n`atx_closed`, `setext`, `setext_with_atx`, `setext_with_atx_closed`), or can\nrequire that all heading styles match the first heading style via `consistent`.\n\nNote: The placement of a horizontal rule directly below a line of text can\ntrigger this rule by turning that text into a level 2 setext-style heading:\n\n```markdown\nA line of text followed by a horizontal rule becomes a heading\n---\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD004` - Unordered list style\n\nTags: `bullet`, `ul`\n\nAliases: `ul-style`\n\nParameters:\n\n- `style`: List style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `dash` / `plus` / `sublist`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for unordered\nlist items do not match the configured unordered list style:\n\n```markdown\n* Item 1\n+ Item 2\n- Item 3\n```\n\nTo fix this issue, use the configured style for list items throughout the\ndocument:\n\n```markdown\n* Item 1\n* Item 2\n* Item 3\n```\n\nThe configured list style can ensure all list styling is a specific symbol\n(`asterisk`, `plus`, `dash`), ensure each sublist has a consistent symbol that\ndiffers from its parent list (`sublist`), or ensure all list styles match the\nfirst list style (`consistent`).\n\nFor example, the following is valid for the `sublist` style because the\nouter-most indent uses asterisk, the middle indent uses plus, and the inner-most\nindent uses dash:\n\n```markdown\n* Item 1\n + Item 2\n - Item 3\n + Item 4\n* Item 4\n + Item 5\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD005` - Inconsistent indentation for list items at the same level\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `list-indent`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are parsed as being at the same level,\nbut don't have the same indentation:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * A misaligned item\n```\n\nUsually, this rule will be triggered because of a typo. Correct the indentation\nfor the list to fix it:\n\n```markdown\n* Item 1\n * Nested Item 1\n * Nested Item 2\n * Nested Item 3\n```\n\nSequentially-ordered list markers are usually left-aligned such that all items\nhave the same starting column:\n\n```markdown\n...\n8. Item\n9. Item\n10. Item\n11. Item\n...\n```\n\nThis rule also supports right-alignment of list markers such that all items have\nthe same ending column:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n...\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD007` - Unordered list indentation\n\nTags: `bullet`, `indentation`, `ul`\n\nAliases: `ul-indent`\n\nParameters:\n\n- `indent`: Spaces for indent (`integer`, default `2`)\n- `start_indent`: Spaces for first level indent (when start_indented is set)\n (`integer`, default `2`)\n- `start_indented`: Whether to indent the first level of the list (`boolean`,\n default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when list items are not indented by the configured\nnumber of spaces (default: 2).\n\nExample:\n\n```markdown\n* List item\n * Nested list item indented by 3 spaces\n```\n\nCorrected Example:\n\n```markdown\n* List item\n * Nested list item indented by 2 spaces\n```\n\nNote: This rule applies to a sublist only if its parent lists are all also\nunordered (otherwise, extra indentation of ordered lists interferes with the\nrule).\n\nThe `start_indented` parameter allows the first level of lists to be indented by\nthe configured number of spaces rather than starting at zero. The `start_indent`\nparameter allows the first level of lists to be indented by a different number\nof spaces than the rest (ignored when `start_indented` is not set).\n\nRationale: Indenting by 2 spaces allows the content of a nested list to be in\nline with the start of the content of the parent list when a single space is\nused after the list marker. Indenting by 4 spaces is consistent with code blocks\nand simpler for editors to implement. Additionally, this can be a compatibility\nissue for other Markdown parsers, which require 4-space indents. More\ninformation: [Markdown Style Guide][markdown-style-guide].\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n[markdown-style-guide]: https://cirosantilli.com/markdown-style-guide#indentation-of-content-inside-lists\n\n\n\n## `MD009` - Trailing spaces\n\nTags: `whitespace`\n\nAliases: `no-trailing-spaces`\n\nParameters:\n\n- `br_spaces`: Spaces for line break (`integer`, default `2`)\n- `code_blocks`: Include code blocks (`boolean`, default `false`)\n- `list_item_empty_lines`: Allow spaces for empty lines in list items\n (`boolean`, default `false`)\n- `strict`: Include unnecessary breaks (`boolean`, default `false`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any lines that end with unexpected whitespace. To fix\nthis, remove the trailing space from the end of the line.\n\nThe `br_spaces` parameter allows an exception to this rule for a specific number\nof trailing spaces, typically used to insert an explicit line break. The default\nvalue allows 2 spaces to indicate a hard break (\\
element). (You must set\n`br_spaces` to a value >= 2 for this parameter to take effect. Setting\n`br_spaces` to 1 behaves the same as 0, disallowing any trailing spaces.)\n\nBy default, trailing space is allowed in indented and fenced code blocks because\nsome programming languages require that. To report such instances, set the\n`code_blocks` parameter to `true`.\n\nBy default, this rule will not trigger when the allowed number of spaces is\nused, even when it doesn't create a hard break (for example, at the end of a\nparagraph). To report such instances, set the `strict` parameter to `true`.\n\n```markdown\nText text text\ntext[2 spaces]\n```\n\nUsing spaces to indent blank lines inside a list item is usually not necessary,\nbut some parsers require it. Set the `list_item_empty_lines` parameter to `true`\nto allow this (even when `strict` is `true`):\n\n```markdown\n- list item text\n [2 spaces]\n list item text\n```\n\nRationale: Except when being used to create a line break, trailing whitespace\nhas no purpose and does not affect the rendering of content.\n\n\n\n## `MD010` - Hard tabs\n\nTags: `hard_tab`, `whitespace`\n\nAliases: `no-hard-tabs`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `ignore_code_languages`: Fenced code languages to ignore (`string[]`, default\n `[]`)\n- `spaces_per_tab`: Number of spaces for each hard tab (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered by any lines that contain hard tab characters instead\nof using spaces for indentation. To fix this, replace any hard tab characters\nwith spaces instead.\n\nExample:\n\n\n\n```markdown\nSome text\n\n\t* hard tab character used to indent the list item\n```\n\n\n\nCorrected example:\n\n```markdown\nSome text\n\n * Spaces used to indent the list item instead\n```\n\nYou have the option to exclude this rule for code blocks and spans. To do so,\nset the `code_blocks` parameter to `false`. Code blocks and spans are included\nby default since handling of tabs by Markdown tools can be inconsistent (e.g.,\nusing 4 vs. 8 spaces).\n\nWhen code blocks are scanned (e.g., by default or if `code_blocks` is `true`),\nthe `ignore_code_languages` parameter can be set to a list of languages that\nshould be ignored (i.e., hard tabs will be allowed, though not required). This\nmakes it easier for documents to include code for languages that require hard\ntabs.\n\nBy default, violations of this rule are fixed by replacing the tab with 1 space\ncharacter. To use a different number of spaces, set the `spaces_per_tab`\nparameter to the desired value.\n\nRationale: Hard tabs are often rendered inconsistently by different editors and\ncan be harder to work with than spaces.\n\nMore information:\n\n- \n- \n\n\n\n## `MD011` - Reversed link syntax\n\nTags: `links`\n\nAliases: `no-reversed-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when text that appears to be a link is encountered, but\nwhere the syntax appears to have been reversed (the `[]` and `()` are\nreversed):\n\n```markdown\n(Incorrect link syntax)[https://www.example.com/]\n```\n\nTo fix this, swap the `[]` and `()` around:\n\n```markdown\n[Correct link syntax](https://www.example.com/)\n```\n\nNote: [Markdown Extra](https://wikipedia.org/wiki/Markdown_Extra)-style\nfootnotes do not trigger this rule:\n\n```markdown\nFor (example)[^1]\n```\n\nRationale: Reversed links are not rendered as usable links.\n\n\n\n## `MD012` - Multiple consecutive blank lines\n\nTags: `blank_lines`, `whitespace`\n\nAliases: `no-multiple-blanks`\n\nParameters:\n\n- `maximum`: Consecutive blank lines (`integer`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are multiple consecutive blank lines in the\ndocument:\n\n```markdown\nSome text here\n\n\nSome more text here\n```\n\nTo fix this, delete the offending lines:\n\n```markdown\nSome text here\n\nSome more text here\n```\n\nNote: this rule will not be triggered if there are multiple consecutive blank\nlines inside code blocks.\n\nNote: The `maximum` parameter can be used to configure the maximum number of\nconsecutive blank lines.\n\nRationale: Except in a code block, blank lines serve no purpose and do not\naffect the rendering of content.\n\n\n\n## `MD013` - Line length\n\nTags: `line_length`\n\nAliases: `line-length`\n\nParameters:\n\n- `code_block_line_length`: Number of characters for code blocks (`integer`,\n default `80`)\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `heading_line_length`: Number of characters for headings (`integer`, default\n `80`)\n- `headings`: Include headings (`boolean`, default `true`)\n- `line_length`: Number of characters (`integer`, default `80`)\n- `stern`: Stern length checking (`boolean`, default `false`)\n- `strict`: Strict length checking (`boolean`, default `false`)\n- `tables`: Include tables (`boolean`, default `true`)\n\nThis rule is triggered when there are lines that are longer than the\nconfigured `line_length` (default: 80 characters). To fix this, split the line\nup into multiple lines. To set a different maximum length for headings, use\n`heading_line_length`. To set a different maximum length for code blocks, use\n`code_block_line_length`\n\nThis rule has an exception when there is no whitespace beyond the configured\nline length. This allows you to include items such as long URLs without being\nforced to break them in the middle. To disable this exception, set the `strict`\nparameter to `true` and an issue will be reported when any line is too long. To\nwarn for lines that are too long and could be fixed but allow long lines\nwithout spaces, set the `stern` parameter to `true`.\n\nFor example (assuming normal behavior):\n\n```markdown\nIF THIS LINE IS THE MAXIMUM LENGTH\nThis line is okay because there are-no-spaces-beyond-that-length\nThis line is a violation because there are spaces beyond that length\nThis-line-is-okay-because-there-are-no-spaces-anywhere-within\n```\n\nIn `strict` mode, the last three lines above are all violations. In `stern`\nmode, the middle two lines above are both violations, but the last is okay.\n\nYou have the option to exclude this rule for code blocks, tables, or headings.\nTo do so, set the `code_blocks`, `tables`, or `headings` parameter(s) to false.\n\nCode blocks are included in this rule by default since it is often a\nrequirement for document readability, and tentatively compatible with code\nrules. Still, some languages do not lend themselves to short lines.\n\nLines with link/image reference definitions and standalone lines (i.e., not part\nof a paragraph) with only a link/image (possibly using (strong) emphasis) are\nalways exempted from this rule (even in `strict` mode) because there is often no\nway to split such lines without breaking the URL.\n\nRationale: Extremely long lines can be difficult to work with in some editors.\nMore information: .\n\n\n\n## `MD014` - Dollar signs used before commands without showing output\n\nTags: `code`\n\nAliases: `commands-show-output`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there are code blocks showing shell commands to be\ntyped, and *all* of the shell commands are preceded by dollar signs ($):\n\n\n\n```markdown\n$ ls\n$ cat foo\n$ less bar\n```\n\n\n\nThe dollar signs are unnecessary in this situation, and should not be\nincluded:\n\n```markdown\nls\ncat foo\nless bar\n```\n\nShowing output for commands preceded by dollar signs does not trigger this rule:\n\n```markdown\n$ ls\nfoo bar\n$ cat foo\nHello world\n$ cat bar\nbaz\n```\n\nBecause some commands do not produce output, it is not a violation if *some*\ncommands do not have output:\n\n```markdown\n$ mkdir test\nmkdir: created directory 'test'\n$ ls test\n```\n\nRationale: It is easier to copy/paste and less noisy if the dollar signs\nare omitted when they are not needed. See\n\nfor more information.\n\n\n\n## `MD018` - No space after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-missing-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing after the hash characters\nin an atx style heading:\n\n```markdown\n#Heading 1\n\n##Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD019` - Multiple spaces after hash on atx style heading\n\nTags: `atx`, `headings`, `spaces`\n\nAliases: `no-multiple-space-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in an atx style heading:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1\n\n## Heading 2\n```\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD020` - No space inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-missing-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when spaces are missing inside the hash characters\nin a closed atx style heading:\n\n```markdown\n#Heading 1#\n\n##Heading 2##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading is missing spaces.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\n\n\n## `MD021` - Multiple spaces inside hashes on closed atx style heading\n\nTags: `atx_closed`, `headings`, `spaces`\n\nAliases: `no-multiple-space-closed-atx`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when more than one space is used to separate the\nheading text from the hash characters in a closed atx style heading:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nTo fix this, separate the heading text from the hash character by a single\nspace:\n\n```markdown\n# Heading 1 #\n\n## Heading 2 ##\n```\n\nNote: this rule will fire if either side of the heading contains multiple\nspaces.\n\nRationale: Extra space has no purpose and does not affect the rendering of\ncontent.\n\n\n\n## `MD022` - Headings should be surrounded by blank lines\n\nTags: `blank_lines`, `headings`\n\nAliases: `blanks-around-headings`\n\nParameters:\n\n- `include_front_matter`: Include front matter content (`boolean`, default\n `false`)\n- `lines_above`: Blank lines above heading (`integer|integer[]`, default `1`)\n- `lines_below`: Blank lines below heading (`integer|integer[]`, default `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when headings (any style) are either not preceded or not\nfollowed by at least one blank line:\n\n```markdown\n# Heading 1\nSome text\n\nSome more text\n## Heading 2\n```\n\nTo fix this, ensure that all headings have a blank line both before and after\n(except where the heading is at the beginning or end of the document):\n\n```markdown\n# Heading 1\n\nSome text\n\nSome more text\n\n## Heading 2\n```\n\nThe `lines_above` and `lines_below` parameters can be used to specify a\ndifferent number of blank lines (including `0`) above or below each heading.\nIf the value `-1` is used for either parameter, any number of blank lines is\nallowed. To customize the number of lines above or below each heading level\nindividually, specify a `number[]` where values correspond to heading levels\n1-6 (in order).\n\nNotes: If `lines_above` or `lines_below` are configured to require more than one\nblank line, [MD012/no-multiple-blanks](md012.md) should also be customized. This\nrule checks for *at least* as many blank lines as specified; any extra blank\nlines are ignored.\n\nBy default, [YAML](https://wikipedia.org/wiki/YAML) front matter is ignored, so\nthe following document reports no violations:\n\n```markdown\n---\ntitle: Title\n---\n## Heading\n```\n\nTo require the configured number of blank lines between front matter content and\na document's first heading, set the `include_front_matter` parameter to `true`.\n\nRationale: Aside from aesthetic reasons, some parsers, including `kramdown`,\nwill not parse headings that don't have a blank line before, and will parse them\nas regular text.\n\n\n\n## `MD023` - Headings must start at the beginning of the line\n\nTags: `headings`, `spaces`\n\nAliases: `heading-start-left`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a heading is indented by one or more spaces:\n\n```markdown\nSome text\n\n # Indented heading\n```\n\nTo fix this, ensure that all headings start at the beginning of the line:\n\n```markdown\nSome text\n\n# Heading\n```\n\nNote that scenarios like block quotes \"indent\" the start of the line, so the\nfollowing is also correct:\n\n```markdown\n> # Heading in Block Quote\n```\n\nRationale: Headings that don't start at the beginning of the line will not be\nparsed as headings, and will instead appear as regular text.\n\n\n\n## `MD024` - Multiple headings with the same content\n\nTags: `headings`\n\nAliases: `no-duplicate-heading`\n\nParameters:\n\n- `siblings_only`: Only check sibling headings (`boolean`, default `false`)\n\nThis rule is triggered if there are multiple headings in the document that have\nthe same text:\n\n```markdown\n# Some text\n\n## Some text\n```\n\nTo fix this, ensure that the content of each heading is different:\n\n```markdown\n# Some text\n\n## Some more text\n```\n\nIf the parameter `siblings_only` is set to `true`, duplication is allowed for\nheadings with different parents (as is common in changelogs):\n\n```markdown\n# Change log\n\n## 1.0.0\n\n### Features\n\n## 2.0.0\n\n### Features\n```\n\nRationale: Some Markdown parsers generate anchors for headings based on the\nheading name; headings with the same content can cause problems with that.\n\n\n\n## `MD025` - Multiple top-level headings in the same document\n\nTags: `headings`\n\nAliases: `single-h1`, `single-title`\n\nParameters:\n\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is triggered when a top-level heading is in use (the first line of\nthe file is an h1 heading), and more than one h1 heading is in use in the\ndocument:\n\n```markdown\n# Top level heading\n\n# Another top-level heading\n```\n\nTo fix, structure your document so there is a single h1 heading that is\nthe title for the document. Subsequent headings must be\nlower-level headings (h2, h3, etc.):\n\n```markdown\n# Title\n\n## Heading\n\n## Another heading\n```\n\nNote: The `level` parameter can be used to change the top-level (ex: to h2) in\ncases where an h1 is added externally.\n\nIf [YAML](https://wikipedia.org/wiki/YAML) front matter is present and\ncontains a `title` property (commonly used with blog posts), this rule treats\nthat as a top level heading and will report a violation for any subsequent\ntop-level headings. To use a different property name in the front matter,\nspecify the text of a regular expression via the `front_matter_title` parameter.\nTo disable the use of front matter by this rule, specify `\"\"` for\n`front_matter_title`.\n\nRationale: A top-level heading is an h1 on the first line of the file, and\nserves as the title for the document. If this convention is in use, then there\ncan not be more than one title for the document, and the entire document should\nbe contained within this heading.\n\n\n\n## `MD026` - Trailing punctuation in heading\n\nTags: `headings`\n\nAliases: `no-trailing-punctuation`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!。，；：！`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on any heading that has one of the specified normal or\nfull-width punctuation characters as the last character in the line:\n\n```markdown\n# This is a heading.\n```\n\nTo fix this, remove the trailing punctuation:\n\n```markdown\n# This is a heading\n```\n\nNote: The `punctuation` parameter can be used to specify what characters count\nas punctuation at the end of a heading. For example, you can change it to\n`\".,;:\"` to allow headings that end with an exclamation point. `?` is\nallowed by default because of how common it is in headings of FAQ-style\ndocuments. Setting the `punctuation` parameter to `\"\"` allows all characters -\nand is equivalent to disabling the rule.\n\nNote: The trailing semicolon of [HTML entity references][html-entity-references]\nlike `©`, `©`, and `©` is ignored by this rule.\n\nRationale: Headings are not meant to be full sentences. More information:\n[Punctuation at the end of headers][end-punctuation].\n\n[end-punctuation]: https://cirosantilli.com/markdown-style-guide#punctuation-at-the-end-of-headers\n[html-entity-references]: https://wikipedia.org/wiki/List_of_XML_and_HTML_character_entity_references\n\n\n\n## `MD027` - Multiple spaces after blockquote symbol\n\nTags: `blockquote`, `indentation`, `whitespace`\n\nAliases: `no-multiple-space-blockquote`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when blockquotes have more than one space after the\nblockquote (`>`) symbol:\n\n```markdown\n> This is a blockquote with bad indentation\n> there should only be one.\n```\n\nTo fix, remove any extraneous space:\n\n```markdown\n> This is a blockquote with correct\n> indentation.\n```\n\nInferring intended list indentation within a blockquote can be challenging;\nsetting the `list_items` parameter to `false` disables this rule for ordered\nand unordered list items.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD028` - Blank line inside blockquote\n\nTags: `blockquote`, `whitespace`\n\nAliases: `no-blanks-blockquote`\n\nThis rule is triggered when two blockquote blocks are separated by nothing\nbut a blank line:\n\n```markdown\n> This is a blockquote\n> which is immediately followed by\n\n> this blockquote. In some cases,\n> these may be merged into one blockquote.\n```\n\nTo fix this, ensure that consecutive blockquotes have text (or an HTML comment)\nin between:\n\n```markdown\n> This is a blockquote.\n\nThis is paragraph text.\n\n> This is a second blockquote.\n\n\n\n> This is a third blockquote.\n```\n\nIf they are meant to be a single quote, add the blockquote symbol at the\nbeginning of the blank line:\n\n```markdown\n> This is a blockquote.\n>\n> This is the same blockquote.\n```\n\nRationale: Some Markdown parsers will treat two blockquotes separated by one\nor more blank lines as the same blockquote, while others will treat them as\nseparate blockquotes.\n\n\n\n## `MD029` - Ordered list item prefix\n\nTags: `ol`\n\nAliases: `ol-prefix`\n\nParameters:\n\n- `style`: List style (`string`, default `one_or_ordered`, values `one` /\n `one_or_ordered` / `ordered` / `zero`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for ordered lists that do not either start with '1.' or\ndo not have a prefix that increases in numerical order (depending on the\nconfigured style). The less-common pattern of using '0.' as a first prefix or\nfor all prefixes is also supported.\n\nExample valid list if the style is configured as 'one':\n\n```markdown\n1. Do this.\n1. Do that.\n1. Done.\n```\n\nExamples of valid lists if the style is configured as 'ordered':\n\n```markdown\n1. Do this.\n2. Do that.\n3. Done.\n```\n\n```markdown\n0. Do this.\n1. Do that.\n2. Done.\n```\n\nAll three examples are valid when the style is configured as 'one_or_ordered'.\n\nExample valid list if the style is configured as 'zero':\n\n```markdown\n0. Do this.\n0. Do that.\n0. Done.\n```\n\nExample invalid list for all styles:\n\n```markdown\n1. Do this.\n3. Done.\n```\n\nThis rule supports 0-prefixing list items for uniform indentation and will\npreserve that when fixing:\n\n```markdown\n...\n08. Item\n09. Item\n10. Item\n11. Item\n```\n\nWhen list items appear to be right-aligned, fixes will maintain that alignment:\n\n```markdown\n...\n 8. Item\n 9. Item\n10. Item\n11. Item\n```\n\nNote: This rule will report violations for cases like the following where an\nimproperly-indented code block (or similar) appears between two list items and\n\"breaks\" the list in two:\n\n\n\n~~~markdown\n1. First list\n\n```text\nCode block\n```\n\n1. Second list\n~~~\n\nThe fix is to indent the code block so it becomes part of the preceding list\nitem as intended:\n\n~~~markdown\n1. First list\n\n ```text\n Code block\n ```\n\n2. Still first list\n~~~\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD030` - Spaces after list markers\n\nTags: `ol`, `ul`, `whitespace`\n\nAliases: `list-marker-space`\n\nParameters:\n\n- `ol_multi`: Spaces for multi-line ordered list items (`integer`, default `1`)\n- `ol_single`: Spaces for single-line ordered list items (`integer`, default\n `1`)\n- `ul_multi`: Spaces for multi-line unordered list items (`integer`, default\n `1`)\n- `ul_single`: Spaces for single-line unordered list items (`integer`, default\n `1`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule checks for the number of spaces between a list marker (e.g. '`-`',\n'`*`', '`+`' or '`1.`') and the text of the list item.\n\nThe number of spaces checked for depends on the document style in use, but the\ndefault is 1 space after any list marker:\n\n```markdown\n* Foo\n* Bar\n* Baz\n\n1. Foo\n1. Bar\n1. Baz\n\n1. Foo\n * Bar\n1. Baz\n```\n\nA document style may change the number of spaces after unordered list items\nand ordered list items independently, as well as based on whether the content\nof every item in the list consists of a single paragraph or multiple\nparagraphs (including sub-lists and code blocks).\n\nFor example, the style guide at\n\nspecifies that 1 space after the list marker should be used if every item in\nthe list fits within a single paragraph, but to use 2 or 3 spaces (for ordered\nand unordered lists respectively) if there are multiple paragraphs of content\ninside the list:\n\n```markdown\n* Foo\n* Bar\n* Baz\n```\n\nvs.\n\n```markdown\n* Foo\n\n Second paragraph\n\n* Bar\n```\n\nor\n\n```markdown\n1. Foo\n\n Second paragraph\n\n1. Bar\n```\n\nTo fix this, ensure the correct number of spaces are used after the list marker\nfor your selected document style.\n\nRationale: Violations of this rule can lead to improperly rendered content.\n\nNote: See [Prettier.md](Prettier.md) for compatibility information.\n\n\n\n## `MD031` - Fenced code blocks should be surrounded by blank lines\n\nTags: `blank_lines`, `code`\n\nAliases: `blanks-around-fences`\n\nParameters:\n\n- `list_items`: Include list items (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when fenced code blocks are either not preceded or not\nfollowed by a blank line:\n\n````markdown\nSome text\n```\nCode block\n```\n\n```\nAnother code block\n```\nSome more text\n````\n\nTo fix this, ensure that all fenced code blocks have a blank line both before\nand after (except where the block is at the beginning or end of the document):\n\n````markdown\nSome text\n\n```\nCode block\n```\n\n```\nAnother code block\n```\n\nSome more text\n````\n\nSet the `list_items` parameter to `false` to disable this rule for list items.\nDisabling this behavior for lists can be useful if it is necessary to create a\n[tight](https://spec.commonmark.org/0.29/#tight) list containing a code fence.\n\nRationale: Aside from aesthetic reasons, some parsers, including kramdown, will\nnot parse fenced code blocks that don't have blank lines before and after them.\n\n\n\n## `MD032` - Lists should be surrounded by blank lines\n\nTags: `blank_lines`, `bullet`, `ol`, `ul`\n\nAliases: `blanks-around-lists`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when lists (of any kind) are either not preceded or not\nfollowed by a blank line:\n\n```markdown\nSome text\n* List item\n* List item\n\n1. List item\n2. List item\n***\n```\n\nIn the first case above, text immediately precedes the unordered list. In the\nsecond case above, a thematic break immediately follows the ordered list. To fix\nviolations of this rule, ensure that all lists have a blank line both before and\nafter (except when the list is at the very beginning or end of the document):\n\n```markdown\nSome text\n\n* List item\n* List item\n\n1. List item\n2. List item\n\n***\n```\n\nNote that the following case is **not** a violation of this rule:\n\n```markdown\n1. List item\n More item 1\n2. List item\nMore item 2\n```\n\nAlthough it is not indented, the text \"More item 2\" is referred to as a\n[lazy continuation line][lazy-continuation] and considered part of the second\nlist item.\n\nRationale: In addition to aesthetic reasons, some parsers, including kramdown,\nwill not parse lists that don't have blank lines before and after them.\n\n[lazy-continuation]: https://spec.commonmark.org/0.30/#lazy-continuation-line\n\n\n\n## `MD033` - Inline HTML\n\nTags: `html`\n\nAliases: `no-inline-html`\n\nParameters:\n\n- `allowed_elements`: Allowed elements (`string[]`, default `[]`)\n- `table_allowed_elements`: Allowed elements in tables (`string[]`, default\n `[]`)\n\nThis rule is triggered whenever raw HTML is used in a Markdown document:\n\n```markdown\n

Inline HTML heading

\n```\n\nTo fix this, use 'pure' Markdown instead of including raw HTML:\n\n```markdown\n# Markdown heading\n```\n\nTo allow specific HTML elements anywhere in Markdown content, set the\n`allowed_elements` parameter to a list of HTML element names. To allow a\nspecific set of HTML elements within Markdown tables, set the\n`table_allowed_elements` parameter to a list of HTML element names. This can be\nused to permit the use of `
`-style line breaks only within Markdown tables.\n\nRationale: Raw HTML is allowed in Markdown, but this rule is included for\nthose who want their documents to only include \"pure\" Markdown, or for those\nwho are rendering Markdown documents into something other than HTML.\n\n\n\n## `MD034` - Bare URL used\n\nTags: `links`, `url`\n\nAliases: `no-bare-urls`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered whenever a URL or email address appears without\nsurrounding angle brackets:\n\n```markdown\nFor more info, visit https://www.example.com/ or email user@example.com.\n```\n\nTo fix this, add angle brackets around the URL or email address:\n\n```markdown\nFor more info, visit or email .\n```\n\nIf a URL or email address contains non-ASCII characters, it may be not be\nhandled as intended even when angle brackets are present. In such cases,\n[percent-encoding](https://wikipedia.org/wiki/Percent-encoding) can be used\nto comply with the required syntax for URL and email.\n\nNote: To include a bare URL or email without it being converted into a link,\nwrap it in a code span:\n\n```markdown\nNot a clickable link: `https://www.example.com`\n```\n\nNote: The following scenario does not trigger this rule because it could be a\nshortcut link:\n\n```markdown\n[https://www.example.com]\n```\n\nNote: The following syntax triggers this rule because the nested link could be\na shortcut link (which takes precedence):\n\n```markdown\n[text [shortcut] text](https://example.com)\n```\n\nTo avoid this, escape both inner brackets:\n\n```markdown\n[link \\[text\\] link](https://example.com)\n```\n\nRationale: Without angle brackets, a bare URL or email isn't converted into a\nlink by some Markdown parsers.\n\n\n\n## `MD035` - Horizontal rule style\n\nTags: `hr`\n\nAliases: `hr-style`\n\nParameters:\n\n- `style`: Horizontal rule style (`string`, default `consistent`)\n\nThis rule is triggered when inconsistent styles of horizontal rules (also known\nas \"thematic breaks\") are used in a document:\n\n```markdown\n---\n\n- - -\n\n***\n\n* * *\n\n****\n```\n\nTo fix this, use the same horizontal rule syntax everywhere:\n\n```markdown\n---\n\n---\n\n---\n```\n\nThe `style` parameter's default value `consistent` ensures all horizontal rules\nin a document match the first horizontal rule in that document. To enforce a\nspecific pattern of characters, set the `style` parameter to that string (e.g.,\n`\"* * *\"`).\n\nNote: In order to be recognized as a horizontal rule, a line must contain three\nor more matching `-`, `_`, or `*` characters with optional space between.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD036` - Emphasis used instead of a heading\n\nTags: `emphasis`, `headings`\n\nAliases: `no-emphasis-as-heading`\n\nParameters:\n\n- `punctuation`: Punctuation characters (`string`, default `.,;:!?。，；：！？`)\n\nThis check looks for instances where emphasized (i.e. bold or italic) text is\nused to separate sections, where a heading should be used instead:\n\n```markdown\n**My document**\n\nLorem ipsum dolor sit amet...\n\n_Another section_\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nTo fix this, use Markdown headings instead of emphasized text to denote\nsections:\n\n```markdown\n# My document\n\nLorem ipsum dolor sit amet...\n\n## Another section\n\nConsectetur adipiscing elit, sed do eiusmod.\n```\n\nNote: This rule looks for single-line paragraphs that consist entirely\nof emphasized text. It won't fire on emphasis used within regular text,\nmulti-line emphasized paragraphs, or paragraphs ending in punctuation\n(normal or full-width). Similarly to rule MD026, you can configure what\ncharacters are recognized as punctuation.\n\nRationale: Using emphasis instead of a heading prevents tools from inferring\nthe structure of a document. More information:\n.\n\n\n\n## `MD037` - Spaces inside emphasis markers\n\nTags: `emphasis`, `whitespace`\n\nAliases: `no-space-in-emphasis`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when emphasis markers (bold, italic) are used, but they\nhave spaces between the markers and the text:\n\n```markdown\nHere is some ** bold ** text.\n\nHere is some * italic * text.\n\nHere is some more __ bold __ text.\n\nHere is some more _ italic _ text.\n```\n\nTo fix this, remove the spaces around the emphasis markers:\n\n```markdown\nHere is some **bold** text.\n\nHere is some *italic* text.\n\nHere is some more __bold__ text.\n\nHere is some more _italic_ text.\n```\n\nRationale: Emphasis is only parsed as such when the asterisks/underscores\naren't surrounded by spaces. This rule attempts to detect where\nthey were surrounded by spaces, but it appears that emphasized text was\nintended by the author.\n\n\n\n## `MD038` - Spaces inside code span elements\n\nTags: `code`, `whitespace`\n\nAliases: `no-space-in-code`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered for code spans containing content with unnecessary space\nnext to the beginning or ending backticks:\n\n```markdown\n`some text `\n\n` some text`\n\n` some text `\n```\n\nTo fix this, remove the extra space characters from the beginning and ending:\n\n```markdown\n`some text`\n```\n\nNote: A single leading *and* trailing space is allowed by the specification and\ntrimmed by the parser to support code spans that begin or end with a backtick:\n\n```markdown\n`` `backticks` ``\n\n`` backtick` ``\n```\n\nNote: When single-space padding is present in the input, it will be preserved\n(even if unnecessary):\n\n```markdown\n` code `\n```\n\nNote: Code spans containing only spaces are allowed by the specification and are\nalso preserved:\n\n```markdown\n` `\n\n` `\n```\n\nRationale: Violations of this rule are usually unintentional and can lead to\nimproperly-rendered content.\n\n\n\n## `MD039` - Spaces inside link text\n\nTags: `links`, `whitespace`\n\nAliases: `no-space-in-links`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered on links that have spaces surrounding the link text:\n\n```markdown\n[ a link ](https://www.example.com/)\n```\n\nTo fix this, remove the spaces surrounding the link text:\n\n```markdown\n[a link](https://www.example.com/)\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD040` - Fenced code blocks should have a language specified\n\nTags: `code`, `language`\n\nAliases: `fenced-code-language`\n\nParameters:\n\n- `allowed_languages`: List of languages (`string[]`, default `[]`)\n- `language_only`: Require language only (`boolean`, default `false`)\n\nThis rule is triggered when fenced code blocks are used, but a language isn't\nspecified:\n\n````markdown\n```\n#!/bin/bash\necho Hello world\n```\n````\n\nTo fix this, add a language specifier to the code block:\n\n````markdown\n```bash\n#!/bin/bash\necho Hello world\n```\n````\n\nTo display a code block without syntax highlighting, use:\n\n````markdown\n```text\nPlain text in a code block\n```\n````\n\nYou can configure the `allowed_languages` parameter to specify a list of\nlanguages code blocks could use. Languages are case sensitive. The default value\nis `[]` which means any language specifier is valid.\n\nYou can prevent extra data from being present in the info string of fenced code\nblocks. To do so, set the `language_only` parameter to `true`.\n\n\nInfo strings with leading/trailing whitespace (ex: `js `) or other content (ex:\n`ruby startline=3`) will trigger this rule.\n\nRationale: Specifying a language improves content rendering by using the\ncorrect syntax highlighting for code. More information:\n.\n\n\n\n## `MD041` - First line in a file should be a top-level heading\n\nTags: `headings`\n\nAliases: `first-line-h1`, `first-line-heading`\n\nParameters:\n\n- `allow_preamble`: Allow content before first heading (`boolean`, default\n `false`)\n- `front_matter_title`: RegExp for matching title in front matter (`string`,\n default `^\\s*title\\s*[:=]`)\n- `level`: Heading level (`integer`, default `1`)\n\nThis rule is intended to ensure documents have a title and is triggered when\nthe first line in a document is not a top-level ([HTML][HTML] `h1`) heading:\n\n```markdown\nThis is a document without a heading\n```\n\nTo fix this, add a top-level heading to the beginning of the document:\n\n```markdown\n# Document Heading\n\nThis is a document with a top-level heading\n```\n\nBecause it is common for projects on GitHub to use an image for the heading of\n`README.md` and that pattern is not well-supported by Markdown, HTML headings\nare also permitted by this rule. For example:\n\n```markdown\n

\n\nThis is a document with a top-level HTML heading\n```\n\nIn some cases, a document's title heading may be preceded by text like a table\nof contents. This is not ideal for accessibility, but can be allowed by setting\nthe `allow_preamble` parameter to `true`.\n\n```markdown\nThis is a document with preamble text\n\n# Document Heading\n```\n\nIf [YAML][YAML] front matter is present and contains a `title` property\n(commonly used with blog posts), this rule will not report a violation. To use a\ndifferent property name in the front matter, specify the text of a [regular\nexpression][RegExp] via the `front_matter_title` parameter. To disable the use\nof front matter by this rule, specify `\"\"` for `front_matter_title`.\n\nThe `level` parameter can be used to change the top-level heading (ex: to `h2`)\nin cases where an `h1` is added externally.\n\nRationale: The top-level heading often acts as the title of a document. More\ninformation: .\n\n[HTML]: https://wikipedia.org/wiki/HTML\n[RegExp]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n[YAML]: https://wikipedia.org/wiki/YAML\n\n\n\n## `MD042` - No empty links\n\nTags: `links`\n\nAliases: `no-empty-links`\n\nThis rule is triggered when an empty link is encountered:\n\n```markdown\n[an empty link]()\n```\n\nTo fix the violation, provide a destination for the link:\n\n```markdown\n[a valid link](https://example.com/)\n```\n\nEmpty fragments will trigger this rule:\n\n```markdown\n[an empty fragment](#)\n\n[an empty link definition][empty]\n\n[empty]: #\n```\n\nBut non-empty fragments will not:\n\n```markdown\n[a valid fragment](#fragment)\n```\n\nEmpty link definitions\n\nRationale: Empty links do not lead anywhere and therefore don't function as\nlinks.\n\n\n\n## `MD043` - Required heading structure\n\nTags: `headings`\n\nAliases: `required-headings`\n\nParameters:\n\n- `headings`: List of headings (`string[]`, default `[]`)\n- `match_case`: Match case of headings (`boolean`, default `false`)\n\nThis rule is triggered when the headings in a file do not match the array of\nheadings passed to the rule. It can be used to enforce a standard heading\nstructure for a set of files.\n\nTo require exactly the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail\n```\n\nSet the `headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"### Detail\"\n]\n```\n\nTo allow optional headings as with the following structure:\n\n```markdown\n# Heading\n## Item\n### Detail (optional)\n## Foot\n### Notes (optional)\n```\n\nUse the special value `\"*\"` meaning \"zero or more unspecified headings\" or the\nspecial value `\"+\"` meaning \"one or more unspecified headings\" and set the\n`headings` parameter to:\n\n```json\n[\n \"# Heading\",\n \"## Item\",\n \"*\",\n \"## Foot\",\n \"*\"\n]\n```\n\nTo allow a single required heading to vary as with a project name:\n\n```markdown\n# Project Name\n## Description\n## Examples\n```\n\nUse the special value `\"?\"` meaning \"exactly one unspecified heading\":\n\n```json\n[\n \"?\",\n \"## Description\",\n \"## Examples\"\n]\n```\n\nWhen an error is detected, this rule outputs the line number of the first\nproblematic heading (otherwise, it outputs the last line number of the file).\n\nNote that while the `headings` parameter uses the \"## Text\" ATX heading style\nfor simplicity, a file may use any supported heading style.\n\nBy default, the case of headings in the document is not required to match that\nof `headings`. To require that case match exactly, set the `match_case`\nparameter to `true`.\n\nRationale: Projects may wish to enforce a consistent document structure across\na set of similar content.\n\n\n\n## `MD044` - Proper names should have the correct capitalization\n\nTags: `spelling`\n\nAliases: `proper-names`\n\nParameters:\n\n- `code_blocks`: Include code blocks (`boolean`, default `true`)\n- `html_elements`: Include HTML elements (`boolean`, default `true`)\n- `names`: List of proper names (`string[]`, default `[]`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when any of the strings in the `names` array do not have\nthe specified capitalization. It can be used to enforce a standard letter case\nfor the names of projects and products.\n\nFor example, the language \"JavaScript\" is usually written with both the 'J' and\n'S' capitalized - though sometimes the 's' or 'j' appear in lower-case. To\nenforce the proper capitalization, specify the desired letter case in the\n`names` array:\n\n```json\n[\n \"JavaScript\"\n]\n```\n\nSometimes a proper name is capitalized differently in certain contexts. In such\ncases, add both forms to the `names` array:\n\n```json\n[\n \"GitHub\",\n \"github.com\"\n]\n```\n\nSet the `code_blocks` parameter to `false` to disable this rule for code blocks\nand spans. Set the `html_elements` parameter to `false` to disable this rule\nfor HTML elements and attributes (such as when using a proper name as part of\na path for `a`/`href` or `img`/`src`).\n\nRationale: Incorrect capitalization of proper names is usually a mistake.\n\n\n\n## `MD045` - Images should have alternate text (alt text)\n\nTags: `accessibility`, `images`\n\nAliases: `no-alt-text`\n\nThis rule reports a violation when an image is missing alternate text (alt text)\ninformation.\n\nAlternate text is commonly specified inline as:\n\n```markdown\n![Alternate text](image.jpg)\n```\n\nOr with reference syntax as:\n\n```markdown\n![Alternate text][ref]\n\n...\n\n[ref]: image.jpg \"Optional title\"\n```\n\nOr with HTML as:\n\n```html\n\"Alternate\n```\n\nNote: If the [HTML `aria-hidden` attribute][aria-hidden] is used to hide the\nimage from assistive technology, this rule does not report a violation:\n\n```html\n\n```\n\nGuidance for writing alternate text is available from the [W3C][w3c],\n[Wikipedia][wikipedia], and [other locations][phase2technology].\n\nRationale: Alternate text is important for accessibility and describes the\ncontent of an image for people who may not be able to see it.\n\n[aria-hidden]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/Reference/Attributes/aria-hidden\n[phase2technology]: https://www.phase2technology.com/blog/no-more-excuses\n[w3c]: https://www.w3.org/WAI/alt/\n[wikipedia]: https://wikipedia.org/wiki/Alt_attribute\n\n\n\n## `MD046` - Code block style\n\nTags: `code`\n\nAliases: `code-block-style`\n\nParameters:\n\n- `style`: Block style (`string`, default `consistent`, values `consistent` /\n `fenced` / `indented`)\n\nThis rule is triggered when unwanted or different code block styles are used in\nthe same document.\n\nIn the default configuration this rule reports a violation for the following\ndocument:\n\n\n\n Some text.\n\n # Indented code\n\n More text.\n\n ```ruby\n # Fenced code\n ```\n\n More text.\n\n\n\nTo fix violations of this rule, use a consistent style (either indenting or code\nfences).\n\nThe configured code block style can be specific (`fenced`, `indented`) or can\nrequire all code blocks match the first code block (`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD047` - Files should end with a single newline character\n\nTags: `blank_lines`\n\nAliases: `single-trailing-newline`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when there is not a single newline character at the end\nof a file.\n\nAn example that triggers the rule:\n\n```markdown\n# Heading\n\nThis file ends without a newline.[EOF]\n```\n\nTo fix the violation, add a newline character to the end of the file:\n\n```markdown\n# Heading\n\nThis file ends with a newline.\n[EOF]\n```\n\nRationale: Some programs have trouble with files that do not end with a newline.\n\nMore information: [What's the point in adding a new line to the end of a\nfile?][stack-exchange]\n\n[stack-exchange]: https://unix.stackexchange.com/questions/18743/whats-the-point-in-adding-a-new-line-to-the-end-of-a-file\n\n\n\n## `MD048` - Code fence style\n\nTags: `code`\n\nAliases: `code-fence-style`\n\nParameters:\n\n- `style`: Code fence style (`string`, default `consistent`, values `backtick`\n / `consistent` / `tilde`)\n\nThis rule is triggered when the symbols used in the document for fenced code\nblocks do not match the configured code fence style:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n~~~ruby\n# Fenced code\n~~~\n````\n\nTo fix this issue, use the configured code fence style throughout the\ndocument:\n\n````markdown\n```ruby\n# Fenced code\n```\n\n```ruby\n# Fenced code\n```\n````\n\nThe configured code fence style can be a specific symbol to use (`backtick`,\n`tilde`) or it can require all code fences match the first code fence\n(`consistent`).\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD049` - Emphasis style\n\nTags: `emphasis`\n\nAliases: `emphasis-style`\n\nParameters:\n\n- `style`: Emphasis style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for emphasis do not\nmatch the configured emphasis style:\n\n```markdown\n*Text*\n_Text_\n```\n\nTo fix this issue, use the configured emphasis style throughout the document:\n\n```markdown\n*Text*\n*Text*\n```\n\nThe configured emphasis style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all emphasis matches the first emphasis\n(`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like_this_one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD050` - Strong style\n\nTags: `emphasis`\n\nAliases: `strong-style`\n\nParameters:\n\n- `style`: Strong style (`string`, default `consistent`, values `asterisk` /\n `consistent` / `underscore`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the symbols used in the document for strong do not\nmatch the configured strong style:\n\n```markdown\n**Text**\n__Text__\n```\n\nTo fix this issue, use the configured strong style throughout the document:\n\n```markdown\n**Text**\n**Text**\n```\n\nThe configured strong style can be a specific symbol to use (`asterisk`,\n`underscore`) or can require all strong matches the first strong (`consistent`).\n\nNote: Emphasis within a word is restricted to `asterisk` in order to avoid\nunwanted emphasis for words containing internal underscores like__this__one.\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n\n\n## `MD051` - Link fragments should be valid\n\nTags: `links`\n\nAliases: `link-fragments`\n\nParameters:\n\n- `ignore_case`: Ignore case of fragments (`boolean`, default `false`)\n- `ignored_pattern`: Pattern for ignoring additional fragments (`string`,\n default ``)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when a link fragment does not match any of the fragments\nthat are automatically generated for headings in a document:\n\n```markdown\n# Heading Name\n\n[Link](#fragment)\n```\n\nTo fix this issue, change the link fragment to reference an existing heading's\ngenerated name (see below):\n\n```markdown\n# Heading Name\n\n[Link](#heading-name)\n```\n\nFor consistency, this rule requires fragments to exactly match the [GitHub\nheading algorithm][github-heading-algorithm] which converts letters to\nlowercase. Therefore, the following example is reported as a violation:\n\n```markdown\n# Heading Name\n\n[Link](#Heading-Name)\n```\n\nTo ignore case when comparing fragments with heading names, the `ignore_case`\nparameter can be set to `true`. In this configuration, the previous example is\nnot reported as a violation.\n\nAlternatively, some platforms allow the syntax `{#named-anchor}` to be used\nwithin a heading to provide a specific name (consisting of only lower-case\nletters, numbers, `-`, and `_`):\n\n```markdown\n# Heading Name {#custom-name}\n\n[Link](#custom-name)\n```\n\nAlternatively, any HTML tag with an `id` attribute or an `a` tag with a `name`\nattribute can be used to define a fragment:\n\n```markdown\n\n\n[Link](#bookmark)\n```\n\nAn `a` tag can be useful in scenarios where a heading is not appropriate or for\ncontrol over the text of the fragment identifier.\n\n[HTML links to `#top` scroll to the top of a document][html-top-fragment]. This\nrule allows that syntax (using lower-case for consistency):\n\n```markdown\n[Link](#top)\n```\n\nThis rule also recognizes the custom fragment syntax used by GitHub to highlight\n[specific content in a document][github-linking-to-content].\n\nFor example, this link to line 20:\n\n```markdown\n[Link](#L20)\n```\n\nAnd this link to content starting within line 19 running into line 21:\n\n```markdown\n[Link](#L19C5-L21C11)\n```\n\nSome Markdown generators dynamically create and insert headings when building\ndocuments, for example by combining a fixed prefix like `figure-` and an\nincrementing numeric counter. To ignore such generated fragments, set the\n`ignored_pattern` [regular expression][RegEx] parameter to a pattern that\nmatches (e.g., `^figure-`).\n\nRationale: [GitHub section links][github-section-links] are created\nautomatically for every heading when Markdown content is displayed on GitHub.\nThis makes it easy to link directly to different sections within a document.\nHowever, section links change if headings are renamed or removed. This rule\nhelps identify broken section links within a document.\n\nNote: Section links are **not** part of the CommonMark specification; this rule\nenforces the [GitHub heading algorithm][github-heading-algorithm]:\n\n1. Convert text to lowercase\n2. Remove punctuation characters\n3. Convert spaces to dashes\n4. Append an incrementing integer (as needed for uniqueness)\n5. [URI-encode][encodeURIComponent] the result\n\n[encodeURIComponent]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent\n[github-section-links]: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#section-links\n[github-heading-algorithm]: https://github.com/gjtorikian/html-pipeline/blob/f13a1534cb650ba17af400d1acd3a22c28004c09/lib/html/pipeline/toc_filter.rb\n[github-linking-to-content]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/creating-a-permanent-link-to-a-code-snippet#linking-to-markdown\n[html-top-fragment]: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment\n[RegEx]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions\n\n\n\n## `MD052` - Reference links and images should use a label that is defined\n\nTags: `images`, `links`\n\nAliases: `reference-links-images`\n\nParameters:\n\n- `ignored_labels`: Ignored link labels (`string[]`, default `[\"x\"]`)\n- `shortcut_syntax`: Include shortcut syntax (`boolean`, default `false`)\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can define it elsewhere and use a label for reference.\nThe reference format is convenient for keeping paragraph text clutter-free\nand makes it easy to reuse the same URL in multiple places.\n\nThere are three kinds of reference links and images:\n\n```markdown\nFull: [text][label]\nCollapsed: [label][]\nShortcut: [label]\n\nFull: ![text][image]\nCollapsed: ![image][]\nShortcut: ![image]\n\n[label]: https://example.com/label\n[image]: https://example.com/image\n```\n\nA link or image renders correctly when the corresponding label is defined, but\ndisplays as text with brackets when the label is not present. By default, this\nrule warns of undefined labels for \"full\" and \"collapsed\" reference syntax but\nnot for \"shortcut\" syntax because it is ambiguous.\n\nThe text `[example]` could be a shortcut link or the text \"example\" in brackets,\nso \"shortcut\" syntax is ignored by default. To include \"shortcut\" syntax, set\nthe `include_shortcut` parameter to `true`. Note that doing so produces warnings\nfor *all* text in the document that *could* be a shortcut. If bracketed text is\nintentional, brackets can be escaped with the `\\` character: `\\[example\\]`.\n\nIf there are link labels that are deliberately unreferenced, they can be ignored\nby setting the `ignored_labels` parameter to the list of strings to ignore. The\ndefault value of this parameter ignores the checkbox syntax used by\n[GitHub Flavored Markdown task list items][gfm-tasklist]:\n\n```markdown\n- [x] Checked task list item\n```\n\n[gfm-tasklist]: https://github.github.com/gfm/#task-list-items-extension-\n\n\n\n## `MD053` - Link and image reference definitions should be needed\n\nTags: `images`, `links`\n\nAliases: `link-image-reference-definitions`\n\nParameters:\n\n- `ignored_definitions`: Ignored definitions (`string[]`, default `[\"//\"]`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source\nat the time of use or can use a label to reference a definition elsewhere in\nthe document. The latter reference format is convenient for keeping paragraph\ntext clutter-free and makes it easy to reuse the same URL in multiple places.\n\nBecause link and image reference definitions are located separately from\nwhere they are used, there are two scenarios where a definition can be\nunnecessary:\n\n1. If a label is not referenced by any link or image in a document, that\n definition is unused and can be deleted.\n2. If a label is defined multiple times in a document, the first definition is\n used and the others can be deleted.\n\nThis rule considers a reference definition to be used if any link or image\nreference has the corresponding label. The \"full\", \"collapsed\", and \"shortcut\"\nformats are all supported.\n\nIf there are reference definitions that are deliberately unreferenced, they can\nbe ignored by setting the `ignored_definitions` parameter to the list of strings\nto ignore. The default value of this parameter ignores the following convention\nfor adding non-HTML comments to Markdown:\n\n```markdown\n[//]: # (This behaves like a comment)\n```\n\n\n\n## `MD054` - Link and image style\n\nTags: `images`, `links`\n\nAliases: `link-image-style`\n\nParameters:\n\n- `autolink`: Allow autolinks (`boolean`, default `true`)\n- `collapsed`: Allow collapsed reference links and images (`boolean`, default\n `true`)\n- `full`: Allow full reference links and images (`boolean`, default `true`)\n- `inline`: Allow inline links and images (`boolean`, default `true`)\n- `shortcut`: Allow shortcut reference links and images (`boolean`, default\n `true`)\n- `url_inline`: Allow URLs as inline links (`boolean`, default `true`)\n\nFixable: Some violations can be fixed by tooling\n\nLinks and images in Markdown can provide the link destination or image source at\nthe time of use or can use a label to reference a definition elsewhere in the\ndocument. The three reference formats are convenient for keeping paragraph text\nclutter-free and make it easy to reuse the same URL in multiple places.\n\nBy default, this rule allows all link/image styles.\n\nSetting the `autolink` parameter to `false` disables autolinks:\n\n```markdown\n\n```\n\nSetting the `inline` parameter to `false` disables inline links and images:\n\n```markdown\n[link](https://example.com)\n\n![image](https://example.com)\n```\n\nSetting the `full` parameter to `false` disables full reference links and\nimages:\n\n```markdown\n[link][url]\n\n![image][url]\n\n[url]: https://example.com\n```\n\nSetting the `collapsed` parameter to `false` disables collapsed reference links\nand images:\n\n```markdown\n[url][]\n\n![url][]\n\n[url]: https://example.com\n```\n\nSetting the `shortcut` parameter to `false` disables shortcut reference links\nand images:\n\n```markdown\n[url]\n\n![url]\n\n[url]: https://example.com\n```\n\nTo fix violations of this rule, change the link or image to use an allowed\nstyle. This rule can automatically fix violations when a link or image can be\nconverted to the `inline` style (preferred) or a link can be converted to the\n`autolink` style (which does not support images and must be an absolute URL).\nThis rule does *not* fix scenarios that require converting a link or image to\nthe `full`, `collapsed`, or `shortcut` reference styles because that involves\nnaming the reference and determining where to insert it in the document.\n\nSetting the `url_inline` parameter to `false` prevents the use of inline links\nwith the same absolute URL text/destination and no title because such links can\nbe converted to autolinks:\n\n```markdown\n[https://example.com](https://example.com)\n```\n\nTo fix `url_inline` violations, use the simpler autolink syntax instead:\n\n```markdown\n\n```\n\nRationale: Consistent formatting makes it easier to understand a document.\nAutolinks are concise, but appear as URLs which can be long and confusing.\nInline links and images can include descriptive text, but take up more space in\nMarkdown form. Reference links and images can be easier to read and manipulate\nin Markdown form, but require a separate link reference definition.\n\n\n\n## `MD055` - Table pipe style\n\nTags: `table`\n\nAliases: `table-pipe-style`\n\nParameters:\n\n- `style`: Table pipe style (`string`, default `consistent`, values\n `consistent` / `leading_and_trailing` / `leading_only` /\n `no_leading_or_trailing` / `trailing_only`)\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-055]\nis inconsistent about its use of leading and trailing pipe characters (`|`).\n\nBy default (`consistent` style), the header row of the first table in a document\nis used to determine the style that is enforced for every table in the document.\nA specific style can be used instead (`leading_and_trailing`, `leading_only`,\n`no_leading_or_trailing`, `trailing_only`).\n\nThis table's header row has leading and trailing pipes, but its delimiter row is\nmissing the trailing pipe and its first row of cells is missing the leading\npipe:\n\n```markdown\n| Header | Header |\n| ------ | ------\n Cell | Cell |\n```\n\nTo fix these issues, make sure there is a pipe character at the beginning and\nend of every row:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and may also\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table\n```\n\nRationale: Some parsers have difficulty with tables that are missing their\nleading or trailing pipe characters. The use of leading/trailing pipes can also\nhelp provide visual clarity.\n\n[gfm-table-055]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD056` - Table column count\n\nTags: `table`\n\nAliases: `table-column-count`\n\nThis rule is triggered when a [GitHub Flavored Markdown table][gfm-table-056]\ndoes not have the same number of cells in every row.\n\nThis table's second data row has too few cells and its third data row has too\nmany cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell |\n| Cell | Cell | Cell |\n```\n\nTo fix these issues, ensure every row has the same number of cells:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n| Cell | Cell |\n| Cell | Cell |\n```\n\nNote that a table's header row and its delimiter row must have the same number\nof cells or it will not be recognized as a table (per specification).\n\nRationale: Extra cells in a row are usually not shown, so their data is lost.\nMissing cells in a row create holes in the table and suggest an omission.\n\n[gfm-table-056]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n\n\n\n## `MD058` - Tables should be surrounded by blank lines\n\nTags: `table`\n\nAliases: `blanks-around-tables`\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when tables are either not preceded or not followed by a\nblank line:\n\n```markdown\nSome text\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n> Blockquote\n```\n\nTo fix violations of this rule, ensure that all tables have a blank line both\nbefore and after (except when the table is at the very beginning or end of the\ndocument):\n\n```markdown\nSome text\n\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\n\n> Blockquote\n```\n\nNote that text immediately following a table (i.e., not separated by an empty\nline) is treated as part of the table (per the specification) and will not\ntrigger this rule:\n\n```markdown\n| Header | Header |\n| ------ | ------ |\n| Cell | Cell |\nThis text is part of the table and the next line is blank\n\nSome text\n```\n\nRationale: In addition to aesthetic reasons, some parsers will incorrectly parse\ntables that don't have blank lines before and after them.\n\n\n\n## `MD059` - Link text should be descriptive\n\nTags: `accessibility`, `links`\n\nAliases: `descriptive-link-text`\n\nParameters:\n\n- `prohibited_texts`: Prohibited link texts (`string[]`, default `[\"click\n here\",\"here\",\"link\",\"more\"]`)\n\nThis rule is triggered when a link has generic text like `[click here](...)` or\n`[link](...)`.\n\nLink text should be descriptive and communicate the purpose of the link (e.g.,\n`[Download the budget document](...)` or `[CommonMark Specification](...)`).\nThis is especially important for screen readers which sometimes present links\nwithout context.\n\nBy default, this rule prohibits a small number of common English words/phrases.\nTo customize that list of words/phrases, set the `prohibited_texts` parameter to\nan `Array` of `string`s.\n\nNote: For languages other than English, use the `prohibited_texts` parameter to\ncustomize the list for that language. It is *not* a goal for this rule to have\ntranslations for every language.\n\nNote: This rule checks Markdown links; HTML links are ignored.\n\nMore information:\n\n- \n- \n\n\n\n## `MD060` - Table column style\n\nTags: `table`\n\nAliases: `table-column-style`\n\nParameters:\n\n- `aligned_delimiter`: Aligned delimiter columns (`boolean`, default `false`)\n- `style`: Table column style (`string`, default `any`, values `aligned` /\n `any` / `compact` / `tight`)\n\nFixable: Some violations can be fixed by tooling\n\nThis rule is triggered when the column separator pipe characters (`|`) of a\n[GitHub Flavored Markdown table][gfm-table-060] are used inconsistently.\n\nThis rule recognizes three table column styles based on popular use.\n\nStyle `aligned` ensures pipe characters are vertically aligned:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nThe `aligned` style ignores cell content, so the following is also valid:\n\n```markdown\n| Character | Meaning |\n|-----------|---------|\n| Y | Yes |\n| N | No |\n```\n\nStyle `compact` avoids extra padding with a single space around cell content:\n\n```markdown\n| Character | Meaning |\n| --- | --- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` uses no padding at all for cell content:\n\n```markdown\n|Character|Meaning|\n|---|---|\n|Y|Yes|\n|N|No|\n```\n\nWhen this rule's `style` parameter is set to `aligned`, `compact`, or `tight`,\nevery table must match the corresponding pattern and any violations will be\nreported. By default, or when the `any` style is used, each table is analyzed to\nsee if it satisfies any supported style. If so, no violations are reported. If\nnot, violations are be reported for whichever style would produce the *fewest*\nissues (i.e., whichever style is the closest match).\n\nSetting the `aligned_delimiter` parameter to `true` requires pipe characters in\nthe delimiter row to align with those in the header row. This can be used with\n`compact` and `tight` tables to make the header text more obvious. (It's already\nrequired for tables with style `aligned`.)\n\nStyle `compact` with `aligned_delimiter`:\n\n```markdown\n| Character | Meaning |\n| --------- | ------- |\n| Y | Yes |\n| N | No |\n```\n\nStyle `tight` with `aligned_delimiter`:\n\n```markdown\n|Character|Meaning|\n|---------|-------|\n|Y|Yes|\n|N|No|\n```\n\nViolations for styles `compact` and `tight` are simple/independent and can be\nfixed automatically. However, fixing even single violations for style `aligned`\nmay require modifying the entire table, and therefore are not automatic:\n\n```markdown\n|Alpha |Delta|\n|------|-----|\n|Charlie|Beta|\n```\n\n**Note**: This rule does not require leading/trailing pipe characters, so this\nis also a valid table for style `compact`:\n\n```markdown\nCharacter | Meaning\n--- | ---\nY | Yes\nN | No\n```\n\n**Note**: Pipe alignment for the `aligned` style is based on visual appearance\nand not character count. Because editors typically render [emoji][emoji] and\n[CJK characters][cjk-characters] at *twice* the width of\n[Latin characters][latin-script], this rule takes that into account for tables\nusing the `aligned` style. The following table is correctly formatted and will\nappear aligned in most editors and monospaced fonts:\n\n\n\n\n```markdown\n| Response | Emoji |\n| -------- | ----- |\n| Yes | ✅ |\n| No | ❎ |\n```\n\n\n\nRationale: Consistent formatting makes it easier to understand a document.\n\n[cjk-characters]: https://wikipedia.org/wiki/CJK_characters\n[emoji]: https://wikipedia.org/wiki/Emoji\n[gfm-table-060]: https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/organizing-information-with-tables\n[latin-script]: https://wikipedia.org/wiki/Latin_script\n\n\n\n\n"}