diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index 35967a1a21..4f351aa9c3 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -1,30 +1,43 @@
 <!--- Provide a general summary of your changes in the Title above -->
 
 ## Description
+
 <!--- Describe your changes in detail -->
 
 ## Related Issue
+
 <!--- This project only accepts pull requests related to open issues -->
+
 <!--- If suggesting a new feature or change, please discuss it in an issue first -->
+
 <!--- If fixing a bug, there should be an issue describing it with steps to reproduce -->
+
 <!--- Please link to the issue here: -->
 
 ## Motivation and Context
+
 <!--- Why is this change required? What problem does it solve? -->
 
 ## How Has This Been Tested?
+
 <!--- Please describe in detail how you tested your changes. -->
+
 <!--- Include details of your testing environment, and the tests you ran to -->
+
 <!--- see how your change affects other areas of the code, etc. -->
 
 ## Screenshots (if appropriate):
 
+<!--- Drag and drop screenshots here -->
+
 ## Checklist:
+
 <!--- Go over all the following points, and put an `x` in all the boxes that apply. -->
+
 <!--- If you're unsure about any of these, don't hesitate to ask. We're here to help! -->
 
-- [ ] My code follows the code style of this project.
-- [ ] My change requires a change to the documentation.
-- [ ] I have updated the documentation accordingly.
-- [ ] I have added tests to cover my changes.
-- [ ] All new and existing tests passed.
+* \[ ] My code follows the code style of this project.
+* \[ ] My change requires a change to the documentation.
+* \[ ] I have updated the documentation accordingly.
+* \[ ] I have added tests to cover my changes.
+* \[ ] All new and existing tests passed.
diff --git a/.remarkrc.yaml b/.remarkrc.yaml
index cf4ada6d5f..381dd0220c 100644
--- a/.remarkrc.yaml
+++ b/.remarkrc.yaml
@@ -21,7 +21,6 @@ plugins:
   - remark-lint-list-item-bullet-indent
   - remark-lint-list-item-content-indent
   - remark-lint-maximum-heading-length: 120
-  - remark-lint-no-auto-link-without-protocol
   - remark-lint-no-blockquote-without-marker
   - remark-lint-no-consecutive-blank-lines
   - remark-lint-no-duplicate-definitions
@@ -36,7 +35,6 @@ plugins:
   - remark-lint-no-heading-content-indent
   - remark-lint-no-heading-indent
   - remark-lint-no-heading-like-paragraph
-  - remark-lint-no-inline-padding
   - remark-lint-no-literal-urls
   - remark-lint-no-multiple-toplevel-headings
   - remark-lint-no-reference-like-url
diff --git a/BREAKING_CHANGES.md b/BREAKING_CHANGES.md
index ec20701053..8d5b4408b7 100644
--- a/BREAKING_CHANGES.md
+++ b/BREAKING_CHANGES.md
@@ -11,14 +11,19 @@
 ### Configuration changes:
 
 * The configuration properties `continuous-delivery-fallback-tag`, `tag-number-pattern`, and `tag` were renamed to `continuous-delivery-fallback-label`, `label-number-pattern`, and `label` respectively. `tag-pre-release-weight` and `tag-prefix` remained as they were as they are referring to a Git tag.
+
 * When using a commit message that matches **both** `*-version-bump-message` and `no-bump-message`, there is no increment for that commit. In other words, `no-bump-message` now takes precedence over `*-version-bump-message`.
+
 * The fallback version strategy now returns `0.0.0` and is flagged with `ShouldIncrement` equal to `true`. This yields the version `0.1.0` on the `develop` branch (`IncrementStrategy.Minor` by default) and `0.0.1` on the `main` branch (`IncremetnStrategy.Patch` by default).
+
 * The current branch (child) inherits its configuration from the source (parent) branch if the `increment` strategy is set to `Inherit`. This makes branch configuration recursive, simpler, more intuitive, more flexible, and more robust.
+
 * Instead of having a single effective configuration, we now have one effective configuration per branch where the increment strategy is not set to `inherit`.
+
 * The new implementation of the branch configuration inheritance affects per default only the pull-requests, hotfix and feature branches. In this case the next version will be generated like the child branch is not existing and the commits have been made on the source branch.
   * The following example illustrates this behavior. On the feature branch the semantic version `1.1.0-just-a-test.1+2` will now be generated instead of version `1.0.0-just-a-test.1+3` previously:
 
-    ``` log
+    ```log
     * 1f1cfb4 52 minutes ago  (HEAD -> feature/just-a-test)
     * 1f9654d 54 minutes ago  (release/1.1.0)
     * be72411 56 minutes ago  (develop)
@@ -26,34 +31,49 @@
     ```
 
 * A new `unknown` branch magic string has been introduced to give the user the possibility to specify the branch configuration for a branch which is not known. A branch is not known if only the regular expression of the branch configuration with the name `unknown` is matching. Please notice that this branch configuration behaves like any other branch configurations.
+
 * Additional `fallback` branch configuration properties have been introduced at the root to define base properties which will be inherit to the branch configurations. That means if no other branch configuration in the inheritance line defines the given property the fallback property applies. Notice that the inheritance tree can be controlled using the increment strategy property in the branch configuration section.
   * The following example illustrates this behavior. The hotfix branch configuration overrides the main branch configuration and the result overrides the fallback branch configuration.
 
-    ``` log
+    ```log
     * 1f1cfb4 52 minutes ago  (HEAD -> hotfix/just-a-test)
     * 14800ff 58 minutes ago  (tag: 1.0.0, main)
     ```
 
 * When overriding the configuration with e.g. GitVersion.yaml the software distinguishes between properties who are not existent and properties who are `null`. This is especially important if the user wants to define branch related configuration which are marked with `increment` strategy `Inherit`.
+
 * Following root configuration properties have been removed:
   * continuous-delivery-fallback-tag
+
 * A new branch related property with name `track-merge-message` has been introduced. Consider we have a `main` branch and a `release/1.0.0` branch and merge changes from `release/1.0.0` to the main branch. In this scenario the merge message will be interpreted as a next version `1.0.0` when `track-merge-message` is set to `true` otherwise `0.0.1`.
+
 * The pre-release tags are only considered when they are matching with the label name of the branch. This has an effect on the way how the `CommitCountSource` will be determined.
+
 * The process of increasing the version with bump message when `CommitMessageIncrementing` is enabled and increment strategy is `None` has been changed.
+
 * A new configuration property with name `version-in-branch-pattern` has been introduced. This setting only applies on branches where the option `is-release-branch` is set to `true`. Please notice that the branch name needs to be defined after the version number by default (instead of `support/lts-2.0.0` please name the branch like `support/2.0.0-lts`).
+
 * The `is-release-branch` property of the `hotfix` branch setting has been changed from `false` to `true`. If present the hotfix number will be considered now by default.
+
 * In the GitHub and the Git Flow workflows the `label` property is by default set to an empty string on the `main` branch. This yields to a pre-release version on `main` with an empty tag. Instead of for instance `1.0.1+46` GitVersion generates the full semantic version `1.0.1-46` instead. This behavior can be changed to generate only stable versions (no pre-release version) with setting the label to `null` (Please keep in mind that the `label` property on root needs to be set to `null` as well, otherwise the fallback applies). This change is caused by issue #2347.
+
 * The `useBranchName` magic string has been removed. Instead use `{BranchName}` for `label`.
+
 * The `BranchPrefixToTrim` configuration property has been removed. `RegularExpression` is now used to capture named groups instead.
   * Default `RegularExpression` for feature branches is changed from `^features?[/-]` to `^features?[/-](?<BranchName>.+)` to support using `{BranchName}` out-of-the-box
   * Default `RegularExpression` for unknown branches is changed from `.*` to `(?<BranchName>.+)` to support using `{BranchName}` out-of-the-box
+
 * The `Mainline` mode and the related implementation has been removed completely. The new `Mainline` version strategy should be used instead.
+
 * The `Mainline` version strategy doesn't support downgrading the increment for calculating the next version. This is the case if e.g. a bump messages has been defined which is lower than the branch increment.
+
 * The branch related property `is-mainline` in the configuration system has been renamed to `is-main-branch`
+
 * The versioning mode has been renamed to deployment mode and consists of following values:
   * ManualDeployment (previously ContinuousDelivery)
   * ContinuousDelivery (previously ContinuousDeployment)
   * ContinuousDeployment (new)
+
 * At the configuration root level, a new array called `strategies` has been introduced, which can consist of on or more following values:
   * ConfiguredNextVersion
   * MergeMessage
@@ -61,14 +81,21 @@
   * TrackReleaseBranches
   * VersionInBranchName
   * Mainline
+
 * The initialization wizard has been removed.
+
 * On the `develop`, `release` and `hotfix` branch the introduced branch related property `prevent-increment.when-current-commit-tagged` has been set to `false` to get the incremented instead of the tagged semantic version.
+
 * When setting the "ignore commits before" parameter to a future value, an exception will occur if no commits are found on the current branch. This behavior mimics that of an empty repository.
+
 * On the `GitFlow` workflow the increment property has been changed:
   * in branch `release` from `None` to `Minor` and
   * in branch `hotfix` from `None` to `Patch`
+
 * On the `GitHubFlow` workflow the increment property has been changed in branch `release` from `None` to `Patch`.
+
 * When creating a branch with name `hotfix/next` (by using the `GitFlow` workflow) or `release/next` (by the `GitHubFlow` workflow) the resulting version will yield to a patched version per default.
+
 * If you have a tag `1.0.0` on `main` and branch from `main` to `release/1.0.1` then the next version number will be `1.1.0` when using the `GitFlow` workflow. This behavior is expected (but different compared to the `GitHubFlow` workflow) because on the `GitFlow` workflow you have an addition branch configuration with name hotfix where `is-release-branch` is set to `true`. That means if you want `1.0.1` as a next version you need to branch to `hotfix/1.0.1` or `hotfix/next`.  On the other hand if you use the `GitHubFlow` workflow the next version number will be `1.0.1` because the increment on the `release` branch is set to `Patch`.
 
 ### Legacy Output Variables
@@ -87,9 +114,9 @@ The following legacy output variables have been removed in this version:
 ## v5.0.0
 
 * Version numbers in branches other than `release` branches are no longer
