diff --git a/lint_rules/adjacent_overload_signatures.md b/lint_rules/adjacent_overload_signatures.md
index 8435f53a..7f4e4f34 100644
--- a/lint_rules/adjacent_overload_signatures.md
+++ b/lint_rules/adjacent_overload_signatures.md
@@ -3,7 +3,7 @@ Requires overload signatures to be adjacent to each other.
 Overloaded signatures which are not next to each other can lead to code which is
 hard to read and maintain.
 
-### Invalid:
+**Invalid:**
 
 (`bar` is declared in-between `foo` overloads)
 
@@ -41,7 +41,7 @@ export function bar(): void {}
 export function foo(sn: string | number): void {}
 ```
 
-### Valid:
+**Valid:**
 
 (`bar` is declared after `foo`)
 
diff --git a/lint_rules/ban_ts_comment.md b/lint_rules/ban_ts_comment.md
index fbf59cc2..ce9401cc 100644
--- a/lint_rules/ban_ts_comment.md
+++ b/lint_rules/ban_ts_comment.md
@@ -4,7 +4,7 @@ Typescript directives reduce the effectiveness of the compiler, something which
 should only be done in exceptional circumstances. The reason why should be
 documented in a comment alongside the directive.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // @ts-expect-error
@@ -21,7 +21,7 @@ let a: number = "I am a string";
 let a: number = "I am a string";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // @ts-expect-error: Temporary workaround (see ticket #422)
diff --git a/lint_rules/ban_types.md b/lint_rules/ban_types.md
index e7dca492..12826cad 100644
--- a/lint_rules/ban_types.md
+++ b/lint_rules/ban_types.md
@@ -17,7 +17,7 @@ safety with the function.
 Finally, `Object` and `{}` means "any non-nullish value" rather than "any object
 type". `object` is a good choice for a meaning of "any object type".
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let a: Boolean;
@@ -29,7 +29,7 @@ let f: Object;
 let g: {};
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let a: boolean;
diff --git a/lint_rules/ban_unknown_rule_code.md b/lint_rules/ban_unknown_rule_code.md
index 6d33ad43..05f6862d 100644
--- a/lint_rules/ban_unknown_rule_code.md
+++ b/lint_rules/ban_unknown_rule_code.md
@@ -12,7 +12,7 @@ const foo: any = 42;
 This rule checks for the validity of the specified rule names (i.e. whether
 `deno_lint` provides the rule or not).
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // typo
@@ -24,7 +24,7 @@ console.assert(x == 42);
 const b = "b";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // deno-lint-ignore eq-eq-eq
diff --git a/lint_rules/ban_untagged_ignore.md b/lint_rules/ban_untagged_ignore.md
index 48af34a5..05bb1203 100644
--- a/lint_rules/ban_untagged_ignore.md
+++ b/lint_rules/ban_untagged_ignore.md
@@ -3,14 +3,14 @@ Requires `deno-lint-ignore` to be annotated with one or more rule names.
 Ignoring all rules can mask unexpected or future problems. Therefore you need to
 explicitly specify which rule(s) are to be ignored.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // deno-lint-ignore
 export function duplicateArgumentsFn(a, b, a) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // deno-lint-ignore no-dupe-args
diff --git a/lint_rules/ban_untagged_todo.md b/lint_rules/ban_untagged_todo.md
index a48b6c1c..f7d0a288 100644
--- a/lint_rules/ban_untagged_todo.md
+++ b/lint_rules/ban_untagged_todo.md
@@ -4,7 +4,7 @@ reference (`#issue`).
 TODOs without reference to a user or an issue become stale with no easy way to
 get more information.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // TODO Improve calc engine