-    considered as a version source by default. Implemented in [#1541][pr-1541].
+  considered as a version source by default. Implemented in [#1541][pr-1541].
 * [#1581][pr-1581] folds `GitTools.Core` back into GitVersion to make
-    maintaining GitVersion easier.
+  maintaining GitVersion easier.
 
 ## v4.0.0
 
@@ -107,27 +134,29 @@ work for you
 * `GitVersionConfig.yaml` is deprecated in favor of `GitVersion.yml`.
 * Regular expressions are no longer used as keys in branch config
   * We have named branches, and introduced a `regex` config which you can
-        override.
+    override.
   * The default keys are: `master`, `develop`, `feature`, `release`, `pull-request`,
-        `hotfix` and `support`
+    `hotfix` and `support`
   * Just run `GitVersion.exe` in your project directory and it will tell you
-        what to change your config keys to
+    what to change your config keys to
   * For example, `dev(elop)?(ment)?$` is now just `develop`, we suggest not
-        overring regular expressions unless you really want to use a different convention.
+    overring regular expressions unless you really want to use a different convention.
 * `source-branches` added as a configuration option for branches, it helps
-    GitVersion pick the correct source branch
+  GitVersion pick the correct source branch
 
 ## v3.0.0
 
 * NextVersion.txt has been deprecated, only `GitVersionConfig.yaml` is supported
 * `AssemblyFileSemVer` variable removed, `AssemblyVersioningScheme` configuration
-    value makes this variable obsolete
+  value makes this variable obsolete
 * Variables `ClassicVersion` and `ClassicVersionWithTag` removed
 * MSBuild task arguments (`AssemblyVersioningScheme`, `DevelopBranchTag`,
-    `ReleaseBranchTag`, `TagPrefix`, `NextVersion`) have been removed, use
-    `GitVersionConfig.yaml` instead
+  `ReleaseBranchTag`, `TagPrefix`, `NextVersion`) have been removed, use
+  `GitVersionConfig.yaml` instead
 * GitVersionTask's `ReleaseDateAttribute` no longer exists
 
 [gitflow]: https://gitversion.net/docs/learn/branching-strategies/gitflow-examples_complete
+
 [pr-1541]: https://github.com/GitTools/GitVersion/pull/1541
+
 [pr-1581]: https://github.com/GitTools/GitVersion/pull/1581
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index fa2ab0c87e..ac82b46b95 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -17,9 +17,9 @@ Issues are also welcome, [failing tests](#writing-tests) are even more welcome.
 * Try to use feature branches rather than developing on main.
 * Please include tests covering the change.
 * The documentation is stored in the repository under the [`docs`](docs) folder.
-    Have a look at the [documentation readme file](docs/readme.md) for guidance
-    on how to improve the documentation and please include documentation updates
-    with your PR.
+  Have a look at the [documentation readme file](docs/readme.md) for guidance
+  on how to improve the documentation and please include documentation updates
+  with your PR.
 
 ## How it works
 
@@ -100,15 +100,15 @@ We use Cake for our build and deployment process. The way the release process is
 
 1. We build releasable artifacts with GitHub Actions
 2. We create a milestone for the release if it's not already created. Our milestones are named using the semver.
-    For example `5.12.0` or `6.0.0-beta.2`
+   For example `5.12.0` or `6.0.0-beta.2`
 3. We move all the closed issues and closed pull requests that are going to be included in the release to the milestone.
 4. We check that all the issues and pull requests that are going to be included in the release have a label assigned,
-    otherwise it will fail the release.
+   otherwise it will fail the release.
 5. We create a release in the GitHub UI, and create a tag and name it using the milestone name. For example `5.12.0` or `6.0.0-beta.2`
 6. We specify if the release is a pre-release or latest release in the GitHub UI.
 7. We publish the release.
 8. The GitHub Actions will create a GitHub release and publish the artifacts to NuGet, Chocolatey, Docker, Homebrew
-    and other distribution channels.
+   and other distribution channels.
 9. The issues and pull requests will get updated with message specifying in which release it was included.
 
 ## Code Style
diff --git a/README.md b/README.md
index b9498ad3b2..849048e10a 100644
--- a/README.md
+++ b/README.md
@@ -49,41 +49,78 @@ You are seeing:
 designed by [David Chapman][app-icon-author]
 from The Noun Project.
 
-[semver]:                          https://semver.org
-[gitter]:                          https://gitter.im/GitTools/GitVersion?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
-[gitter-badge]:                    https://badges.gitter.im/Join+Chat.svg
-[azure-pipeline]:                  https://dev.azure.com/GitTools/GitVersion/_build/latest?definitionId=1
-[azure-pipeline-badge]:            https://dev.azure.com/GitTools/GitVersion/_apis/build/status/GitTools.GitVersion
-[github-actions]:                  https://github.com/GitTools/GitVersion/actions
-[github-actions-badge]:            https://github.com/GitTools/GitVersion/workflows/CI/badge.svg
-[codecov]:                         https://codecov.io/gh/GitTools/GitVersion
-[codecov-badge]:                   https://codecov.io/gh/GitTools/GitVersion/branch/main/graph/badge.svg
-[docs]:                            https://gitversion.net/docs/
-[gh-rel]:                          https://github.com/GitTools/GitVersion/releases/latest
-[gh-rel-badge]:                    https://img.shields.io/github/release/gittools/gitversion.svg?logo=github
-[choco]:                           https://chocolatey.org/packages/GitVersion.Portable
-[choco-badge]:                     https://img.shields.io/chocolatey/v/gitversion.portable.svg?logo=nuget
-[gvt]:                             https://www.nuget.org/packages/GitVersion.MsBuild
-[gvt-badge]:                       https://img.shields.io/nuget/v/GitVersion.MsBuild.svg?logo=nuget
-[gvgt]:                            https://www.nuget.org/packages/GitVersion.Tool
-[gvgt-badge]:                      https://img.shields.io/nuget/v/GitVersion.Tool.svg?logo=nuget
-[brew]:                            https://formulae.brew.sh/formula/gitversion
-[brew-badge]:                      https://img.shields.io/homebrew/v/gitversion.svg?logo=homebrew
-[winget]:                          https://github.com/microsoft/winget-pkgs/tree/master/manifests/g/GitTools/GitVersion
-[winget-badge]:                    https://img.shields.io/badge/winget-v6.0.2-blue.svg?logo=microsoft
-[dockerhub]:                       https://hub.docker.com/r/gittools/gitversion/
-[dockerhub-badge]:                 https://img.shields.io/docker/pulls/gittools/gitversion.svg?logo=docker
-[az-pipeline-task]:                https://marketplace.visualstudio.com/items?itemName=gittools.gittools
-[az-pipeline-task-badge]:          https://img.shields.io/badge/marketplace-gittools.gittools-blue?logo=azure-pipelines
-[gh-actions]:                      https://github.com/marketplace/actions/gittools
-[gh-actions-badge]:                https://img.shields.io/badge/marketplace-gittools-blue?logo=github
-[contribute]:                      https://github.com/GitTools/GitVersion/blob/main/CONTRIBUTING.md
-[why]:                             https://gitversion.net/docs/learn/why
-[usage]:                           https://gitversion.net/docs/usage
-[how]:                             https://gitversion.net/docs/learn/how-it-works
-[faq]:                             https://gitversion.net/docs/learn/faq
-[who]:                             https://gitversion.net/docs/learn/who
-[gv-in-action]:                    https://raw.githubusercontent.com/GitTools/GitVersion/master/docs/input/docs/img/README.png
-[banner]:                          https://raw.githubusercontent.com/GitTools/graphics/master/GitVersion/banner-1280x640.png
-[app-icon]:                        https://thenounproject.com/term/tree/13389/
-[app-icon-author]:                 https://thenounproject.com/david.chapman
+[semver]: https://semver.org
+
+[gitter]: https://gitter.im/GitTools/GitVersion?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
+
+[gitter-badge]: https://badges.gitter.im/Join+Chat.svg
+
+[azure-pipeline]: https://dev.azure.com/GitTools/GitVersion/_build/latest?definitionId=1
+
+[azure-pipeline-badge]: https://dev.azure.com/GitTools/GitVersion/_apis/build/status/GitTools.GitVersion
+
+[github-actions]: https://github.com/GitTools/GitVersion/actions
+
+[github-actions-badge]: https://github.com/GitTools/GitVersion/workflows/CI/badge.svg
+
+[codecov]: https://codecov.io/gh/GitTools/GitVersion
+
+[codecov-badge]: https://codecov.io/gh/GitTools/GitVersion/branch/main/graph/badge.svg
+
+[docs]: https://gitversion.net/docs/
+
+[gh-rel]: https://github.com/GitTools/GitVersion/releases/latest
+
+[gh-rel-badge]: https://img.shields.io/github/release/gittools/gitversion.svg?logo=github
+
+[choco]: https://chocolatey.org/packages/GitVersion.Portable
+
+[choco-badge]: https://img.shields.io/chocolatey/v/gitversion.portable.svg?logo=nuget
+
+[gvt]: https://www.nuget.org/packages/GitVersion.MsBuild
+
+[gvt-badge]: https://img.shields.io/nuget/v/GitVersion.MsBuild.svg?logo=nuget
+
+[gvgt]: https://www.nuget.org/packages/GitVersion.Tool
+
+[gvgt-badge]: https://img.shields.io/nuget/v/GitVersion.Tool.svg?logo=nuget
+
+[brew]: https://formulae.brew.sh/formula/gitversion
+
+[brew-badge]: https://img.shields.io/homebrew/v/gitversion.svg?logo=homebrew
+
+[winget]: https://github.com/microsoft/winget-pkgs/tree/master/manifests/g/GitTools/GitVersion
+
+[winget-badge]: https://img.shields.io/badge/winget-v6.0.2-blue.svg?logo=microsoft
+
+[dockerhub]: https://hub.docker.com/r/gittools/gitversion/
+
+[dockerhub-badge]: https://img.shields.io/docker/pulls/gittools/gitversion.svg?logo=docker
+
+[az-pipeline-task]: https://marketplace.visualstudio.com/items?itemName=gittools.gittools
+
+[az-pipeline-task-badge]: https://img.shields.io/badge/marketplace-gittools.gittools-blue?logo=azure-pipelines
+
+[gh-actions]: https://github.com/marketplace/actions/gittools
+
+[gh-actions-badge]: https://img.shields.io/badge/marketplace-gittools-blue?logo=github
+
+[contribute]: https://github.com/GitTools/GitVersion/blob/main/CONTRIBUTING.md
+
+[why]: https://gitversion.net/docs/learn/why
+
+[usage]: https://gitversion.net/docs/usage
+
+[how]: https://gitversion.net/docs/learn/how-it-works
+
+[faq]: https://gitversion.net/docs/learn/faq
+
+[who]: https://gitversion.net/docs/learn/who
+
+[gv-in-action]: https://raw.githubusercontent.com/GitTools/GitVersion/master/docs/input/docs/img/README.png
+
+[banner]: https://raw.githubusercontent.com/GitTools/graphics/master/GitVersion/banner-1280x640.png
+
+[app-icon]: https://thenounproject.com/term/tree/13389/
+
+[app-icon-author]: https://thenounproject.com/david.chapman
diff --git a/SECURITY.md b/SECURITY.md
index 6e07e80a06..5d4f3799c2 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -4,14 +4,14 @@
 
 | Version   | Supported          |
 | --------: | :----------------: |
-| 5.x       | :white_check_mark: |
+| 5.x       | :white\_check\_mark: |
 | ⋜ 5.x     | :x:                |
 
 ## Reporting Security Issues
 
 ⚠ **Please do not report security vulnerabilities through public GitHub issues.** ⚠
 
-Instead, please send an email to [security@gitversion.net](mailto:security@gitversion.net).
+Instead, please send an email to <security@gitversion.net>.
 
 You should receive a response within 24 hours. If for some reason you do not, please follow up via email to ensure we received your original message.
 
diff --git a/build/CI.sln b/build/CI.sln
index 4a5f522977..f0edfb151e 100644
--- a/build/CI.sln
+++ b/build/CI.sln
@@ -6,6 +6,13 @@ ProjectSection(SolutionItems) = preProject
 	..\global.json = ..\global.json
 	..\.gitignore = ..\.gitignore
 	..\.config\dotnet-tools.json = ..\.config\dotnet-tools.json
+	..\package.json = ..\package.json
+	
+	
+	
+	
+	
+	..\.remarkrc.yaml = ..\.remarkrc.yaml
 EndProjectSection
 EndProject
 Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "build", "build\build.csproj", "{1AC00FB2-E28A-46B7-9683-AA7A1AFC29EB}"
diff --git a/build/nuspec/README.md b/build/nuspec/README.md
index e91094077a..02b3c0314a 100644
--- a/build/nuspec/README.md
+++ b/build/nuspec/README.md
@@ -39,22 +39,38 @@ You are seeing:
 designed by [David Chapman][app-icon-author]
 from The Noun Project.
 
-[semver]:                          http://semver.org
-[gitter]:                          https://gitter.im/GitTools/GitVersion?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
-[gitter-badge]:                    https://badges.gitter.im/Join+Chat.svg
-[docs]:                            https://gitversion.net/docs/
-[gvt]:                             https://www.nuget.org/packages/GitVersion.MsBuild
-[gvt-badge]:                       https://img.shields.io/nuget/v/GitVersion.MsBuild.svg?logo=nuget
-[gitversiontask]:                  https://www.nuget.org/packages/GitVersionTask/
-[gvgt]:                            https://www.nuget.org/packages/GitVersion.Tool
-[gvgt-badge]:                      https://img.shields.io/nuget/v/GitVersion.Tool.svg?logo=nuget
-[contribute]:                      https://github.com/GitTools/GitVersion/blob/main/CONTRIBUTING.md
-[why]:                             https://gitversion.net/docs/learn/why
-[usage]:                           https://gitversion.net/docs/usage
-[how]:                             https://gitversion.net/docs/learn/how-it-works
-[faq]:                             https://gitversion.net/docs/learn/faq
-[who]:                             https://gitversion.net/docs/learn/who
-[gv-in-action]:                    https://raw.githubusercontent.com/GitTools/GitVersion/master/docs/input/docs/img/README.png
-[banner]:                          https://raw.githubusercontent.com/GitTools/graphics/master/GitVersion/banner-1280x640.png
-[app-icon]:                        https://thenounproject.com/term/tree/13389/
-[app-icon-author]:                 http://thenounproject.com/david.chapman
+[semver]: http://semver.org
+
+[gitter]: https://gitter.im/GitTools/GitVersion?utm_source=badge&utm_medium=badge&utm_campaign=pr-badge&utm_content=badge
+
+[gitter-badge]: https://badges.gitter.im/Join+Chat.svg
+
+[docs]: https://gitversion.net/docs/
+
+[gvt]: https://www.nuget.org/packages/GitVersion.MsBuild
+
+[gvt-badge]: https://img.shields.io/nuget/v/GitVersion.MsBuild.svg?logo=nuget
+
+[gvgt]: https://www.nuget.org/packages/GitVersion.Tool
+
+[gvgt-badge]: https://img.shields.io/nuget/v/GitVersion.Tool.svg?logo=nuget
+
+[contribute]: https://github.com/GitTools/GitVersion/blob/main/CONTRIBUTING.md
+
+[why]: https://gitversion.net/docs/learn/why
+
+[usage]: https://gitversion.net/docs/usage
+
+[how]: https://gitversion.net/docs/learn/how-it-works
+
+[faq]: https://gitversion.net/docs/learn/faq
+
+[who]: https://gitversion.net/docs/learn/who
+
+[gv-in-action]: https://raw.githubusercontent.com/GitTools/GitVersion/master/docs/input/docs/img/README.png
+
+[banner]: https://raw.githubusercontent.com/GitTools/graphics/master/GitVersion/banner-1280x640.png
+
+[app-icon]: https://thenounproject.com/term/tree/13389/
+
+[app-icon-author]: http://thenounproject.com/david.chapman
diff --git a/docs/input/docs/learn/branching-strategies/gitflow/examples.md b/docs/input/docs/learn/branching-strategies/gitflow/examples.md
index 1511b617fb..fd3876c5b0 100644
--- a/docs/input/docs/learn/branching-strategies/gitflow/examples.md
+++ b/docs/input/docs/learn/branching-strategies/gitflow/examples.md
@@ -10,6 +10,7 @@ These examples are illustrating the usage of the supported `GitFlow` workflow
 in GitVersion. To enable this workflow, the builtin template
 [GitFlow/v1](/docs/workflows/GitFlow/v1.json) needs to be referenced in the
 configuration as follows:
+
 ```yaml
 workflow: GitFlow/v1
 mode: ContinuousDelivery
@@ -45,7 +46,7 @@ created from a `develop`, `release`, `main`, `support` or `hotfix` branch.
 
 ### Create feature branch from main
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_FeatureFromMainBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_FeatureFromMainBranch.png)
 
 :::{.alert .alert-info}
 After the feature branch is merged, the version on `main` is `2.0.0-5`.
@@ -55,7 +56,7 @@ configured to use _continuous deployment_ the version would be `2.0.0`.
 
 ### Create feature branch from develop
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_FeatureFromDevelopBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_FeatureFromDevelopBranch.png)
 
 :::{.alert .alert-info}
 After the feature branch is merged, the version on `develop` is
@@ -72,23 +73,23 @@ Hotfix branches are used when you need to do a _patch_ release in the
 
 ### Create hotfix branch
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_HotfixBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_HotfixBranch.png)
 
 ### Create hotfix branch with version number
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_VersionedHotfixBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_VersionedHotfixBranch.png)
 
 ## Release Branches
 
-Release branches are used for major and minor releases to stabilize a RC 
+Release branches are used for major and minor releases to stabilize a RC
 (Release Candidate) or to integrate features (in parallel) targeting different
 iterations. Release branches are taken from `main` (or from `develop`) and will
 be merged back afterwards. Finally the `main` branch is tagged with the
 released version.
 
 Release branches can be used in the `GitFlow` as well as `GitHubFlow` workflow.
-Sometimes you want to start on a large feature which may take a while 
-to stabilize so you want to keep it off main. 
+Sometimes you want to start on a large feature which may take a while
+to stabilize so you want to keep it off main.
 In these scenarios you can either create a long lived
 feature branch (if you do not know the version number this large feature will go
 into, and it's non-breaking) otherwise you can create a release branch for the
@@ -97,15 +98,15 @@ branch or the release branch.
 
 ### Create release branch
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_ReleaseBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_ReleaseBranch.png)
 
 ### Create release branch with version
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_VersionedReleaseBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_VersionedReleaseBranch.png)
 
 ## Develop Branch
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_DevelopBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_DevelopBranch.png)
 
 ## Support Branches
 
@@ -116,7 +117,7 @@ majors, then name your branch `support/<major>.x` (i.e `support/1.x`), to
 support minors use `support/<major>.<minor>.x` or `support/<major>.<minor>.0`.
 (i.e `support/1.3.x` or `support/1.3.0`)
 
-![GitFlow](/docs/img/DocumentationSamplesForGitFlow\_SupportBranch.png)
+![GitFlow](/docs/img/DocumentationSamplesForGitFlow_SupportBranch.png)
 
 :::{.alert .alert-info}
 Depending on what you name your support branch, you may or may not need a
@@ -135,5 +136,7 @@ See [contributing examples](/docs/learn/branching-strategies/contribute-examples
 See `DocumentationSamplesForGitFlow.cs`. To update, modify then run test.
 
 [continuous-deployment]: /docs/reference/modes/continuous-deployment
+
 [continuous-delivery]: /docs/reference/modes/continuous-delivery
+
 [manual-deployment]: /docs/reference/modes/manual-deployment
diff --git a/docs/input/docs/learn/branching-strategies/gitflow/index.md b/docs/input/docs/learn/branching-strategies/gitflow/index.md
index dbb5688c1b..2c3019d88b 100644
--- a/docs/input/docs/learn/branching-strategies/gitflow/index.md
+++ b/docs/input/docs/learn/branching-strategies/gitflow/index.md
@@ -11,18 +11,18 @@ SemVer compatible versions from this structure.
 ## Assumptions:
 
 * Using [GitFlow branching model](https://nvie.com/git-model/) which always has a
-    main and a develop branch
+  main and a develop branch
 * Following [Semantic Versioning](https://semver.org/)
 * Planned releases (bumps in major or minor) are done on release branches
-    prefixed with release-. Eg: release-4.1 (or release-4.1.0)
+  prefixed with release-. Eg: release-4.1 (or release-4.1.0)
 * Hotfixes are prefixed with hotfix- Eg. hotfix-4.0.4
 * The original [GitFlow model](https://nvie.com/posts/a-successful-git-branching-model/)
-    specifies branches with a "-" separator while the [git flow extensions](https://github.com/CJ-Systems/gitflow-cjs)
-    default to a "/" separator.  Either work with GitVersion.
+  specifies branches with a "-" separator while the [git flow extensions](https://github.com/CJ-Systems/gitflow-cjs)
+  default to a "/" separator.  Either work with GitVersion.
 * Tags are used on the main branch and reflects the SemVer of each stable
-    release eg 3.3.8 , 4.0.0, etc
+  release eg 3.3.8 , 4.0.0, etc
 * Tags can also be used to override versions while we transition repositories
-    over to GitVersion
+  over to GitVersion
 * Using a build server with multi-branch building enabled eg TeamCity 8
 
 ## How Branches are handled
@@ -72,7 +72,7 @@ Long version:
 * minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
 * patch: 0
 * pre-release: `alpha.{n}` where n = how many commits `develop` is in front of
-    `mainVersionCommit.Date` ('0' padded to 4 characters)
+  `mainVersionCommit.Date` ('0' padded to 4 characters)
 
 Long version:
 
@@ -91,7 +91,7 @@ Named: `hotfix-{versionNumber}` eg `hotfix-1.2`
 * minor: `mergeVersion.Minor`
 * patch: `mergeVersion.Patch`
 * pre-release: `beta{n}` where n = number of commits on branch  ('0' padded to
-    4 characters)
+  4 characters)
 
 Long version:
 
@@ -116,7 +116,7 @@ tag would be `1.2.0-alpha1`
 * minor: `mergeVersion.Minor`
 * patch: 0
 * pre-release: `{releaseTag.preRelease}.{n}` where n = 1 + the number of commits
-    since `releaseTag`.
+  since `releaseTag`.
 
 So on a branch named `release-1.2` with a tag `1.2.0-alpha1` and 4 commits after
 that tag the version would be `1.2.0-alpha1.4`
@@ -143,7 +143,7 @@ branches named like "4.0.3"
 * minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
 * patch: 0
 * pre-release: `alpha.feature-{n}` where n = First 8 characters of the commit
-    SHA of the first commit
+  SHA of the first commit
 
 Long version:
 
@@ -163,7 +163,7 @@ Branch naming convention: anything except `main`, `develop`, `release-{n}`, or
 * minor: `mainMergeVersion.Minor + 1` (0 if the override above is used)
 * patch: 0
 * pre-release: `alpha.pull{n}` where n = the pull request number  ('0' padded to
-    4 characters)
+  4 characters)
 
 ## Nightly Builds
 
diff --git a/docs/input/docs/learn/branching-strategies/githubflow/examples.md b/docs/input/docs/learn/branching-strategies/githubflow/examples.md
index 0f79be951a..92f07d1e89 100644
--- a/docs/input/docs/learn/branching-strategies/githubflow/examples.md
+++ b/docs/input/docs/learn/branching-strategies/githubflow/examples.md
@@ -8,6 +8,7 @@ These examples are illustrating the usage of the supported `GitHubFlow` workflow
 in GitVersion. To enable this workflow, the builtin template
 [GitHubFlow/v1](/docs/workflows/GitHubFlow/v1.json) needs to be referenced in the
 configuration as follows:
+
 ```yaml
 workflow: GitHubFlow/v1
 mode: ContinuousDelivery
@@ -26,7 +27,7 @@ All other branches are manually published. Read more about this at
 [version increments](/docs/reference/version-increments).
 
 :::{.alert .alert-info}
-The _continuous delivery_ mode has been used for the `main` branch in this 
+The _continuous delivery_ mode has been used for the `main` branch in this
 examples (specified as a fallback on the root
 configuration layer) to illustrate how the version increments are applied.
 In production context the _continuous deployment_ mode might be a better
@@ -37,7 +38,7 @@ by the pipeline automatically.
 ## Feature Branch
 
 Feature branches can be used in the `GitHubFlow` workflow to implement a
-feature or fix a bug in an isolated environment. Feature branches will take 
+feature or fix a bug in an isolated environment. Feature branches will take
 the feature
 branch name and use that as the pre-release label. Feature branches will be
 created from a `main` or `release` branch.
@@ -87,5 +88,7 @@ See [contributing examples](/docs/learn/branching-strategies/contribute-examples
 See `DocumentationSamplesForGitHubFlow.cs`. To update, modify then run test.
 
 [continuous-deployment]: /docs/reference/modes/continuous-deployment
+
 [continuous-delivery]: /docs/reference/modes/continuous-delivery
+
 [manual-deployment]: /docs/reference/modes/manual-deployment
diff --git a/docs/input/docs/learn/branching-strategies/overview.md b/docs/input/docs/learn/branching-strategies/overview.md
index b5053214b3..4af9d6638f 100644
--- a/docs/input/docs/learn/branching-strategies/overview.md
+++ b/docs/input/docs/learn/branching-strategies/overview.md
@@ -28,7 +28,7 @@ and the branching strategy most open source projects use.
 
 * [Mainline development][mainline] on `main`.
 * Work on [feature branches][feature-branches], merge into `main` via a [pull
-    request][pull-request].
+  request][pull-request].
 * Works well for [continuous delivery][continuous-delivery].
 * Does not have a way to manage/maintain old releases.
 * Only allows working on a single release at a time.
@@ -41,7 +41,7 @@ more control over when features and code is released.
 * Development on `develop` branch.
 * `main` only contains _released_ code.
 * Supports maintaining old releases (like nServiceBus, they support the last 3
-    major versions with bug fixes and security updates).
+  major versions with bug fixes and security updates).
 * Supports development on multiple releases at one time.
 
 ## Choosing a branching strategy
@@ -52,16 +52,22 @@ There are a few reasons you would pick GitFlow over GitHubFlow, they are:
 2. You need to work on multiple releases at the same time.
 
 * For example a new feature which will go in the next major version, while bug
-    fixes/smaller features are still going into the current release
+  fixes/smaller features are still going into the current release
 
 But if you do not have a good reason to go with GitFlow, then start with
 GitHubFlow. It is a far simpler model and if you end up needing GitFlow later,
 it is [easy to convert][converting-to-gitflow].
 
 [continuous-delivery]: /docs/reference/modes/continuous-delivery
+
 [converting-to-gitflow]: /docs/learn/branching-strategies/gitflow/converting-to-gitflow
+
 [feature-branches]: /docs/learn/branching-strategies/gitflow/examples#feature-branches
+
 [gitflow]: /docs/learn/branching-strategies/gitflow
+
 [githubflow]: /docs/learn/branching-strategies/githubflow
+
 [mainline]: /docs/reference/modes/mainline
+
 [pull-request]: /docs/learn/branching-strategies/gitflow/examples#pull-request
diff --git a/docs/input/docs/learn/credits.md b/docs/input/docs/learn/credits.md
index d00e906c52..69e6326eb1 100644
--- a/docs/input/docs/learn/credits.md
+++ b/docs/input/docs/learn/credits.md
@@ -16,18 +16,33 @@ Icons sourced, with love, from [The Noun Project][the-noun-project]:
 :::
 
 [artz91]: https://thenounproject.com/ArtZ91/
+
 [collect-icon]: /assets/img/collect.svg
+
 [collect-link]: https://thenounproject.com/term/collect/424422/
+
 [david-chapman]: https://thenounproject.com/david.chapman/
+
 [ghayn]: https://thenounproject.com/Ghayn/
+
 [kevineichhorn]: https://thenounproject.com/kevineichhorn/
+
 [library-icon]: /assets/img/library.svg
+
 [library-link]: https://thenounproject.com/term/library/1386683/
+
 [monstercritic]: https://thenounproject.com/monstercritic/
+
 [repeat-icon]: /assets/img/repeat.svg
+
 [repeat-link]: https://thenounproject.com/term/repeat/304152/
+
 [terminal-icon]: /assets/img/terminal.svg
+
 [terminal-link]: https://thenounproject.com/term/terminal/2191738/
+
 [the-noun-project]: https://thenounproject.com/
+
 [tree-icon]: /assets/img/icon.svg
+
 [tree-link]: https://thenounproject.com/term/tree/13389/
diff --git a/docs/input/docs/learn/faq.md b/docs/input/docs/learn/faq.md
index b179215d85..4f972dad4a 100644
--- a/docs/input/docs/learn/faq.md
+++ b/docs/input/docs/learn/faq.md
@@ -69,8 +69,13 @@ therefore not be considered for version calculation in the target branch of the
 merge.
 
 [dynamic-repos]: /docs/learn/dynamic-repositories
+
 [increments]: /docs/reference/version-increments
+
 [octopus]: /docs/reference/build-servers/octopus-deploy
+
 [semver-intro]: /docs/learn/intro-to-semver
+
 [semver]: https://semver.org
+
 [variables]: /docs/reference/variables
diff --git a/docs/input/docs/learn/how-it-works.md b/docs/input/docs/learn/how-it-works.md
index 03391ae1e4..a556661b26 100644
--- a/docs/input/docs/learn/how-it-works.md
+++ b/docs/input/docs/learn/how-it-works.md
@@ -17,11 +17,11 @@ it _much_ more predictable and easier to diagnose when odd things are happening.
 GitVersion has three distinct steps for calculating versions in v3.
 
 1. If the current commit is tagged, the tag is used and build metadata
-    (excluding commit count) is added. The other two steps will not execute.
+   (excluding commit count) is added. The other two steps will not execute.
 2. A set of strategies are evaluated to decide on the base version and some
-    metadata about that version. See [Version Strategies](#version-strategies)
+   metadata about that version. See [Version Strategies](#version-strategies)
 3. The highest base version is selected, using that base version as the new
-    version is calculated.
+   version is calculated.
 
 Visually it looks something like this:
 
@@ -39,19 +39,19 @@ simply to show what happens if the check is true.
 Currently we have the following strategies:
 
 * `Fallback` - Always returns 0.0.0 and will be used for
-    calculating the next version which is dependent on the increment strategy of
-    the effected branch (e.g. on main the next version is 0.0.1 or on develop it is 0.1.0).
-    The fallback strategy only applies if no other selected strategy returns a base version.
+  calculating the next version which is dependent on the increment strategy of
+  the effected branch (e.g. on main the next version is 0.0.1 or on develop it is 0.1.0).
+  The fallback strategy only applies if no other selected strategy returns a base version.
 * `ConfiguredNextVersion` - Returns the version from the GitVersion.yaml file
 * `MergeMessage` - Finds version numbers from merge messages
-    (e.g., `Merge 'release/3.0.0' into 'main'` will return `3.0.0`)
+  (e.g., `Merge 'release/3.0.0' into 'main'` will return `3.0.0`)
 * `TaggedCommit` - Extracts version information from all tags on the branch which are valid,
-    and not newer than the current commit.
+  and not newer than the current commit.
 * `TrackReleaseBranches` - Considers the base version extracted from release branches when
-    calculating the next version for branches configured with `track-release-branches: true`
-    (part of default configuration for `develop` branch in `GitFlow` workflow)
+  calculating the next version for branches configured with `track-release-branches: true`
+  (part of default configuration for `develop` branch in `GitFlow` workflow)
 * `VersionInBranchName` - Extracts version information from the
-    branch name (e.g., `release/3.0.0` will find `3.0.0`)
+  branch name (e.g., `release/3.0.0` will find `3.0.0`)
 * `Mainline` - Increments the version on every commit for branches configured with `is-main-branch: true`
 
 Each strategy needs to return an instance of `BaseVersion` which has the
@@ -59,14 +59,14 @@ following properties:
 
 * `Source` - Description of the source (e.g., `Merge message 'Merge 'release/3.0.0' into 'main'`)
 * `ShouldIncrement` - Some strategies should have the version incremented,
-    others do not (e.g., `ConfiguredNextVersion` returns false,
-    `TaggedCommit` returns true)
+  others do not (e.g., `ConfiguredNextVersion` returns false,
+  `TaggedCommit` returns true)
 * `SemanticVersion` - SemVer of the base version strategy
 * `BaseVersionSource` - SHA hash of the source. Commits will be counted from
-    this hash. Can be null (e.g., `ConfiguredNextVersion` returns
-    null).
+  this hash. Can be null (e.g., `ConfiguredNextVersion` returns
+  null).
 * `BranchNameOverride` - When `useBranchName` or `{BranchName}` is used in the
-    tag configuration, this allows the branch name to be changed by a base version.
-    `VersionInBranchName` uses this to strip out anything before the
-    first `-` or `/.` so `foo` ends up being evaluated as `foo`. If in doubt, just
-    use null.
+  tag configuration, this allows the branch name to be changed by a base version.
+  `VersionInBranchName` uses this to strip out anything before the
+  first `-` or `/.` so `foo` ends up being evaluated as `foo`. If in doubt, just
+  use null.
diff --git a/docs/input/docs/learn/why.md b/docs/input/docs/learn/why.md
index a87ef0cc3a..0b08792e30 100644
--- a/docs/input/docs/learn/why.md
+++ b/docs/input/docs/learn/why.md
@@ -14,9 +14,9 @@ It solves:
 * Rebuilding tags always produces the same version
 * Not having to rebuild to increment versions
 * Not duplicating version information in multiple places (branch release/2.0.0
-    already has the version in it, why do I need to change something else)
+  already has the version in it, why do I need to change something else)
 * Each branch calculates its SemVer and versions flow between branches when
-    they are merged
+  they are merged
 * Pull requests produce unique pre-release version numbers
 * NuGet semver issues
 * Build server integration
diff --git a/docs/input/docs/reference/build-servers/appveyor.md b/docs/input/docs/reference/build-servers/appveyor.md
index 2232c49a15..5cf4199c94 100644
--- a/docs/input/docs/reference/build-servers/appveyor.md
+++ b/docs/input/docs/reference/build-servers/appveyor.md
@@ -12,4 +12,4 @@ AppVeyor is the first build server which has a setup helper built into
 2. Choose `Setup build scripts` (currently option 7, but that could change)
 3. Choose `AppVeyor`
 4. Follow the prompts to generate an AppVeyor.yml file which works nicely with
-    GitVersion
+   GitVersion
diff --git a/docs/input/docs/reference/build-servers/azure-devops.md b/docs/input/docs/reference/build-servers/azure-devops.md
index 3f548d18a4..500b15b7b2 100644
--- a/docs/input/docs/reference/build-servers/azure-devops.md
+++ b/docs/input/docs/reference/build-servers/azure-devops.md
@@ -5,6 +5,7 @@ Description: |
     Details on the Azure DevOps Build Pipeline support in GitVersion
 RedirectFrom: docs/build-server-support/build-server/azure-devops
 ---
+
 ## Installation and usage
 
 For Azure DevOps Services or Azure DevOps Server you can install the [GitTools Bundle](https://marketplace.visualstudio.com/items?itemName=gittools.gittools).
diff --git a/docs/input/docs/reference/build-servers/buildkite.md b/docs/input/docs/reference/build-servers/buildkite.md
index 5bae6a9729..30c04c14cf 100644
--- a/docs/input/docs/reference/build-servers/buildkite.md
+++ b/docs/input/docs/reference/build-servers/buildkite.md
@@ -50,6 +50,9 @@ eval $(gitversion | jq -r 'to_entries[] | "buildkite-agent meta-data set GitVers
 Assuming your Buildkite agent has dotnet and gitversion installed and on the path, all the calculated GitVersion variables will have a corresponding meta-data key set.
 
 [buildkite]: https://buildkite.com/
+
 [configuration]: https://buildkite.com/docs/agent/v3/hooks
+
 [hooks]: https://buildkite.com/docs/agent/v3/hooks
+
 [meta-data]: https://buildkite.com/docs/agent/v3/cli-meta-data
diff --git a/docs/input/docs/reference/build-servers/continua.md b/docs/input/docs/reference/build-servers/continua.md
index eefe6048df..e2af69c06e 100644
--- a/docs/input/docs/reference/build-servers/continua.md
+++ b/docs/input/docs/reference/build-servers/continua.md
@@ -23,9 +23,9 @@ It also requires a few variables which will automatically be filled by
 GitVersion. The example below are just a few, any of the GitVersion variables
 written to the output can be used.
 
-* GitVersion_FullSemVer
-* GitVersion_MajorMinorPatch
-* GitVersion_NuGetVersion
+* GitVersion\_FullSemVer
+* GitVersion\_MajorMinorPatch
+* GitVersion\_NuGetVersion
 
 You also need to add a property collector for the agents to detect the
 GitVersion tool on the agents:
@@ -36,7 +36,7 @@ GitVersion tool on the agents:
 * Property Name => Path
 * Executable => GitVersion.exe
 * Search paths => your installation folder (e.g. `C:\Tools\GitVersion` or if you
-    are using Chocolatey `C:\ProgramData\chocolatey\lib\GitVersion.Portable\tools`)
+  are using Chocolatey `C:\ProgramData\chocolatey\lib\GitVersion.Portable\tools`)
 
 ## Basic Usage
 
diff --git a/docs/input/docs/reference/build-servers/github-actions.md b/docs/input/docs/reference/build-servers/github-actions.md
index d19e4489a5..77ae3a9023 100644
--- a/docs/input/docs/reference/build-servers/github-actions.md
+++ b/docs/input/docs/reference/build-servers/github-actions.md
@@ -4,6 +4,7 @@ Title: GitHub Actions
 Description: |
     Details on the GitHub Actions Workflow support in GitVersion
 ---
+
 ## Installation and usage
 
 For GitHub Actions you can install the action from [GitTools Bundle](https://github.com/marketplace/actions/gittools).
diff --git a/docs/input/docs/reference/build-servers/gitlab.md b/docs/input/docs/reference/build-servers/gitlab.md
index 9a03ac25b8..aa97d9e5fd 100755
--- a/docs/input/docs/reference/build-servers/gitlab.md
+++ b/docs/input/docs/reference/build-servers/gitlab.md
@@ -13,22 +13,29 @@ A working example of integrating GitVersion with GitLab is maintained in the pro
 
 Here is a summary of what it demonstrated (many more details in the [Readme][readme])
 
-- Is a reusable working example known as a Guided Exploration ([Guided Exploration Manifesto][guided-exploration-manifesto]) - so job logs and package artifacts can be reviewed. The project can also be imported to your own GitLab group or instance as a starting point for your own work.
-- IMPORTANT: It demonstrates how to override GitLab CI's default cloning behavior so that GitVersion can do a dynamic copy. Selectively clones GitVersion.yml so that these settings take effect. This best practice demonstrates the best way to do this while avoiding a double-cloning of the project (once by GitLab Runner and once by GitVersion).
-- Implements GitVersion as a CI/CD Extension that can be reused across many projects using includes.
-- Implements GitVersion as a single job that runs the GitVersion container and passes the version number downstream into both _pipeline_ and _job_ level variables, which means...
-- It can be used with ANY coding language, framework or packaging engine.
-- Generates example packaged artifacts:
-  - Two ways of building Sem Versioned NuGet packages (msbuild-ish and nuget.exe-ish) and uploads them and tests them from a [GitLab NuGet Repository][gitlab-nuget-repository].
-  - A Sem Versioned [GitLab Generic Package][gitlab-generic-package]
-  - A Sem Versioned docker container and uploads to [GitLab Container Registry][gitlab-container-registry].
-- It creates a Sem Versioned [GitLab Release][gitlab-release-help] and Git tag using the [GitLab Release Cli][gitlab-release-cli] and links the generic package as evidence.
+* Is a reusable working example known as a Guided Exploration ([Guided Exploration Manifesto][guided-exploration-manifesto]) - so job logs and package artifacts can be reviewed. The project can also be imported to your own GitLab group or instance as a starting point for your own work.
+* IMPORTANT: It demonstrates how to override GitLab CI's default cloning behavior so that GitVersion can do a dynamic copy. Selectively clones GitVersion.yml so that these settings take effect. This best practice demonstrates the best way to do this while avoiding a double-cloning of the project (once by GitLab Runner and once by GitVersion).
+* Implements GitVersion as a CI/CD Extension that can be reused across many projects using includes.
+* Implements GitVersion as a single job that runs the GitVersion container and passes the version number downstream into both _pipeline_ and _job_ level variables, which means...
+* It can be used with ANY coding language, framework or packaging engine.
+* Generates example packaged artifacts:
+  * Two ways of building Sem Versioned NuGet packages (msbuild-ish and nuget.exe-ish) and uploads them and tests them from a [GitLab NuGet Repository][gitlab-nuget-repository].
+  * A Sem Versioned [GitLab Generic Package][gitlab-generic-package]
+  * A Sem Versioned docker container and uploads to [GitLab Container Registry][gitlab-container-registry].
+* It creates a Sem Versioned [GitLab Release][gitlab-release-help] and Git tag using the [GitLab Release Cli][gitlab-release-cli] and links the generic package as evidence.
 
 [gitlab-generic-package]: https://docs.gitlab.com/ee/user/packages/generic_packages/
+
 [gitlab-nuget-repository]: https://docs.gitlab.com/ee/user/packages/nuget_repository/
+
 [gitlab-release-cli]: https://gitlab.com/gitlab-org/release-cli/-/tree/master/docs
+
 [gitlab-container-registry]: https://docs.gitlab.com/ee/user/packages/container_registry/
+
 [guided-exploration-manifesto]: https://gitlab.com/guided-explorations/guided-exploration-concept/-/blob/master/README.md
+
 [readme]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/-/blob/develop/README.md
+
 [utterly-automated-versioning]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/
+
 [gitlab-release-help]: https://docs.gitlab.com/ee/user/project/releases/
diff --git a/docs/input/docs/reference/build-servers/jenkins.md b/docs/input/docs/reference/build-servers/jenkins.md
index 19669ee20f..93eb9cb6ab 100644
--- a/docs/input/docs/reference/build-servers/jenkins.md
+++ b/docs/input/docs/reference/build-servers/jenkins.md
@@ -31,9 +31,9 @@ To inject the GitVersion variables as environment variables for a build job
 using [EnvInject][env-inject], do the following:
 
 1. Add an **Execute Windows batch command** build step with _Command_:
-    `gitversion /output buildserver`
+   `gitversion /output buildserver`
 2. Add an **Inject environment variables** build step and use value
-    'gitversion.properties' for the _Properties File Path_ parameter
+   'gitversion.properties' for the _Properties File Path_ parameter
 
 This assumes GitVersion.exe is available on the command line.
 
@@ -76,4 +76,5 @@ script {
 ```
 
 [env-inject]: https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
+
 [pipeline-utility-steps]: https://plugins.jenkins.io/pipeline-utility-steps
diff --git a/docs/input/docs/reference/build-servers/myget.md b/docs/input/docs/reference/build-servers/myget.md
index c2d34846c2..895862c2a9 100644
--- a/docs/input/docs/reference/build-servers/myget.md
+++ b/docs/input/docs/reference/build-servers/myget.md
@@ -9,16 +9,16 @@ MyGet Build Services has built-in support for GitVersion and is encouraging you
 to leverage GitVersion + GitFlow to produce Semantically Versioned packages.
 
 * Create a [custom build script](https://docs.myget.org/docs/reference/custom-build-scripts):
-    we advise to run a tool like GitVersion in a _pre-build_ script, so that it can
-    set additional environment variables for the actual build script. MyGet
-    [by convention](https://docs.myget.org/docs/reference/build-services#Pre-\_and_post-build_steps)
-    automatically picks up any of the following file names as pre-build script:
+  we advise to run a tool like GitVersion in a _pre-build_ script, so that it can
+  set additional environment variables for the actual build script. MyGet
+  [by convention](https://docs.myget.org/docs/reference/build-services#Pre-_and_post-build_steps)
+  automatically picks up any of the following file names as pre-build script:
   * `pre-build.(bat|cmd|ps1)`
   * `pre-myget.(bat|cmd|ps1)`
 * Run `GitVersion /output buildserver`: this will cause MyGet Build Services to
-    set the current `%PackageVersion%` value to the NuGet-compatible SemVer
-    generated by GitVersion and apply this [MyGet Environment Variable](https://docs.myget.org/docs/reference/build-services#Available_Environment_Variables)
-    wherever it is used during the build process.
+  set the current `%PackageVersion%` value to the NuGet-compatible SemVer
+  generated by GitVersion and apply this [MyGet Environment Variable](https://docs.myget.org/docs/reference/build-services#Available_Environment_Variables)
+  wherever it is used during the build process.
 * Ensure the build script has been pushed to your source repository root. Done :)
 
 :::{.alert .alert-info}
diff --git a/docs/input/docs/reference/build-servers/octopus-deploy.md b/docs/input/docs/reference/build-servers/octopus-deploy.md
index bbc38962b4..e7d50ff3e0 100644
--- a/docs/input/docs/reference/build-servers/octopus-deploy.md
+++ b/docs/input/docs/reference/build-servers/octopus-deploy.md
@@ -53,14 +53,14 @@ manual build in your _build server_ which pushes the package to Octopus deploy.
 Another simple option is to tag a stable version to release, the basic idea is:
 
 1. GitVersion is set to continuous deployment mode, so main will create `-ci.x`
-    pre-release builds
+   pre-release builds
 2. CI Builds only create NuGet packages for stable builds
 3. You tag main with a stable version of the next version then push it
 4. The CI build triggers, GitVersion will always respect tags so you will get a
-    stable version
+   stable version
 5. The stable package will be pushed to Octopus
 6. Because of the tag, then next build will be incremented and will be producing
-    pre-release packages of the next build
+   pre-release packages of the next build
 
 #### Script to create the release
 
@@ -179,4 +179,5 @@ will burn multiple versions per release. This might not be an issue for you, but
 can confuse consumers of your library as the version has semantic meaning.
 
 [continuous-delivery]: /docs/reference/modes/continuous-delivery
+
 [increment-per-commit]: /docs/reference/version-increments#incrementing-per-commit
diff --git a/docs/input/docs/reference/build-servers/teamcity.md b/docs/input/docs/reference/build-servers/teamcity.md
index 371bd3106e..60f84f5129 100644
--- a/docs/input/docs/reference/build-servers/teamcity.md
+++ b/docs/input/docs/reference/build-servers/teamcity.md
@@ -63,22 +63,22 @@ See [dynamic repositories][dynamic-repo] for more info.
 
 * We update the TC build number to the GitVersion number automatically
 * We output the individual values of the GitVersion version variables as build
-    parameters with format `GitVersion.*` (Eg: `GitVersion.Major`) if you need
-    access to them in your build script. Being system variables they will be passed
-    as msbuild/environmental variables to other build steps
+  parameters with format `GitVersion.*` (Eg: `GitVersion.Major`) if you need
+  access to them in your build script. Being system variables they will be passed
+  as msbuild/environmental variables to other build steps
 
 ### NuGet in TeamCity
 
 * Add a dummy [parameter][parameter] to the project called `GitVersion.NuGetVersion`. If
-    many of your projects uses git-flow and SemVer you can add the parameter to
-    the "root-project" (TeamCity 8.x+). You need a dummy param because
-    GitVersion creates the variables at runtime, and you cannot reference a
-    parameter which is not available statically. GitVersion will overwrite the
-    dummy value.
+  many of your projects uses git-flow and SemVer you can add the parameter to
+  the "root-project" (TeamCity 8.x+). You need a dummy param because
+  GitVersion creates the variables at runtime, and you cannot reference a
+  parameter which is not available statically. GitVersion will overwrite the
+  dummy value.
 * Then setup you nuget pack build set the "version" to
-    `%GitVersion.NuGetVersion%`.
+  `%GitVersion.NuGetVersion%`.
 * If you do your pack in a build script then you can just use environmental
-    variables because teamcity will pass them through automatically.
+  variables because teamcity will pass them through automatically.
 
 ### When TeamCity -> GitHub can't use https
 
@@ -104,8 +104,13 @@ Sorry
 * [Continuous Delivery Setup in TeamCity][cd]
 
 [cd]: https://jake.ginnivan.net/blog/2014/07/09/my-typical-teamcity-build-setup
+
 [dynamic-repo]: /docs/learn/dynamic-repositories
+
 [general-settings]: https://www.jetbrains.com/help/teamcity/git.html#General+Settings
+
 [parameter]: https://confluence.jetbrains.com/display/TCD8/Configuring+Build+Parameters
+
 [teamcity]: https://www.jetbrains.com/teamcity/
+
 [meta-runner]: https://github.com/JetBrains/meta-runner-power-pack/tree/master/gitversion
diff --git a/docs/input/docs/reference/configuration.md b/docs/input/docs/reference/configuration.md
index a377ed692e..9f7354f2ce 100644
--- a/docs/input/docs/reference/configuration.md
+++ b/docs/input/docs/reference/configuration.md
@@ -25,9 +25,9 @@ To see the effective configuration (defaults and overrides), you can run
 
 The following supported workflow configurations are available in GitVersion and can be referenced by the workflow property:
 
-- GitFlow (GitFlow/v1)
-- GitHubFlow (GitHubFlow/v1)
-- TrunkBased (TrunkBased/preview1)
+* GitFlow (GitFlow/v1)
+* GitHubFlow (GitHubFlow/v1)
+* TrunkBased (TrunkBased/preview1)
 
 Example of using a `GitHubFlow` workflow with a different `tag-prefix`:
 
@@ -638,9 +638,9 @@ merge-message-formats:
 
 The regular expression should contain the following capture groups:
 
-- `SourceBranch` - Identifies the source branch of the merge
-- `TargetBranch` - Identifies the target branch of the merge
-- `PullRequestNumber` - Captures the pull-request number
+* `SourceBranch` - Identifies the source branch of the merge
+* `TargetBranch` - Identifies the target branch of the merge
+* `PullRequestNumber` - Captures the pull-request number
 
 Custom merge message formats are evaluated _before_ any built in formats.
 Support for [Conventional Commits][conventional-commits] can be
@@ -768,16 +768,16 @@ Take this commit graph
 
 By looking at this graph, you cannot tell which of these scenarios happened:
 
-- feature/foo branches off release/v1.0.0
-  - Branch release/v1.0.0 from main
-  - Branch feature/foo from release/v1.0.0
-  - Add a commit to both release/v1.0.0 and feature/foo
-  - release/v1.0.0 is the base for feature/foo
-- release/v1.0.0 branches off feature/foo
-  - Branch feature/foo from main
-  - Branch release/v1.0.0 from feature/foo
-  - Add a commit to both release/v1.0.0 and feature/foo
-  - feature/foo is the base for release/v1.0.0
+* feature/foo branches off release/v1.0.0
+  * Branch release/v1.0.0 from main
+  * Branch feature/foo from release/v1.0.0
+  * Add a commit to both release/v1.0.0 and feature/foo
+  * release/v1.0.0 is the base for feature/foo
+* release/v1.0.0 branches off feature/foo
+  * Branch feature/foo from main
+  * Branch release/v1.0.0 from feature/foo
+  * Add a commit to both release/v1.0.0 and feature/foo
+  * feature/foo is the base for release/v1.0.0
 
 Or put more simply, you cannot tell which branch was created first,
 `release/v1.0.0` or `feature/foo`.
@@ -941,7 +941,7 @@ Can be `Strict` - using the [regex](https://regex101.com/r/Ly7O1x/3/)
 or `Loose` the old way of parsing. The default if not specified is `Strict`
 Example of invalid `Strict`, but valid `Loose`
 
-``` log
+```log
 1.2-alpha4
 01.02.03-rc03
 1.2.3.4
@@ -953,19 +953,26 @@ Specifies which version strategy implementation (one or more) will be used to de
 These strategies can be combined, and the order in which they are specified does not matter.
 The configuration accepts the following values:
 
-- Fallback
-- ConfiguredNextVersion
-- MergeMessage
-- TaggedCommit
-- TrackReleaseBranches
-- VersionInBranchName
-- Mainline
+* Fallback
+* ConfiguredNextVersion
+* MergeMessage
+* TaggedCommit
+* TrackReleaseBranches
+* VersionInBranchName
+* Mainline
 
 [1145]: https://github.com/GitTools/GitVersion/issues/1145
+
 [1366]: https://github.com/GitTools/GitVersion/issues/1366
+
 [2506]: https://github.com/GitTools/GitVersion/pull/2506#issuecomment-754754037
+
 [conventional-commits-config]: /docs/reference/version-increments#conventional-commit-messages
+
 [conventional-commits]: https://www.conventionalcommits.org/
+
 [modes]: /docs/reference/modes
+
 [variables]: /docs/reference/variables
+
 [version-sources]: /docs/reference/version-sources
diff --git a/docs/input/docs/reference/mdsource/configuration.source.md b/docs/input/docs/reference/mdsource/configuration.source.md
index d913b67c6b..be3500ee72 100644
--- a/docs/input/docs/reference/mdsource/configuration.source.md
+++ b/docs/input/docs/reference/mdsource/configuration.source.md
@@ -25,9 +25,9 @@ To see the effective configuration (defaults and overrides), you can run
 
 The following supported workflow configurations are available in GitVersion and can be referenced by the workflow property:
 
-- GitFlow (GitFlow/v1)
-- GitHubFlow (GitHubFlow/v1)
-- TrunkBased (TrunkBased/preview1)
+* GitFlow (GitFlow/v1)
+* GitHubFlow (GitHubFlow/v1)
+* TrunkBased (TrunkBased/preview1)
 
 Example of using a `GitHubFlow` workflow with a different `tag-prefix`:
 
@@ -239,9 +239,9 @@ merge-message-formats:
 
 The regular expression should contain the following capture groups:
 
-- `SourceBranch` - Identifies the source branch of the merge
-- `TargetBranch` - Identifies the target branch of the merge
-- `PullRequestNumber` - Captures the pull-request number
+* `SourceBranch` - Identifies the source branch of the merge
+* `TargetBranch` - Identifies the target branch of the merge
+* `PullRequestNumber` - Captures the pull-request number
 
 Custom merge message formats are evaluated _before_ any built in formats.
 Support for [Conventional Commits][conventional-commits] can be
@@ -369,16 +369,16 @@ Take this commit graph
 
 By looking at this graph, you cannot tell which of these scenarios happened:
 
-- feature/foo branches off release/v1.0.0
-  - Branch release/v1.0.0 from main
-  - Branch feature/foo from release/v1.0.0
-  - Add a commit to both release/v1.0.0 and feature/foo
-  - release/v1.0.0 is the base for feature/foo
-- release/v1.0.0 branches off feature/foo
-  - Branch feature/foo from main
-  - Branch release/v1.0.0 from feature/foo
-  - Add a commit to both release/v1.0.0 and feature/foo
-  - feature/foo is the base for release/v1.0.0
+* feature/foo branches off release/v1.0.0
+  * Branch release/v1.0.0 from main
+  * Branch feature/foo from release/v1.0.0
+  * Add a commit to both release/v1.0.0 and feature/foo
+  * release/v1.0.0 is the base for feature/foo
+* release/v1.0.0 branches off feature/foo
+  * Branch feature/foo from main
+  * Branch release/v1.0.0 from feature/foo
+  * Add a commit to both release/v1.0.0 and feature/foo
+  * feature/foo is the base for release/v1.0.0
 
 Or put more simply, you cannot tell which branch was created first,
 `release/v1.0.0` or `feature/foo`.
@@ -542,7 +542,7 @@ Can be `Strict` - using the [regex](https://regex101.com/r/Ly7O1x/3/)
 or `Loose` the old way of parsing. The default if not specified is `Strict`
 Example of invalid `Strict`, but valid `Loose`
 
-``` log
+```log
 1.2-alpha4
 01.02.03-rc03
 1.2.3.4
@@ -554,19 +554,26 @@ Specifies which version strategy implementation (one or more) will be used to de
 These strategies can be combined, and the order in which they are specified does not matter.
 The configuration accepts the following values:
 
-- Fallback
-- ConfiguredNextVersion
-- MergeMessage
-- TaggedCommit
-- TrackReleaseBranches
-- VersionInBranchName
-- Mainline
+* Fallback
+* ConfiguredNextVersion
+* MergeMessage
+* TaggedCommit
+* TrackReleaseBranches
+* VersionInBranchName
+* Mainline
 
 [1145]: https://github.com/GitTools/GitVersion/issues/1145
+
 [1366]: https://github.com/GitTools/GitVersion/issues/1366
+
 [2506]: https://github.com/GitTools/GitVersion/pull/2506#issuecomment-754754037
+
 [conventional-commits-config]: /docs/reference/version-increments#conventional-commit-messages
+
 [conventional-commits]: https://www.conventionalcommits.org/
+
 [modes]: /docs/reference/modes
+
 [variables]: /docs/reference/variables
+
 [version-sources]: /docs/reference/version-sources
diff --git a/docs/input/docs/reference/modes/continuous-delivery.md b/docs/input/docs/reference/modes/continuous-delivery.md
index d1d2a1e712..3b6aa456ae 100644
--- a/docs/input/docs/reference/modes/continuous-delivery.md
+++ b/docs/input/docs/reference/modes/continuous-delivery.md
@@ -36,5 +36,7 @@ is done as it's an automated process.
 * [Continuous delivery][wikipedia]
 
 [configuration]: /docs/reference/configuration
+
 [blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
+
 [wikipedia]: https://en.wikipedia.org/wiki/Continuous_delivery
diff --git a/docs/input/docs/reference/modes/continuous-deployment.md b/docs/input/docs/reference/modes/continuous-deployment.md
index 852936e67f..d393f299ec 100644
--- a/docs/input/docs/reference/modes/continuous-deployment.md
+++ b/docs/input/docs/reference/modes/continuous-deployment.md
@@ -31,4 +31,5 @@ Tags are required in this mode to communicate when the deployement happens on pr
 * [Semantic Versioning & auto-incremented NuGet package versions][blog]
 
 [configuration]: /docs/reference/configuration
+
 [blog]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
diff --git a/docs/input/docs/reference/modes/manual-deployment.md b/docs/input/docs/reference/modes/manual-deployment.md
index 9ea3383d94..e76e3e08d0 100644
--- a/docs/input/docs/reference/modes/manual-deployment.md
+++ b/docs/input/docs/reference/modes/manual-deployment.md
@@ -8,14 +8,14 @@ RedirectFrom: docs/reference/versioning-modes/manual-deployment
 ---
 
 Having not the necessity to deploy the build artifacts on every commit is an
-indecation of using the __Manual Deployment__ mode. This mode can be used to
+indecation of using the **Manual Deployment** mode. This mode can be used to
 remain on the same pre-released version until it has been deployed dedicatedly.
 
 ## How Manual Deployment affects GitVersion
 
 The thing about manual deployment is that there will be _multiple_ candidates
 to deploy on testing and it is a human choice to deploy. This means that
-GitVersion will build __the same semantic version__ until that version is
+GitVersion will build **the same semantic version** until that version is
 deployed. For instance:
 
 * 1.1.0-2+1
@@ -33,5 +33,7 @@ an external manual process.
 * [Continuous Delivery, the book][book]
 
 [configuration]: /docs/reference/configuration
+
 [book]: https://www.amazon.com/Continuous-Delivery-Deployment-Automation-Addison-Wesley/dp/0321601912
+
 [wikipedia]: https://en.wikipedia.org/wiki/Continuous_delivery
diff --git a/docs/input/docs/reference/requirements.md b/docs/input/docs/reference/requirements.md
index fd205ea8aa..3d950f4e6f 100644
--- a/docs/input/docs/reference/requirements.md
+++ b/docs/input/docs/reference/requirements.md
@@ -43,6 +43,9 @@ the case on build servers, the `Git_Branch` environment variable needs to be
 defined and set to the reference being built.
 
 [git-unshallow]: https://git-scm.com/docs/git-fetch#Documentation/git-fetch.txt---unshallow
+
 [gitflow]: /docs/learn/branching-strategies/gitflow
+
 [build-servers]: /docs/reference/build-servers
+
 [configuration]: /docs/reference/configuration
diff --git a/docs/input/docs/reference/version-increments.md b/docs/input/docs/reference/version-increments.md
index 27cf1d6b33..7dd4f83f82 100644
--- a/docs/input/docs/reference/version-increments.md
+++ b/docs/input/docs/reference/version-increments.md
@@ -109,9 +109,9 @@ If your CI/CD workflow uses semantic-release's commit-analyzer, change
 
 Alternatively, you can override this rule in the
 [configuration](https://github.com/semantic-release/commit-analyzer/tree/master#usage)
-of \@semantic-release/commit-analyzer. If you intend to write rules with
+of @semantic-release/commit-analyzer. If you intend to write rules with
 patterns, note that instead of using Regular Expression,
-\@semantic-release/commit-analyzer uses
+@semantic-release/commit-analyzer uses
 [micromatch's glob implementation](https://github.com/micromatch/micromatch#matching-features).
 
 ### GitVersion.yml
@@ -172,7 +172,11 @@ For more information/background on why we have come to this conclusion, read
 [Xavier Decoster's blog post on the subject][auto-incremented-nuget-package].
 
 [auto-incremented-nuget-package]: https://www.xavierdecoster.com/semantic-versioning-auto-incremented-nuget-package-versions
+
 [continuous-delivery]: /docs/reference/modes/continuous-delivery
+
 [conventional-commits]: https://www.conventionalcommits.org/
+
 [faq-branch-name-source]: /docs/learn/faq#merged-branch-names-as-version-source
+
 [git-tagging]: https://git-scm.com/book/en/v2/Git-Basics-Tagging
diff --git a/docs/input/docs/reference/version-sources.md b/docs/input/docs/reference/version-sources.md
index c12adfd217..dcdae9f82d 100644
--- a/docs/input/docs/reference/version-sources.md
+++ b/docs/input/docs/reference/version-sources.md
@@ -17,7 +17,7 @@ The logic of GitVersion is something like this:
 * Calculate the base version (highest version from all the sources)
 * Increment version if needed based on branch config
 * Calculate the build metadata (everything after the +) and append to the
-    calculated version
+  calculated version
 
 ## Version Sources
 
@@ -51,7 +51,7 @@ Will increment: false
 For the develop branch, i.e. marked with `is-develop: true`
 
 * Returns the version number extracted from any child release-branches, i.e.
-    those marked with `is-release-branch: true`
+  those marked with `is-release-branch: true`
 * Returns the version number of any tags on the main branch
 
 Will increment: true
diff --git a/docs/input/docs/usage/ci.md b/docs/input/docs/usage/ci.md
index 95b4106329..6affabd81b 100644
--- a/docs/input/docs/usage/ci.md
+++ b/docs/input/docs/usage/ci.md
@@ -32,5 +32,7 @@ GitVersion into an Azure DevOps build pipeline.
 The GitLab CI example [gitlab-sample][] implements GitVersion support at the pipeline level by using a single job that runs the GitVersion container and passes the version number downstream into both _pipeline_ and _job_ level variables. It is also implemented as a reusable CI/CD Extension that can be included in many different projects.
 
 [gittools-actions]: https://github.com/marketplace/actions/gittools
+
 [gittools-task]: https://marketplace.visualstudio.com/items?itemName=gittools.gittools
+
 [gitlab-sample]: https://gitlab.com/guided-explorations/devops-patterns/utterly-automated-versioning/
diff --git a/docs/input/docs/usage/cli/assembly-patch.md b/docs/input/docs/usage/cli/assembly-patch.md
index ef1a7b2f07..94509e65c8 100644
--- a/docs/input/docs/usage/cli/assembly-patch.md
+++ b/docs/input/docs/usage/cli/assembly-patch.md
@@ -12,9 +12,9 @@ It will update the following assembly attributes:
 
 * `AssemblyVersion` will be set to the `AssemblySemVer` variable.
 * `AssemblyFileVersion` will be set to the `MajorMinorPatch` variable with an
-    appended `.0`.
+  appended `.0`.
 * `AssemblyInformationalVersion` will be set to the `InformationalVersion`
-    variable.
+  variable.
 
 Note that contrary to when using the [MSBuild Task][msbuild-task] the
 attributes must already exist in the `AssemblyInfo.cs` or `AssemblyInfo.vb`
@@ -31,9 +31,9 @@ will be generated based on a known template that adds:
 
 * `AssemblyVersion` will be set to the `AssemblySemVer` variable.
 * `AssemblyFileVersion` will be set to the `MajorMinorPatch` variable with an
-    appended `.0`.
+  appended `.0`.
 * `AssemblyInformationalVersion` will be set to the `InformationalVersion`
-    variable.
+  variable.
 
 This can be done for \*.cs, \*.vb and \*.fs files.
 
@@ -81,4 +81,5 @@ To support integration with WiX projects, use `GitVersion.exe
 referenced in the WiX project files.
 
 [msbuild-task]: /docs/usage/msbuild
+
 [variables]: /docs/reference/variables
diff --git a/docs/input/docs/usage/cli/installation.md b/docs/input/docs/usage/cli/installation.md
index 3699db9447..c6cd3e4e0d 100644
--- a/docs/input/docs/usage/cli/installation.md
+++ b/docs/input/docs/usage/cli/installation.md
@@ -83,8 +83,13 @@ This should work on all operating systems supported by Docker (at the time
 of writing: Linux, macOS, Windows).
 
 [dotnet-tool]: https://docs.microsoft.com/en-us/dotnet/core/tools/global-tools#install-a-global-tool
+
 [tool]: https://www.nuget.org/packages/GitVersion.Tool/
+
 [brew]: https://formulae.brew.sh/formula/gitversion
+
 [homebrew]: https://brew.sh/
+
 [docker]: https://hub.docker.com/r/gittools/gitversion
+
 [choco]: https://chocolatey.org/packages/GitVersion.Portable
diff --git a/docs/input/docs/usage/msbuild.md b/docs/input/docs/usage/msbuild.md
index badf8b99a6..1c9c588be8 100644
--- a/docs/input/docs/usage/msbuild.md
+++ b/docs/input/docs/usage/msbuild.md
@@ -92,7 +92,7 @@ Now, when you build:
 
 * `AssemblyVersion` will be set to the `AssemblySemVer` variable.
 * `AssemblyFileVersion` will be set to the `MajorMinorPatch` variable with `.0`
-    appended to it.
+  appended to it.
 * `AssemblyInformationalVersion` will be set to the `InformationalVersion` variable.
 
 #### Other injected Variables
diff --git a/docs/readme.md b/docs/readme.md
index a4ab0556a0..8898e0691b 100644
--- a/docs/readme.md
+++ b/docs/readme.md
@@ -53,6 +53,9 @@ a local web server. Information about the URL that can be used to view the docs
 will be shown in the output. Copy/paste this URL into a browser window.
 
 [gitversion.net]: https://gitversion.net/
+
 [forking]: https://guides.github.com/activities/forking/
+
 [ps-mac]: https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-macos?view=powershell-7.1
+
 [ps-linux]: https://docs.microsoft.com/en-us/powershell/scripting/install/installing-powershell-core-on-linux?view=powershell-7.1
diff --git a/package-lock.json b/package-lock.json
index 5ee552e795..5275b79602 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -33,7 +33,6 @@
         "remark-lint-list-item-content-indent": "^4.0.0",
         "remark-lint-list-item-indent": "^4.0.0",
         "remark-lint-maximum-heading-length": "^4.0.0",
-        "remark-lint-no-auto-link-without-protocol": "^4.0.0",
         "remark-lint-no-blockquote-without-marker": "^6.0.0",
         "remark-lint-no-consecutive-blank-lines": "^5.0.0",
         "remark-lint-no-dead-urls": "^2.0.0",
@@ -50,7 +49,6 @@
         "remark-lint-no-heading-content-indent": "^5.0.0",
         "remark-lint-no-heading-indent": "^5.0.0",
         "remark-lint-no-heading-like-paragraph": "^4.0.0",
-        "remark-lint-no-inline-padding": "^5.0.0",
         "remark-lint-no-literal-urls": "^4.0.0",
         "remark-lint-no-multiple-toplevel-headings": "^4.0.0",
         "remark-lint-no-reference-like-url": "^4.0.0",
@@ -9086,13 +9084,6 @@
         "url": "https://opencollective.com/unified"
       }
     },
-    "node_modules/remark-lint-no-auto-link-without-protocol": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/remark-lint-no-auto-link-without-protocol/-/remark-lint-no-auto-link-without-protocol-4.0.0.tgz",
-      "integrity": "sha512-m9P2KgLxblySJ/0bI3MSsDYv3Bem7Ynz5P0OVAJlGvHra/YQyszyd6U/oUavTbel+8sPPymHtNAUTkiDLobn4A==",
-      "deprecated": "Deprecated",
-      "dev": true
-    },
     "node_modules/remark-lint-no-blockquote-without-marker": {
       "version": "6.0.0",
       "resolved": "https://registry.npmjs.org/remark-lint-no-blockquote-without-marker/-/remark-lint-no-blockquote-without-marker-6.0.0.tgz",
@@ -11295,13 +11286,6 @@
         "url": "https://opencollective.com/unified"
       }
     },
-    "node_modules/remark-lint-no-inline-padding": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/remark-lint-no-inline-padding/-/remark-lint-no-inline-padding-5.0.0.tgz",
-      "integrity": "sha512-d88MYpPv4SAWUBmB6QS6gU4vgg5y66IesjijwQT0yg4HwENcO5IbMLs3WDqo6w53DOQPqw+MmDRszP9XaEePIw==",
-      "deprecated": "Deprecated",
-      "dev": true
-    },
     "node_modules/remark-lint-no-literal-urls": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/remark-lint-no-literal-urls/-/remark-lint-no-literal-urls-4.0.0.tgz",
@@ -23462,12 +23446,6 @@
         }
       }
     },
-    "remark-lint-no-auto-link-without-protocol": {
-      "version": "4.0.0",
-      "resolved": "https://registry.npmjs.org/remark-lint-no-auto-link-without-protocol/-/remark-lint-no-auto-link-without-protocol-4.0.0.tgz",
-      "integrity": "sha512-m9P2KgLxblySJ/0bI3MSsDYv3Bem7Ynz5P0OVAJlGvHra/YQyszyd6U/oUavTbel+8sPPymHtNAUTkiDLobn4A==",
-      "dev": true
-    },
     "remark-lint-no-blockquote-without-marker": {
       "version": "6.0.0",
       "resolved": "https://registry.npmjs.org/remark-lint-no-blockquote-without-marker/-/remark-lint-no-blockquote-without-marker-6.0.0.tgz",
@@ -25192,12 +25170,6 @@
         }
       }
     },
-    "remark-lint-no-inline-padding": {
-      "version": "5.0.0",
-      "resolved": "https://registry.npmjs.org/remark-lint-no-inline-padding/-/remark-lint-no-inline-padding-5.0.0.tgz",
-      "integrity": "sha512-d88MYpPv4SAWUBmB6QS6gU4vgg5y66IesjijwQT0yg4HwENcO5IbMLs3WDqo6w53DOQPqw+MmDRszP9XaEePIw==",
-      "dev": true
-    },
     "remark-lint-no-literal-urls": {
       "version": "4.0.0",
       "resolved": "https://registry.npmjs.org/remark-lint-no-literal-urls/-/remark-lint-no-literal-urls-4.0.0.tgz",
diff --git a/package.json b/package.json
index 006ce70883..21159eacab 100644
--- a/package.json
+++ b/package.json
@@ -54,7 +54,6 @@
     "remark-lint-list-item-content-indent": "^4.0.0",
     "remark-lint-list-item-indent": "^4.0.0",
     "remark-lint-maximum-heading-length": "^4.0.0",
-    "remark-lint-no-auto-link-without-protocol": "^4.0.0",
     "remark-lint-no-blockquote-without-marker": "^6.0.0",
     "remark-lint-no-consecutive-blank-lines": "^5.0.0",
     "remark-lint-no-dead-urls": "^2.0.0",
@@ -71,7 +70,6 @@
     "remark-lint-no-heading-content-indent": "^5.0.0",
     "remark-lint-no-heading-indent": "^5.0.0",
     "remark-lint-no-heading-like-paragraph": "^4.0.0",
-    "remark-lint-no-inline-padding": "^5.0.0",
     "remark-lint-no-literal-urls": "^4.0.0",
     "remark-lint-no-multiple-toplevel-headings": "^4.0.0",
     "remark-lint-no-reference-like-url": "^4.0.0",