@@ -21,7 +21,7 @@ export function calcValue(): number {}
 export function calcValue(): number {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // TODO(djones) Improve calc engine
diff --git a/lint_rules/ban_unused_ignore.md b/lint_rules/ban_unused_ignore.md
index 5978ee28..dfa8dd04 100644
--- a/lint_rules/ban_unused_ignore.md
+++ b/lint_rules/ban_unused_ignore.md
@@ -9,7 +9,7 @@ likely to confuse future code readers, and to make matters worse, might hide
 future lint errors unintentionally. To prevent such situations, this rule
 detects unused, superfluous ignore directives.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Actually this line is valid since `export` means "used",
@@ -18,7 +18,7 @@ detects unused, superfluous ignore directives.
 export const foo = 42;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 export const foo = 42;
diff --git a/lint_rules/button_has_type.md b/lint_rules/button_has_type.md
index 5607e13f..2c097565 100644
--- a/lint_rules/button_has_type.md
+++ b/lint_rules/button_has_type.md
@@ -1,7 +1,7 @@
 Checks that a `<button>` JSX element has a valid `type` attribute. The default
 value is `"submit"` which is often not the desired behavior.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <button />
@@ -11,7 +11,7 @@ value is `"submit"` which is often not the desired behavior.
 <button type={2} />
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <button type="submit" />
diff --git a/lint_rules/camelcase.md b/lint_rules/camelcase.md
index f4cd0ce1..b58f1098 100644
--- a/lint_rules/camelcase.md
+++ b/lint_rules/camelcase.md
@@ -13,7 +13,7 @@ Of note:
 - This rule also applies to variables imported or exported via ES modules, but
   not to object properties of those variables
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let first_name = "Ichigo";
@@ -41,7 +41,7 @@ interface snake_case_interface {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let firstName = "Ichigo";
diff --git a/lint_rules/constructor_super.md b/lint_rules/constructor_super.md
index 0c67a57c..45bdf8bb 100644
--- a/lint_rules/constructor_super.md
+++ b/lint_rules/constructor_super.md
@@ -4,7 +4,7 @@ Defined constructors of derived classes (e.g. `class A extends B`) must always
 call `super()`. Classes which extend non-constructors (e.g.
 `class A extends null`) must not have a constructor.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 class A {}
@@ -30,7 +30,7 @@ class E extends null {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 class A {}
diff --git a/lint_rules/default_param_last.md b/lint_rules/default_param_last.md
index aa475b4d..de874ba1 100644
--- a/lint_rules/default_param_last.md
+++ b/lint_rules/default_param_last.md
@@ -5,14 +5,14 @@ the function call without mapping the function inputs to different parameters
 which is confusing and error prone. Specifying them last allows them to be left
 out without changing the semantics of the other parameters.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function f(a = 2, b) {}
 function f(a = 5, b, c = 5) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function f() {}
diff --git a/lint_rules/eqeqeq.md b/lint_rules/eqeqeq.md
index 4bb8f7de..62bb402d 100644
--- a/lint_rules/eqeqeq.md
+++ b/lint_rules/eqeqeq.md
@@ -6,14 +6,14 @@ value. On the other hand `==` and `!=` do type coercion before value checking
 which can lead to unexpected results. For example `5 == "5"` is `true`, while
 `5 === "5"` is `false`.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (a == 5) {}
 if ("hello world" != input) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (a === 5) {}
diff --git a/lint_rules/explicit_function_return_type.md b/lint_rules/explicit_function_return_type.md
index 35c4979b..91e838e5 100644
--- a/lint_rules/explicit_function_return_type.md
+++ b/lint_rules/explicit_function_return_type.md
@@ -4,7 +4,7 @@ Explicit return types have a number of advantages including easier to understand
 code and better type safety. It is clear from the signature what the return type
 of the function (if any) will be.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function someCalc() {
@@ -15,7 +15,7 @@ function anotherCalc() {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function someCalc(): number {
diff --git a/lint_rules/explicit_module_boundary_types.md b/lint_rules/explicit_module_boundary_types.md
index 9ea3fa27..709d8c2c 100644
--- a/lint_rules/explicit_module_boundary_types.md
+++ b/lint_rules/explicit_module_boundary_types.md
@@ -5,7 +5,7 @@ inputs and outputs of a module (known as the module boundary). This will make it
 very clear to any users of the module how to supply inputs and handle outputs in
 a type safe manner.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Missing return type (e.g. void)
@@ -22,7 +22,7 @@ export function isValid() {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // Typed input parameters and return value
diff --git a/lint_rules/for_direction.md b/lint_rules/for_direction.md
index e835dbcd..c9a41641 100644
--- a/lint_rules/for_direction.md
+++ b/lint_rules/for_direction.md
@@ -5,14 +5,14 @@ infinite loops. This can occur through incorrect initialization, bad
 continuation step logic or wrong direction incrementing of the loop control
 variable.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Infinite loop
 for (let i = 0; i < 2; i--) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 for (let i = 0; i < 2; i++) {}
diff --git a/lint_rules/fresh_handler_export.md b/lint_rules/fresh_handler_export.md
index 86c50556..6f5c1d3a 100644
--- a/lint_rules/fresh_handler_export.md
+++ b/lint_rules/fresh_handler_export.md
@@ -5,7 +5,7 @@ rendering happens. They are expected to be available as a named export called
 `handler`. This rule checks for when the export was incorrectly named `handlers`
 instead of `handler`.
 
-### Invalid:
+**Invalid:**
 
 ```js
 export const handlers = {
@@ -16,7 +16,7 @@ export function handlers() {}
 export async function handlers() {}
 ```
 
-### Valid:
+**Valid:**
 
 ```jsx
 export const handler = {
diff --git a/lint_rules/fresh_server_event_handlers.md b/lint_rules/fresh_server_event_handlers.md
index 95d47904..0710b9a5 100644
--- a/lint_rules/fresh_server_event_handlers.md
+++ b/lint_rules/fresh_server_event_handlers.md
@@ -7,7 +7,7 @@ will have no effect.
 Note that this rule only applies to server components inside the `routes/`
 folder, not to fresh islands or any other components.
 
-### Invalid:
+**Invalid:**
 
 ```jsx
 <button onClick={() => {}} />
@@ -15,7 +15,7 @@ folder, not to fresh islands or any other components.
 <my-custom-element foo={() => {}} />
 ```
 
-### Valid:
+**Valid:**
 
 ```jsx
 <button />
diff --git a/lint_rules/getter_return.md b/lint_rules/getter_return.md
index 070c0fa3..e28c8699 100644
--- a/lint_rules/getter_return.md
+++ b/lint_rules/getter_return.md
@@ -3,7 +3,7 @@ Requires all property getter functions to return a value
 Getter functions return the value of a property. If the function returns no
 value then this contract is broken.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let foo = {
@@ -15,7 +15,7 @@ class Person {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let foo = {
diff --git a/lint_rules/guard_for_in.md b/lint_rules/guard_for_in.md
index 7edd1343..bb065017 100644
--- a/lint_rules/guard_for_in.md
+++ b/lint_rules/guard_for_in.md
@@ -4,7 +4,7 @@ Looping over objects with a `for-in` loop will include properties that are
 inherited through the prototype chain. This behavior can lead to unexpected
 items in your for loop.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 for (const key in obj) {
@@ -12,7 +12,7 @@ for (const key in obj) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 for (const key in obj) {
diff --git a/lint_rules/jsx_boolean_value.md b/lint_rules/jsx_boolean_value.md
index fd2d8340..880c7c3a 100644
--- a/lint_rules/jsx_boolean_value.md
+++ b/lint_rules/jsx_boolean_value.md
@@ -1,14 +1,14 @@
 Enforce a consistent JSX boolean value style. Passing `true` as the boolean
 value can be omitted with the shorthand syntax.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const foo = <Foo isFoo={true} />;
 const foo = <Foo isFoo={false} />;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const foo = <Foo isFoo />;
diff --git a/lint_rules/jsx_curly_braces.md b/lint_rules/jsx_curly_braces.md
index cffb17e1..b1ff2a78 100644
--- a/lint_rules/jsx_curly_braces.md
+++ b/lint_rules/jsx_curly_braces.md
@@ -1,6 +1,6 @@
 Ensure consistent use of curly braces around JSX expressions.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const foo = <Foo foo=<div /> />;
@@ -8,7 +8,7 @@ const foo = <Foo str={"foo"} />;
 const foo = <div>{"foo"}</div>;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const foo = <Foo foo={<div />} />;
diff --git a/lint_rules/jsx_key.md b/lint_rules/jsx_key.md
index bd6a663e..87f04dff 100644
--- a/lint_rules/jsx_key.md
+++ b/lint_rules/jsx_key.md
@@ -1,7 +1,7 @@
 Ensure the `key` attribute is present when passing iterables into JSX. It allows
 frameworks to optimize checking the order of elements.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const foo = [<div>foo</div>];
@@ -10,7 +10,7 @@ const foo = [<>foo</>];
 Array.from([1, 2, 3], () => <div />);
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const foo = [<div key="a">foo</div>];
diff --git a/lint_rules/jsx_no_children_prop.md b/lint_rules/jsx_no_children_prop.md
index 79b0eba6..25ea6456 100644
--- a/lint_rules/jsx_no_children_prop.md
+++ b/lint_rules/jsx_no_children_prop.md
@@ -1,13 +1,13 @@
 Pass children as JSX children instead of as an attribute.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <div children="foo" />
 <div children={[<Foo />, <Bar />]} />
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <div>foo</div>
diff --git a/lint_rules/jsx_no_danger_with_children.md b/lint_rules/jsx_no_danger_with_children.md
index a0448c3f..31292efe 100644
--- a/lint_rules/jsx_no_danger_with_children.md
+++ b/lint_rules/jsx_no_danger_with_children.md
@@ -1,7 +1,7 @@
 Using JSX children together with `dangerouslySetInnerHTML` is invalid as they
 will be ignored.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <div dangerouslySetInnerHTML={{ __html: "<h1>hello</h1>" }}>
@@ -9,7 +9,7 @@ will be ignored.
 </div>;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <div dangerouslySetInnerHTML={{ __html: "<h1>hello</h1>" }} />;
diff --git a/lint_rules/jsx_no_duplicate_props.md b/lint_rules/jsx_no_duplicate_props.md
index 6d5c3d7f..6ba9db84 100644
--- a/lint_rules/jsx_no_duplicate_props.md
+++ b/lint_rules/jsx_no_duplicate_props.md
@@ -1,7 +1,7 @@
 Disallow duplicated JSX props. Later props will always overwrite earlier props
 often leading to unexpected results.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <div id="1" id="2" />;
@@ -9,7 +9,7 @@ often leading to unexpected results.
 <App a {...b} a />;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <div id="1" />
diff --git a/lint_rules/jsx_no_useless_fragment.md b/lint_rules/jsx_no_useless_fragment.md
index 3a117630..030e5ffa 100644
--- a/lint_rules/jsx_no_useless_fragment.md
+++ b/lint_rules/jsx_no_useless_fragment.md
@@ -1,7 +1,7 @@
 Fragments are only necessary at the top of a JSX "block" and only when there are
 multiple children. Fragments are not needed in other scenarios.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <></>
@@ -10,7 +10,7 @@ multiple children. Fragments are not needed in other scenarios.
 <p>foo <>bar</></p>
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <>{foo}</>
diff --git a/lint_rules/jsx_props_no_spread_multi.md b/lint_rules/jsx_props_no_spread_multi.md
index 86d201ca..2c81813e 100644
--- a/lint_rules/jsx_props_no_spread_multi.md
+++ b/lint_rules/jsx_props_no_spread_multi.md
@@ -1,7 +1,7 @@
 Spreading the same expression twice is typically a mistake and causes
 unnecessary computations.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <div {...foo} {...foo} />
@@ -9,7 +9,7 @@ unnecessary computations.
 <Foo {...foo.bar} {...foo.bar} />
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <div {...foo} />
diff --git a/lint_rules/jsx_void_dom_elements_no_children.md b/lint_rules/jsx_void_dom_elements_no_children.md
index 86dbec26..2cf80e3c 100644
--- a/lint_rules/jsx_void_dom_elements_no_children.md
+++ b/lint_rules/jsx_void_dom_elements_no_children.md
@@ -3,14 +3,14 @@ HTML. See
 [`Void element` article on MDN](https://developer.mozilla.org/en-US/docs/Glossary/Void_element)
 for more information.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 <br>foo</br>
 <img src="a.jpg">foo</img>
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 <br />
diff --git a/lint_rules/no_array_constructor.md b/lint_rules/no_array_constructor.md
index 37c04c27..323d9e1e 100644
--- a/lint_rules/no_array_constructor.md
+++ b/lint_rules/no_array_constructor.md
@@ -11,7 +11,7 @@ constructor is that the `Array` global may be redefined.
 The one exception to this rule is when creating a new array of fixed size, e.g.
 `new Array(6)`. This is the conventional way to create arrays of fixed length.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // This is 4 elements, not a size 100 array of 3 elements
@@ -20,7 +20,7 @@ const a = new Array(100, 1, 2, 3);
 const b = new Array(); // use [] instead
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a = new Array(100);
diff --git a/lint_rules/no_async_promise_executor.md b/lint_rules/no_async_promise_executor.md
index bd8d9c84..32e5ae45 100644
--- a/lint_rules/no_async_promise_executor.md
+++ b/lint_rules/no_async_promise_executor.md
@@ -14,14 +14,14 @@ idea for several reasons:
   the new Promise constructor can be reduced, extracting the async code and
   changing it to be synchronous.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 new Promise(async function (resolve, reject) {});
 new Promise(async (resolve, reject) => {});
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 new Promise(function (resolve, reject) {});
diff --git a/lint_rules/no_await_in_loop.md b/lint_rules/no_await_in_loop.md
index 2b701d43..c69409be 100644
--- a/lint_rules/no_await_in_loop.md
+++ b/lint_rules/no_await_in_loop.md
@@ -9,7 +9,7 @@ A common solution is to refactor the code to run the loop body asynchronously
 and capture the promises generated. After the loop finishes you can then await
 all the promises at once.
 
-### Invalid:
+**Invalid:**
 
 ```javascript
 async function doSomething(items) {
@@ -22,7 +22,7 @@ async function doSomething(items) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```javascript
 async function doSomething(items) {
diff --git a/lint_rules/no_await_in_sync_fn.md b/lint_rules/no_await_in_sync_fn.md
index 587af20d..48758dad 100644
--- a/lint_rules/no_await_in_sync_fn.md
+++ b/lint_rules/no_await_in_sync_fn.md
@@ -4,7 +4,7 @@ Using the `await` keyword inside a non-async function is a syntax error. To be
 able to use `await` inside a function, the function needs to be marked as async
 via the `async` keyword
 
-### Invalid:
+**Invalid:**
 
 ```javascript
 function foo() {
@@ -20,7 +20,7 @@ const fooFn = () => {
 };
 ```
 
-### Valid:
+**Valid:**
 
 ```javascript
 async function foo() {
diff --git a/lint_rules/no_boolean_literal_for_arguments.md b/lint_rules/no_boolean_literal_for_arguments.md
index e0609abe..923b8371 100644
--- a/lint_rules/no_boolean_literal_for_arguments.md
+++ b/lint_rules/no_boolean_literal_for_arguments.md
@@ -9,7 +9,7 @@ A simple fix for the points mentioned above is the use of self documenting
 constants that will end up working as "named booleans", that allow for a better
 understanding on what the parameters mean in the context of the function call.
 
-### Invalid
+**Invalid:**
 
 ```typescript
 function redraw(allViews: boolean, inline: boolean) {
@@ -28,7 +28,7 @@ function enableLogs(enable: boolean) {
 enableLogs(true);
 ```
 
-### Valid
+**Valid:**
 
 ```typescript
 function redraw(allViews: boolean, inline: boolean) {
diff --git a/lint_rules/no_case_declarations.md b/lint_rules/no_case_declarations.md
index 8d5a9d1e..fffe3e25 100644
--- a/lint_rules/no_case_declarations.md
+++ b/lint_rules/no_case_declarations.md
@@ -7,7 +7,7 @@ assigned, which only happens if that case/default is reached. This can lead to
 unexpected errors. The solution is to ensure each `case` or `default` block is
 wrapped in brackets to scope limit the declarations.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 switch (choice) {
@@ -28,7 +28,7 @@ switch (choice) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 switch (choice) {
diff --git a/lint_rules/no_class_assign.md b/lint_rules/no_class_assign.md
index f7137858..68febbf9 100644
--- a/lint_rules/no_class_assign.md
+++ b/lint_rules/no_class_assign.md
@@ -4,14 +4,14 @@ Declaring a class such as `class A {}`, creates a variable `A`. Like any
 variable this can be modified or reassigned. In most cases this is a mistake and
 not what was intended.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 class A {}
 A = 0; // reassigning the class variable itself
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 class A {}
diff --git a/lint_rules/no_compare_neg_zero.md b/lint_rules/no_compare_neg_zero.md
index 31f28b0a..b39baa85 100644
--- a/lint_rules/no_compare_neg_zero.md
+++ b/lint_rules/no_compare_neg_zero.md
@@ -4,13 +4,13 @@ Comparing a value directly against negative may not work as expected as it will
 also pass for non-negative zero (i.e. `0` and `+0`). Explicit comparison with
 negative zero can be performed using `Object.is`.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (x === -0) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (x === 0) {}
diff --git a/lint_rules/no_cond_assign.md b/lint_rules/no_cond_assign.md
index 2810913a..ea2edd57 100644
--- a/lint_rules/no_cond_assign.md
+++ b/lint_rules/no_cond_assign.md
@@ -5,7 +5,7 @@ result of mistyping the equality operator, `==`. If an assignment within a
 conditional statement is required then this rule allows it by wrapping the
 assignment in parentheses.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let x;
@@ -22,7 +22,7 @@ function setHeight(someNode) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let x;
diff --git a/lint_rules/no_console.md b/lint_rules/no_console.md
index 5d2e3459..64d55f3d 100644
--- a/lint_rules/no_console.md
+++ b/lint_rules/no_console.md
@@ -9,7 +9,7 @@ disallowing the use of `console`.
 This rule is especially useful in libraries where you almost never want to
 output to the console.
 
-### Invalid
+**Invalid:**
 
 ```typescript
 console.log("Debug message");
@@ -23,7 +23,7 @@ function log() {
 }
 ```
 
-### Valid
+**Valid:**
 
 It is recommended to explicitly enable the console via a `deno-lint-ignore`
 comment for any calls where you actually want to use it.
diff --git a/lint_rules/no_const_assign.md b/lint_rules/no_const_assign.md
index d39f63fb..8add482d 100644
--- a/lint_rules/no_const_assign.md
+++ b/lint_rules/no_const_assign.md
@@ -2,7 +2,7 @@ Disallows modifying a variable declared as `const`.
 
 Modifying a variable declared as `const` will result in a runtime error.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = 0;
@@ -12,7 +12,7 @@ a++;
 ++a;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a = 0;
diff --git a/lint_rules/no_constant_condition.md b/lint_rules/no_constant_condition.md
index df87d694..1afa50a0 100644
--- a/lint_rules/no_constant_condition.md
+++ b/lint_rules/no_constant_condition.md
@@ -4,7 +4,7 @@ Using a constant expression in a conditional test is often either a mistake or a
 temporary situation introduced during development and is not ready for
 production.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (true) {}
@@ -12,7 +12,7 @@ if (2) {}
 do {} while (x = 2); // infinite loop
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (x) {}
diff --git a/lint_rules/no_control_regex.md b/lint_rules/no_control_regex.md
index 5b1d12d6..510ff28a 100644
--- a/lint_rules/no_control_regex.md
+++ b/lint_rules/no_control_regex.md
@@ -4,7 +4,7 @@ Control characters are invisible characters in the ASCII range of 0-31. It is
 uncommon to use these in a regular expression and more often it is a mistake in
 the regular expression.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // Examples using ASCII (31) Carriage Return (hex x0d)
@@ -14,7 +14,7 @@ const pattern3 = new RegExp("\\x0d");
 const pattern4 = new RegExp("\\u000d");
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // Examples using ASCII (32) Space (hex x20)
diff --git a/lint_rules/no_danger.md b/lint_rules/no_danger.md
index 20083ed1..e051614a 100644
--- a/lint_rules/no_danger.md
+++ b/lint_rules/no_danger.md
@@ -1,13 +1,13 @@
 Prevent the use of `dangerouslySetInnerHTML` which can lead to XSS
 vulnerabilities if used incorrectly.
 
-### Invalid:
+**Invalid:**
 
 ```tsx
 const hello = <div dangerouslySetInnerHTML={{ __html: "Hello World!" }} />;
 ```
 
-### Valid:
+**Valid:**
 
 ```tsx
 const hello = <div>Hello World!</div>;
diff --git a/lint_rules/no_debugger.md b/lint_rules/no_debugger.md
index 3fdaa34e..9805cb2f 100644
--- a/lint_rules/no_debugger.md
+++ b/lint_rules/no_debugger.md
@@ -5,7 +5,7 @@ environment and start the debugger at the statement. Modern debuggers and
 tooling no longer need this statement and leaving it in can cause the execution
 of your code to stop in production.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function isLongString(x: string) {
@@ -14,7 +14,7 @@ function isLongString(x: string) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function isLongString(x: string) {
diff --git a/lint_rules/no_delete_var.md b/lint_rules/no_delete_var.md
index 54317aa4..1c81307f 100644
--- a/lint_rules/no_delete_var.md
+++ b/lint_rules/no_delete_var.md
@@ -5,7 +5,7 @@ Disallows the deletion of variables
 Setting `strict` mode on will raise a syntax error when attempting to delete a
 variable.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = 1;
@@ -16,7 +16,7 @@ delete b; // would return false
 delete c; // would return false
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let obj = {
diff --git a/lint_rules/no_dupe_args.md b/lint_rules/no_dupe_args.md
index 22d53ec3..e8a8373d 100644
--- a/lint_rules/no_dupe_args.md
+++ b/lint_rules/no_dupe_args.md
@@ -4,7 +4,7 @@ If you supply multiple arguments of the same name to a function, the last
 instance will shadow the preceding one(s). This is most likely an unintentional
 typo.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function withDupes(a, b, a) {
@@ -12,7 +12,7 @@ function withDupes(a, b, a) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function withoutDupes(a, b, c) {
diff --git a/lint_rules/no_dupe_class_members.md b/lint_rules/no_dupe_class_members.md
index ef8d088e..f8909d1e 100644
--- a/lint_rules/no_dupe_class_members.md
+++ b/lint_rules/no_dupe_class_members.md
@@ -3,7 +3,7 @@ Disallows using a class member function name more than once
 Declaring a function of the same name twice in a class will cause the previous
 declaration(s) to be overwritten, causing unexpected behaviors.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 class Foo {
@@ -12,7 +12,7 @@ class Foo {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 class Foo {
diff --git a/lint_rules/no_dupe_else_if.md b/lint_rules/no_dupe_else_if.md
index f32a3480..35ed539a 100644
--- a/lint_rules/no_dupe_else_if.md
+++ b/lint_rules/no_dupe_else_if.md
@@ -4,7 +4,7 @@ When you reuse a condition in an `if`/`else if` statement, the duplicate
 condition will never be reached (without unusual side-effects) meaning this is
 almost always a bug.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (a) {}
@@ -16,7 +16,7 @@ else if (a === 6) {}
 else if (a === 5) {} // duplicate of condition above
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (a) {}
diff --git a/lint_rules/no_dupe_keys.md b/lint_rules/no_dupe_keys.md
index 28aeadaa..2f6f8625 100644
--- a/lint_rules/no_dupe_keys.md
+++ b/lint_rules/no_dupe_keys.md
@@ -3,7 +3,7 @@ Disallows duplicate keys in object literals.
 Setting the same key multiple times in an object literal will override other
 assignments to that key and can cause unexpected behaviour.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const foo = {
@@ -26,7 +26,7 @@ const foo = {
 };
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const foo = {
diff --git a/lint_rules/no_duplicate_case.md b/lint_rules/no_duplicate_case.md
index c73b6a9b..f9b282fb 100644
--- a/lint_rules/no_duplicate_case.md
+++ b/lint_rules/no_duplicate_case.md
@@ -3,7 +3,7 @@ Disallows using the same case clause in a switch statement more than once
 When you reuse a case test expression in a `switch` statement, the duplicate
 case will never be reached meaning this is almost always a bug.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const someText = "a";
@@ -19,7 +19,7 @@ switch (someText) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const someText = "a";
diff --git a/lint_rules/no_empty.md b/lint_rules/no_empty.md
index 5322669d..1d9a308e 100644
--- a/lint_rules/no_empty.md
+++ b/lint_rules/no_empty.md
@@ -5,7 +5,7 @@ and can make code less readable. This rule ignores block statements that only
 contain comments. This rule also ignores empty constructors and function bodies
 (including arrow functions).
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (foo) {}
@@ -21,7 +21,7 @@ try {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (foo) {
diff --git a/lint_rules/no_empty_character_class.md b/lint_rules/no_empty_character_class.md
index 331e26cb..18a2165c 100644
--- a/lint_rules/no_empty_character_class.md
+++ b/lint_rules/no_empty_character_class.md
@@ -4,14 +4,14 @@ Regular expression character classes are a series of characters in brackets,
 e.g. `[abc]`. if nothing is supplied in the brackets it will not match anything
 which is likely a typo or mistake.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 /^abc[]/.test("abcdefg"); // false, as `d` does not match an empty character class
 "abcdefg".match(/^abc[]/); // null
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // Without a character class
diff --git a/lint_rules/no_empty_enum.md b/lint_rules/no_empty_enum.md
index 4a540ae6..87710a0c 100644
--- a/lint_rules/no_empty_enum.md
+++ b/lint_rules/no_empty_enum.md
@@ -3,13 +3,13 @@ Disallows the declaration of an empty enum
 An enum with no members serves no purpose. This rule will capture these
 situations as either unnecessary code or a mistaken empty implementation.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 enum Foo {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 enum Foo {
diff --git a/lint_rules/no_empty_interface.md b/lint_rules/no_empty_interface.md
index 63c467b3..66d1bf21 100644
--- a/lint_rules/no_empty_interface.md
+++ b/lint_rules/no_empty_interface.md
@@ -3,13 +3,13 @@ Disallows the declaration of an empty interface
 An interface with no members serves no purpose. This rule will capture these
 situations as either unnecessary code or a mistaken empty implementation.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 interface Foo {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 interface Foo {
diff --git a/lint_rules/no_empty_pattern.md b/lint_rules/no_empty_pattern.md
index b5591f7d..a3a2686a 100644
--- a/lint_rules/no_empty_pattern.md
+++ b/lint_rules/no_empty_pattern.md
@@ -3,7 +3,7 @@ Disallows the use of empty patterns in destructuring
 In destructuring, it is possible to use empty patterns such as `{}` or `[]`
 which have no effect, most likely not what the author intended.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // In these examples below, {} and [] are not object literals or empty arrays,
@@ -16,7 +16,7 @@ function myFunc({}) {}
 function myFunc([]) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const { a } = someObj;
diff --git a/lint_rules/no_eval.md b/lint_rules/no_eval.md
index 1a014d3a..d353fa5a 100644
--- a/lint_rules/no_eval.md
+++ b/lint_rules/no_eval.md
@@ -4,7 +4,7 @@ Disallows the use of `eval`
 of security vulnerabilities. In addition to being slow, `eval` is also often
 unnecessary with better solutions available.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const obj = { x: "foo" };
@@ -12,7 +12,7 @@ const key = "x",
 const value = eval("obj." + key);
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const obj = { x: "foo" };
diff --git a/lint_rules/no_ex_assign.md b/lint_rules/no_ex_assign.md
index 56e12a6f..81922da4 100644
--- a/lint_rules/no_ex_assign.md
+++ b/lint_rules/no_ex_assign.md
@@ -3,7 +3,7 @@ Disallows the reassignment of exception parameters
 There is generally no good reason to reassign an exception parameter. Once
 reassigned the code from that point on has no reference to the error anymore.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 try {
@@ -14,7 +14,7 @@ try {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 try {
diff --git a/lint_rules/no_explicit_any.md b/lint_rules/no_explicit_any.md
index c79a1aa8..70b77656 100644
--- a/lint_rules/no_explicit_any.md
+++ b/lint_rules/no_explicit_any.md
@@ -7,7 +7,7 @@ immediately clear what type of value is being referenced. It is better to be
 explicit about all types. For a more type-safe alternative to `any`, use
 `unknown` if you are unable to choose a more specific type.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const someNumber: any = "two";
@@ -16,7 +16,7 @@ function foo(): any {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const someNumber: string = "two";
diff --git a/lint_rules/no_external_imports.md b/lint_rules/no_external_imports.md
index 5b4bd3e2..409b903d 100644
--- a/lint_rules/no_external_imports.md
+++ b/lint_rules/no_external_imports.md
@@ -15,13 +15,13 @@ Disallows the use of external imports
   - so if you'd like to follow the "deps.ts convention" or to use import maps,
     this rule is for you.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 import { assertEquals } from "https://deno.land/std@0.126.0/testing/asserts.ts";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 import { assertEquals } from "./deps.ts";
diff --git a/lint_rules/no_extra_boolean_cast.md b/lint_rules/no_extra_boolean_cast.md
index 3ede4341..e6985517 100644
--- a/lint_rules/no_extra_boolean_cast.md
+++ b/lint_rules/no_extra_boolean_cast.md
@@ -5,7 +5,7 @@ automatically coerced into a boolean. Therefore, techniques such as double
 negation (`!!foo`) or casting (`Boolean(foo)`) are unnecessary and produce the
 same result as without the negation or casting.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (!!foo) {}
@@ -14,7 +14,7 @@ while (!!foo) {}
 for (; Boolean(foo);) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (foo) {}
diff --git a/lint_rules/no_extra_non_null_assertion.md b/lint_rules/no_extra_non_null_assertion.md
index d3e411a2..cbcfd0ad 100644
--- a/lint_rules/no_extra_non_null_assertion.md
+++ b/lint_rules/no_extra_non_null_assertion.md
@@ -5,7 +5,7 @@ know this value is not null. Specifying this operator more than once in a row,
 or in combination with the optional chaining operator (`?`) is confusing and
 unnecessary.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const foo: { str: string } | null = null;
@@ -19,7 +19,7 @@ function anotherFunc(bar?: { str: string }) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const foo: { str: string } | null = null;
diff --git a/lint_rules/no_fallthrough.md b/lint_rules/no_fallthrough.md
index 48d90e83..4852b715 100644
--- a/lint_rules/no_fallthrough.md
+++ b/lint_rules/no_fallthrough.md
@@ -8,7 +8,7 @@ enforces that you either end each case statement with a break statement or an
 explicit comment that fallthrough was intentional. The fallthrough comment must
 contain one of `fallthrough`, `falls through` or `fall through`.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 switch (myVar) {
@@ -21,7 +21,7 @@ switch (myVar) {
 // If myVar = 1, outputs both `1` and `2`.  Was this intentional?
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 switch (myVar) {
diff --git a/lint_rules/no_func_assign.md b/lint_rules/no_func_assign.md
index 3286bbe5..ebc8d8fb 100644
--- a/lint_rules/no_func_assign.md
+++ b/lint_rules/no_func_assign.md
@@ -4,7 +4,7 @@ Javascript allows for the reassignment of a function definition. This is
 generally a mistake on the developers part, or poor coding practice as code
 readability and maintainability will suffer.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function foo() {}
@@ -18,7 +18,7 @@ myFunc = existingFunc;
 function myFunc() {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function foo() {}
diff --git a/lint_rules/no_global_assign.md b/lint_rules/no_global_assign.md
index cd3cff24..bae77e05 100644
--- a/lint_rules/no_global_assign.md
+++ b/lint_rules/no_global_assign.md
@@ -4,7 +4,7 @@ In Javascript, `String` and `Object` for example are native objects. Like any
 object, they can be reassigned, but it is almost never wise to do so as this can
 lead to unexpected results and difficult to track down bugs.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 Object = null;
diff --git a/lint_rules/no_implicit_declare_namespace_export.md b/lint_rules/no_implicit_declare_namespace_export.md
index 4347e810..c33ed4b9 100644
--- a/lint_rules/no_implicit_declare_namespace_export.md
+++ b/lint_rules/no_implicit_declare_namespace_export.md
@@ -5,7 +5,7 @@ whether a named export is present.
 
 ["ambient" namespaces]: https://www.typescriptlang.org/docs/handbook/namespaces.html#ambient-namespaces
 
-### Invalid:
+**Invalid:**
 
 ```ts
 // foo.ts or foo.d.ts
@@ -15,7 +15,7 @@ declare namespace ns {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```ts
 // foo.ts or foo.d.ts
diff --git a/lint_rules/no_import_assertions.md b/lint_rules/no_import_assertions.md
index dd4e0d97..25224f37 100644
--- a/lint_rules/no_import_assertions.md
+++ b/lint_rules/no_import_assertions.md
@@ -4,14 +4,14 @@ ES import attributes (previously called import assertions) has been changed to
 use the `with` keyword. The old syntax using `assert` is still supported, but
 deprecated.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 import obj from "./obj.json" assert { type: "json" };
 import("./obj2.json", { assert: { type: "json" } });
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 import obj from "./obj.json" with { type: "json" };
diff --git a/lint_rules/no_import_assign.md b/lint_rules/no_import_assign.md
index 83666d59..0194f551 100644
--- a/lint_rules/no_import_assign.md
+++ b/lint_rules/no_import_assign.md
@@ -4,7 +4,7 @@ ES module import bindings should be treated as read-only since modifying them
 during code execution will likely result in runtime errors. It also makes for
 poor code readability and difficult maintenance.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 import defaultMod, { namedMod } from "./mod.js";
@@ -16,7 +16,7 @@ modNameSpace.someExportedMember = "hello";
 modNameSpace = {};
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 import defaultMod, { namedMod } from "./mod.js";
diff --git a/lint_rules/no_inferrable_types.md b/lint_rules/no_inferrable_types.md
index 55b0b6d0..8c3485be 100644
--- a/lint_rules/no_inferrable_types.md
+++ b/lint_rules/no_inferrable_types.md
@@ -5,7 +5,7 @@ their type. Specifying their type can add additional verbosity to the code. For
 example, with `const x: number = 5`, specifying `number` is unnecessary as it is
 obvious that `5` is a number.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a: bigint = 10n;
@@ -34,7 +34,7 @@ class Foo {
 function fn(s: number = 5, t: boolean = true) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a = 10n;
diff --git a/lint_rules/no_inner_declarations.md b/lint_rules/no_inner_declarations.md
index 2a1d4a82..90378c82 100644
--- a/lint_rules/no_inner_declarations.md
+++ b/lint_rules/no_inner_declarations.md
@@ -10,7 +10,7 @@ code. Because these variables are hoisted to the module root, it is best to
 declare them there for clarity. Note that variables declared with `let` or
 `const` are block scoped and therefore this rule does not apply to them.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (someBool) {
@@ -24,7 +24,7 @@ function someFunc(someVal: number): void {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function doSomething() {}
diff --git a/lint_rules/no_invalid_regexp.md b/lint_rules/no_invalid_regexp.md
index 5a850447..0e56f27a 100644
--- a/lint_rules/no_invalid_regexp.md
+++ b/lint_rules/no_invalid_regexp.md
@@ -4,13 +4,13 @@ Specifying an invalid regular expression literal will result in a SyntaxError at
 compile time, however specifying an invalid regular expression string in the
 RegExp constructor will only be discovered at runtime.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const invalidRegExp = new RegExp(")");
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const goodRegExp = new RegExp(".");
diff --git a/lint_rules/no_invalid_triple_slash_reference.md b/lint_rules/no_invalid_triple_slash_reference.md
index fb6f89df..f379e6e3 100644
--- a/lint_rules/no_invalid_triple_slash_reference.md
+++ b/lint_rules/no_invalid_triple_slash_reference.md
@@ -17,9 +17,9 @@ the `types` directive.
 [v1.9.2]: https://deno.land/manual@v1.9.2/typescript/types#using-the-triple-slash-reference-directive
 [the latest manual]: https://deno.land/manual/typescript/types#using-the-triple-slash-reference-directive
 
-### Invalid:
+**Invalid:**
 
-#### JavaScript
+_JavaScript_
 
 ```javascript
 /// <reference path="./mod.d.ts" />
@@ -29,7 +29,7 @@ the `types` directive.
 // ... the rest of the JavaScript ...
 ```
 
-#### TypeScript
+_TypeScript_
 
 ```typescript
 /// <reference foo="bar" />
@@ -37,9 +37,9 @@ the `types` directive.
 // ... the rest of the TypeScript ...
 ```
 
-### Valid:
+**Valid:**
 
-#### JavaScript
+_JavaScript_
 
 ```javascript
 /// <reference types="./mod.d.ts" />
@@ -48,7 +48,7 @@ the `types` directive.
 // ... the rest of the JavaScript ...
 ```
 
-#### TypeScript
+_TypeScript_
 
 ```typescript
 /// <reference types="./mod.d.ts" />
diff --git a/lint_rules/no_misused_new.md b/lint_rules/no_misused_new.md
index 9833a591..aff4aa20 100644
--- a/lint_rules/no_misused_new.md
+++ b/lint_rules/no_misused_new.md
@@ -3,7 +3,7 @@ Disallows defining `constructor`s for interfaces or `new` for classes
 Specifying a `constructor` for an interface or defining a `new` method for a
 class is incorrect and should be avoided.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 class C {
@@ -15,7 +15,7 @@ interface I {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 class C {
diff --git a/lint_rules/no_namespace.md b/lint_rules/no_namespace.md
index f5c6025f..a862c60f 100644
--- a/lint_rules/no_namespace.md
+++ b/lint_rules/no_namespace.md
@@ -13,7 +13,7 @@ cases:
 
 ["ambient" namespaces]: https://www.typescriptlang.org/docs/handbook/namespaces.html#ambient-namespaces
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // foo.ts
@@ -26,7 +26,7 @@ namespace ns {}
 // all usage of `module` and `namespace` keywords are allowed in `.d.ts`
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // foo.ts
diff --git a/lint_rules/no_new_symbol.md b/lint_rules/no_new_symbol.md
index 1d8dd4cc..3baffdaa 100644
--- a/lint_rules/no_new_symbol.md
+++ b/lint_rules/no_new_symbol.md
@@ -4,13 +4,13 @@ Disallows the use of `new` operators with built-in `Symbol`s
 with the `new` operator by mistake. This rule detects such wrong usage of the
 `new` operator.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const foo = new Symbol("foo");
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const foo = Symbol("foo");
diff --git a/lint_rules/no_node_globals.md b/lint_rules/no_node_globals.md
index 9a5df065..a5959553 100644
--- a/lint_rules/no_node_globals.md
+++ b/lint_rules/no_node_globals.md
@@ -4,14 +4,14 @@ NodeJS exposes a set of global objects that differs from deno (and the web), so
 code should not assume they are available. Instead, import the objects from
 their defining modules as needed.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // foo.ts
 const buf = Buffer.from("foo", "utf-8"); // Buffer is not a global object in deno
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // foo.ts
diff --git a/lint_rules/no_non_null_asserted_optional_chain.md b/lint_rules/no_non_null_asserted_optional_chain.md
index c33bf320..676bc9b1 100644
--- a/lint_rules/no_non_null_asserted_optional_chain.md
+++ b/lint_rules/no_non_null_asserted_optional_chain.md
@@ -4,14 +4,14 @@ Disallow non-null assertions after an optional chain expression
 `undefined`. Using a `!` non-null assertion to assert the result of an `?.`
 optional chain expression is non-nullable is likely wrong.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 foo?.bar!;
 foo?.bar()!;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 foo?.bar;
diff --git a/lint_rules/no_non_null_assertion.md b/lint_rules/no_non_null_assertion.md
index 13094d2b..223e678d 100644
--- a/lint_rules/no_non_null_assertion.md
+++ b/lint_rules/no_non_null_assertion.md
@@ -6,7 +6,7 @@ tell the type system new information is often a sign that code is not fully
 type-safe. It's generally better to structure program logic so that TypeScript
 understands when values may be nullable.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 interface Example {
@@ -17,7 +17,7 @@ declare const example: Example;
 const includes = example.property!.includes("foo");
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 interface Example {
diff --git a/lint_rules/no_obj_calls.md b/lint_rules/no_obj_calls.md
index b73fba17..e2b04f31 100644
--- a/lint_rules/no_obj_calls.md
+++ b/lint_rules/no_obj_calls.md
@@ -11,7 +11,7 @@ they look like constructors:
 Calling these as functions would result in runtime errors. This rule statically
 prevents such wrong usage of them.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const math = Math();
@@ -27,7 +27,7 @@ const atomics = Atomics();
 const newAtomics = new Atomics();
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const area = (radius: number): number => Math.PI * radius * radius;
diff --git a/lint_rules/no_octal.md b/lint_rules/no_octal.md
index 45c014ab..0bd47173 100644
--- a/lint_rules/no_octal.md
+++ b/lint_rules/no_octal.md
@@ -7,14 +7,14 @@ mode throws `SyntaxError` for the expression.
 Since ES2015, the other prefix `0o` has been introduced as an alternative. This
 new one is always encouraged to use in today's code.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = 042;
 const b = 7 + 042;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a = 0o42;
diff --git a/lint_rules/no_process_global.md b/lint_rules/no_process_global.md
index a9eca104..87401c80 100644
--- a/lint_rules/no_process_global.md
+++ b/lint_rules/no_process_global.md
@@ -4,14 +4,14 @@ NodeJS and Deno expose `process` global but they are hard to statically analyze
 by tools, so code should not assume they are available. Instead,
 `import process from "node:process"`.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // foo.ts
 const foo = process.env.FOO;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // foo.ts
diff --git a/lint_rules/no_prototype_builtins.md b/lint_rules/no_prototype_builtins.md
index b4012295..9f68e192 100644
--- a/lint_rules/no_prototype_builtins.md
+++ b/lint_rules/no_prototype_builtins.md
@@ -11,7 +11,7 @@ properties from `Object.prototype` and attempt to call the following methods:
 Instead, it's always encouraged to call these methods from `Object.prototype`
 explicitly.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = foo.hasOwnProperty("bar");
@@ -19,7 +19,7 @@ const b = foo.isPrototypeOf("bar");
 const c = foo.propertyIsEnumerable("bar");
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a = Object.prototype.hasOwnProperty.call(foo, "bar");
diff --git a/lint_rules/no_redeclare.md b/lint_rules/no_redeclare.md
index 9587da94..ad900a36 100644
--- a/lint_rules/no_redeclare.md
+++ b/lint_rules/no_redeclare.md
@@ -11,7 +11,7 @@ As for functions and parameters, JavaScript just treats these as runtime errors,
 throwing `SyntaxError` when being run. It's also beneficial to detect this sort
 of errors statically.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 var a = 3;
@@ -33,7 +33,7 @@ function e(arg: number) {
 function f(arg: number, arg: string) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 var a = 3;
diff --git a/lint_rules/no_regex_spaces.md b/lint_rules/no_regex_spaces.md
index fb7fb128..9e6356ea 100644
--- a/lint_rules/no_regex_spaces.md
+++ b/lint_rules/no_regex_spaces.md
@@ -14,7 +14,7 @@ const re = /foo   bar/;
 const re = /foo {3}var/;
 ```
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const re1 = /  /;
@@ -28,7 +28,7 @@ const re7 = new RegExp(" a b  c d ");
 const re8 = new RegExp("foo  {3}bar");
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const re1 = /foo/;
diff --git a/lint_rules/no_self_assign.md b/lint_rules/no_self_assign.md
index a6bc5af2..468fa911 100644
--- a/lint_rules/no_self_assign.md
+++ b/lint_rules/no_self_assign.md
@@ -4,7 +4,7 @@ Self assignments like `a = a;` have no effect at all. If there are self
 assignments in the code, most likely it means that the author is still in the
 process of refactoring and there's remaining work they have to do.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 a = a;
@@ -15,7 +15,7 @@ a = a;
 a.b = a.b;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let a = a;
diff --git a/lint_rules/no_self_compare.md b/lint_rules/no_self_compare.md
index 0862758d..b850d3d0 100644
--- a/lint_rules/no_self_compare.md
+++ b/lint_rules/no_self_compare.md
@@ -4,7 +4,7 @@ Comparing a variable or value against itself is usually an error, either a typo
 or refactoring error. It is confusing to the reader and may potentially
 introduce a runtime error.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (x === x) {
@@ -17,7 +17,7 @@ if (a["b"] === a["b"]) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (x === y) {
diff --git a/lint_rules/no_setter_return.md b/lint_rules/no_setter_return.md
index 1bc2500d..3e17615e 100644
--- a/lint_rules/no_setter_return.md
+++ b/lint_rules/no_setter_return.md
@@ -9,7 +9,7 @@ the linter is quite beneficial.
 Note that returning without a value is allowed; this is a useful technique to do
 early-return from a function.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = {
@@ -33,7 +33,7 @@ const c = {
 };
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // return without a value is allowed since it is used to do early-return
diff --git a/lint_rules/no_shadow_restricted_names.md b/lint_rules/no_shadow_restricted_names.md
index a4978ed7..f29e3401 100644
--- a/lint_rules/no_shadow_restricted_names.md
+++ b/lint_rules/no_shadow_restricted_names.md
@@ -31,7 +31,7 @@ function foo() {
 Of course, shadowing like this most likely confuse other developers and should
 be avoided. This lint rule detects and warn them.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const undefined = 42;
@@ -46,7 +46,7 @@ try {
 } catch (eval) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // If not assigned a value, `undefined` may be shadowed
diff --git a/lint_rules/no_sparse_arrays.md b/lint_rules/no_sparse_arrays.md
index 027b1520..0f86fac9 100644
--- a/lint_rules/no_sparse_arrays.md
+++ b/lint_rules/no_sparse_arrays.md
@@ -12,13 +12,13 @@ lead to unexpected behavior:
 [1, undefined, 2].flatMap((item) => item); // => [1, undefined, 2]
 ```
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const items = ["foo", , "bar"];
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const items = ["foo", "bar"];
diff --git a/lint_rules/no_sync_fn_in_async_fn.md b/lint_rules/no_sync_fn_in_async_fn.md
index 86ab9432..429fde63 100644
--- a/lint_rules/no_sync_fn_in_async_fn.md
+++ b/lint_rules/no_sync_fn_in_async_fn.md
@@ -4,7 +4,7 @@ Using sync functions like `Deno.readTextFileSync` blocks the deno event loop so
 it's not recommended to use it inside of an async function, because it stops
 progress of all other async tasks.
 
-### Invalid:
+**Invalid:**
 
 ```javascript
 async function foo() {
@@ -20,7 +20,7 @@ const fooFn = async () => {
 };
 ```
 
-### Valid:
+**Valid:**
 
 ```javascript
 async function foo() {
diff --git a/lint_rules/no_this_alias.md b/lint_rules/no_this_alias.md
index ea711517..30f4e671 100644
--- a/lint_rules/no_this_alias.md
+++ b/lint_rules/no_this_alias.md
@@ -66,7 +66,7 @@ obj.doSomethingLater();
 This example is taken from
 [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions).
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const self = this;
@@ -80,7 +80,7 @@ const bar = () => {
 };
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const self = "this";
diff --git a/lint_rules/no_this_before_super.md b/lint_rules/no_this_before_super.md
index bfa67a8d..918f9e17 100644
--- a/lint_rules/no_this_before_super.md
+++ b/lint_rules/no_this_before_super.md
@@ -7,7 +7,7 @@ constructors.
 
 [`ReferenceError`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/ReferenceError
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 class A extends B {
@@ -25,7 +25,7 @@ class C extends D {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 class A extends B {
diff --git a/lint_rules/no_throw_literal.md b/lint_rules/no_throw_literal.md
index 996b669d..76770d9f 100644
--- a/lint_rules/no_throw_literal.md
+++ b/lint_rules/no_throw_literal.md
@@ -5,7 +5,7 @@ object using the `Error` object as base objects for user-defined exceptions. The
 fundamental benefit of `Error` objects is that they automatically keep track of
 where they were built and originated.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 throw "error";
@@ -14,7 +14,7 @@ throw undefined;
 throw null;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 throw new Error("error");
diff --git a/lint_rules/no_top_level_await.md b/lint_rules/no_top_level_await.md
index bdbc0127..ddb093ba 100644
--- a/lint_rules/no_top_level_await.md
+++ b/lint_rules/no_top_level_await.md
@@ -2,14 +2,14 @@ Disallows the use of top level await expressions.
 
 Top level await cannot be used when distributing CommonJS/UMD via dnt.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 await foo();
 for await (item of items) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 async function foo() {
diff --git a/lint_rules/no_undef.md b/lint_rules/no_undef.md
index ee8fb8f0..07c3fe32 100644
--- a/lint_rules/no_undef.md
+++ b/lint_rules/no_undef.md
@@ -1,6 +1,6 @@
 Disallow the use of undeclared variables
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const foo = someFunction();
diff --git a/lint_rules/no_unreachable.md b/lint_rules/no_unreachable.md
index 7a608913..bdc4e755 100644
--- a/lint_rules/no_unreachable.md
+++ b/lint_rules/no_unreachable.md
@@ -4,7 +4,7 @@ Because the control flow statements (`return`, `throw`, `break` and `continue`)
 unconditionally exit a block of code, any statements after them cannot be
 executed.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function foo() {
@@ -48,7 +48,7 @@ for (;;) {}
 console.log("done");
 ```
 
-### Valid
+**Valid:**
 
 ```typescript
 function foo() {
diff --git a/lint_rules/no_unsafe_finally.md b/lint_rules/no_unsafe_finally.md
index c921926f..a76c88e9 100644
--- a/lint_rules/no_unsafe_finally.md
+++ b/lint_rules/no_unsafe_finally.md
@@ -4,7 +4,7 @@ Use of the control flow statements (`return`, `throw`, `break` and `continue`)
 overrides the usage of any control flow statements that might have been used in
 the `try` or `catch` blocks, which is usually not the desired behaviour.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let foo = function () {
@@ -30,7 +30,7 @@ let foo = function () {
 };
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let foo = function () {
diff --git a/lint_rules/no_unsafe_negation.md b/lint_rules/no_unsafe_negation.md
index 9ae28f98..179bc06a 100644
--- a/lint_rules/no_unsafe_negation.md
+++ b/lint_rules/no_unsafe_negation.md
@@ -12,7 +12,7 @@ they want it to behave just like `!(key in someObject)`, but actually it behaves
 like `(!key) in someObject`. This lint rule warns such usage of `!` operator so
 it will be less confusing.
 
-### Invalid:
+**Invalid:**
 
 <!-- deno-fmt-ignore -->
 
@@ -21,7 +21,7 @@ if (!key in object) {}
 if (!foo instanceof Foo) {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (!(key in object)) {}
diff --git a/lint_rules/no_unused_labels.md b/lint_rules/no_unused_labels.md
index da6c8087..f5372d7a 100644
--- a/lint_rules/no_unused_labels.md
+++ b/lint_rules/no_unused_labels.md
@@ -4,7 +4,7 @@ A label that is declared but never used is most likely developer's mistake. If
 that label is meant to be used, then write a code so that it will be used.
 Otherwise, remove the label.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 LABEL1:
@@ -23,7 +23,7 @@ for (const x of xs) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 LABEL1:
diff --git a/lint_rules/no_unused_vars.md b/lint_rules/no_unused_vars.md
index cd07708b..acc384dc 100644
--- a/lint_rules/no_unused_vars.md
+++ b/lint_rules/no_unused_vars.md
@@ -25,7 +25,7 @@ If you want to declare unused variables intentionally, prefix them with the
 underscore character `_`, like `_a`. This rule ignores variables that are
 prefixed with `_`.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = 0;
@@ -55,7 +55,7 @@ export function e(x: number): number {
 const f = "unused variable";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a = 0;
diff --git a/lint_rules/no_useless_rename.md b/lint_rules/no_useless_rename.md
index d36c8955..af3e69fd 100644
--- a/lint_rules/no_useless_rename.md
+++ b/lint_rules/no_useless_rename.md
@@ -2,7 +2,7 @@ Disallow useless rename operations where both the original and new name are
 exactly the same. This is often a leftover from a refactoring procedure and can
 be safely removed.
 
-### Invalid:
+**Invalid:**
 
 ```ts
 import { foo as foo } from "foo";
@@ -10,7 +10,7 @@ const { foo: foo } = obj;
 export { foo as foo };
 ```
 
-### Valid:
+**Valid:**
 
 ```ts
 import { foo as bar } from "foo";
diff --git a/lint_rules/no_var.md b/lint_rules/no_var.md
index 89c3cbc1..7baeacb3 100644
--- a/lint_rules/no_var.md
+++ b/lint_rules/no_var.md
@@ -5,13 +5,13 @@ variables. Block scoped variables are defined using `const` and `let` keywords.
 not accessible outside their block scope. On the other hand, variables defined
 using `var` keyword are only limited by their function scope.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 var foo = "bar";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const foo = 1;
diff --git a/lint_rules/no_window_global.md b/lint_rules/no_window_global.md
index e814c81c..54d7fdd8 100644
--- a/lint_rules/no_window_global.md
+++ b/lint_rules/no_window_global.md
@@ -4,7 +4,7 @@ The `window` global is no longer available in Deno. Deno does not have a window
 and `typeof window === "undefined"` is often used to tell if the code is running
 in the browser.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = await window.fetch("https://deno.land");
@@ -17,7 +17,7 @@ window.addEventListener("load", () => {
 });
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a1 = await fetch("https://deno.land");
diff --git a/lint_rules/no_window_prefix.md b/lint_rules/no_window_prefix.md
index 80905ca0..1ecfb614 100644
--- a/lint_rules/no_window_prefix.md
+++ b/lint_rules/no_window_prefix.md
@@ -13,7 +13,7 @@ different meanings in Workers. In other words, this lint rule complains about
 the use of `window` only if it's completely replaceable with `self`,
 `globalThis`, or no prefix.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const a = await window.fetch("https://deno.land");
@@ -21,7 +21,7 @@ const a = await window.fetch("https://deno.land");
 const b = window.Deno.metrics();
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const a1 = await fetch("https://deno.land");
diff --git a/lint_rules/no_with.md b/lint_rules/no_with.md
index adc7a52c..e38fbf2d 100644
--- a/lint_rules/no_with.md
+++ b/lint_rules/no_with.md
@@ -5,7 +5,7 @@ and compatibility issues. For more details, see [with - JavaScript | MDN].
 
 [with - JavaScript | MDN]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/with
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 with (someVar) {
diff --git a/lint_rules/prefer_as_const.md b/lint_rules/prefer_as_const.md
index 5e1d9b8d..45cf65b3 100644
--- a/lint_rules/prefer_as_const.md
+++ b/lint_rules/prefer_as_const.md
@@ -11,7 +11,7 @@ This lint rule suggests using const assertion because it will generally lead to
 a safer code. For more details about const assertion, see
 [the official handbook](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-4.html#const-assertions).
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let a: 2 = 2; // type annotation
@@ -20,7 +20,7 @@ let c = <2> 2; // type assertion
 let d = { foo: 1 as 1 }; // type assertion
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 let a = 2 as const;
diff --git a/lint_rules/prefer_ascii.md b/lint_rules/prefer_ascii.md
index 61ea9518..6ca4a20b 100644
--- a/lint_rules/prefer_ascii.md
+++ b/lint_rules/prefer_ascii.md
@@ -14,7 +14,7 @@ Deno's internal JavaScript code. If you want to make sure your codebase is made
 up of ASCII characters only (e.g. want to disallow non-ASCII identifiers) for
 some reasons, then this rule will be helpful.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const π = Math.PI;
@@ -32,7 +32,7 @@ function こんにちは(名前: string) {
 // U+201C
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const pi = Math.PI;
diff --git a/lint_rules/prefer_const.md b/lint_rules/prefer_const.md
index a9b3f9cb..59b18fc0 100644
--- a/lint_rules/prefer_const.md
+++ b/lint_rules/prefer_const.md
@@ -20,7 +20,7 @@ detecting and warning [`var`] variables.
 [`const`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/const
 [`var`]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/var
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 let a = 0;
@@ -40,7 +40,7 @@ let e;
 e = 2;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 // uninitialized variable is allowed
diff --git a/lint_rules/prefer_namespace_keyword.md b/lint_rules/prefer_namespace_keyword.md
index 6450eb82..e6c809c3 100644
--- a/lint_rules/prefer_namespace_keyword.md
+++ b/lint_rules/prefer_namespace_keyword.md
@@ -8,7 +8,7 @@ always use `namespace` instead whenever we write TypeScript these days. See
 [TypeScript v1.5 release note](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-1-5.html#namespace-keyword)
 for more details.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 module modA {}
@@ -16,7 +16,7 @@ module modA {}
 declare module modB {}
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 namespace modA {}
diff --git a/lint_rules/prefer_primordials.md b/lint_rules/prefer_primordials.md
index d6150ced..02444a72 100644
--- a/lint_rules/prefer_primordials.md
+++ b/lint_rules/prefer_primordials.md
@@ -22,7 +22,7 @@ The second line of this example should be:
 const evens = primordials.ArrayPrototypeFilter(arr, (val) => val % 2 === 0);
 ```
 
-### Invalid:
+**Invalid:**
 
 ```javascript
 const arr = new Array();
@@ -34,7 +34,7 @@ const i = parseInt("42");
 const { ownKeys } = Reflect;
 ```
 
-### Valid:
+**Valid:**
 
 ```javascript
 const { Array } = primordials;
diff --git a/lint_rules/require_await.md b/lint_rules/require_await.md
index de7b80b5..2e6f00e4 100644
--- a/lint_rules/require_await.md
+++ b/lint_rules/require_await.md
@@ -5,7 +5,7 @@ In general, the primary reason to use async functions is to use await
 expressions or await using declarations inside. If an async function has
 neither, it is most likely an unintentional mistake.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 async function f1() {
@@ -31,7 +31,7 @@ class MyClass {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 await asyncFunction();
diff --git a/lint_rules/require_yield.md b/lint_rules/require_yield.md
index 08f855a0..f7e6f3b2 100644
--- a/lint_rules/require_yield.md
+++ b/lint_rules/require_yield.md
@@ -6,7 +6,7 @@ points we use the `yield` keyword. In other words, it makes no sense at all to
 create generator functions that contain no `yield` keyword, since such functions
 could be written as normal functions.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 function* f1() {
@@ -14,7 +14,7 @@ function* f1() {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 function* f1() {
diff --git a/lint_rules/single_var_declarator.md b/lint_rules/single_var_declarator.md
index 4c4ce251..8052d569 100644
--- a/lint_rules/single_var_declarator.md
+++ b/lint_rules/single_var_declarator.md
@@ -1,12 +1,12 @@
 Disallows multiple variable definitions in the same declaration statement
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 const foo = 1, bar = "2";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 const foo = 1;
diff --git a/lint_rules/triple_slash_reference.md b/lint_rules/triple_slash_reference.md
index c893824b..e68d51db 100644
--- a/lint_rules/triple_slash_reference.md
+++ b/lint_rules/triple_slash_reference.md
@@ -7,14 +7,14 @@ directives is generally discouraged in favor of ECMAScript Module imports. This
 rule reports on the use of `/// <reference path="..." />`,
 `/// <reference types="..." />`, or `/// <reference lib="..." />` directives.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 /// <reference types="foo" />
 import * as foo from "foo";
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 import * as foo from "foo";
diff --git a/lint_rules/use_isnan.md b/lint_rules/use_isnan.md
index 401e0992..b861d371 100644
--- a/lint_rules/use_isnan.md
+++ b/lint_rules/use_isnan.md
@@ -9,7 +9,7 @@ itself, the results of comparisons to `NaN` are confusing:
 Therefore, this rule makes you use the `isNaN()` or `Number.isNaN()` to judge
 the value is `NaN` or not.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 if (foo == NaN) {
@@ -31,7 +31,7 @@ switch (foo) {
 }
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 if (isNaN(foo)) {
diff --git a/lint_rules/valid_typeof.md b/lint_rules/valid_typeof.md
index 3baa3a0b..8e4e3b52 100644
--- a/lint_rules/valid_typeof.md
+++ b/lint_rules/valid_typeof.md
@@ -22,7 +22,7 @@ as this cannot be guaranteed. An exception to this is comparing the results of
 two `typeof` operations as these are both guaranteed to return on of the above
 strings.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 // typo
@@ -38,7 +38,7 @@ typeof baz === anotherVariable;
 typeof foo == 5;
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 typeof foo === "undefined";
diff --git a/lint_rules/verbatim_module_syntax.md b/lint_rules/verbatim_module_syntax.md
index 2a452928..06924be1 100644
--- a/lint_rules/verbatim_module_syntax.md
+++ b/lint_rules/verbatim_module_syntax.md
@@ -4,7 +4,7 @@ This rule ensures that the code works when the `verbatimModuleSyntax` TypeScript
 compiler option is enabled. This is useful in libraries distributing TypeScript
 code in order to work in more scenarios.
 
-### Invalid:
+**Invalid:**
 
 ```typescript
 import { Person } from "./person.ts";
@@ -24,7 +24,7 @@ const person: Person = {
 output(person);
 ```
 
-### Valid:
+**Valid:**
 
 ```typescript
 import type { Person } from "./person.ts";
diff --git a/runtime/reference/cli/lint.md b/runtime/reference/cli/lint.md
index 76f55dd4..0dbb9b8e 100644
--- a/runtime/reference/cli/lint.md
+++ b/runtime/reference/cli/lint.md
@@ -14,16 +14,13 @@ templateEngine: [vto, md]
 For a complete list of supported rules, visit
 [the deno_lint rule documentation](https://lint.deno.land).
 
-<ul>
 {{ for lintRule of await generateLintRuleList() }}
-  <li>
-    <b>{{ lintRule.name }}</b>
-    <pre>
-      {{ lintRule.mdContent.slice(0, 100) }}
-    </pre>
-  </li>
+
+### {{ lintRule.name }}
+
+{{ lintRule.mdContent }}
+
 {{ /for }}
-</ul>
 
 ## Ignore directives