Fix docs links

docs/pages/blog/v8.mdx

@@ -67,7 +67,7 @@ The `shipit` command will now also publish a prerelease when ran from a prerelea
 3. Multiple `next` Branches (ex: `alpha`, `beta`, `rc`)
 4. Feature Pre-releases
 
-Read more [here](../pages/generated/shipit.md#prereleases).
+Read more [here](../docs/generated/shipit#prereleases).
 
 ## Label Configuration
 

docs/pages/docs/configuration/non-npm.mdx

@@ -40,7 +40,7 @@ To configure `auto` to work with your project you will need to do two things
 
 ### Making an `.autorc`
 
-Using `auto` with any other package manager than [npm](https://npmjs.com) requires that you create an [`.autorc`](./autorc.md) at the root of your project.
+Using `auto` with any other package manager than [npm](https://npmjs.com) requires that you create an [`.autorc`](./autorc) at the root of your project.
 
 1. `.autorc` - No plugins, `shipit` doesn't work. Enables [advanced setup](https://intuit.github.io/auto/pages/getting-started.html#detailed-setup)
 
@@ -78,7 +78,7 @@ Now that you have `auto` all set up you can use all of it's commands!
 ~/auto shipit
 ```
 
-> ℹ️ Tip: Using `auto` locally with an `.env` file is a great experience. See how [here](./getting-started.md#local-.env).
+> ℹ️ Tip: Using `auto` locally with an `.env` file is a great experience. See how [here](../welcome/getting-started#local-env).
 
 ## Plugins
 

docs/pages/docs/configuration/plugins.mdx

@@ -2,11 +2,11 @@
 title: Plugins
 ---
 
-`auto` uses the package [tapable](https://github.com/webpack/tapable) to expose a plugin system. Go [here](./writing-plugins.md) to learn how to write one!
+`auto` uses the package [tapable](https://github.com/webpack/tapable) to expose a plugin system. Go [here](../plugins/writing-plugins) to learn how to write one!
 
 ## Using Plugins
 
-To use a plugin you can either supply the plugin via a CLI arg or in your [.autorc](./autorc.md#plugins).
+To use a plugin you can either supply the plugin via a CLI arg or in your [.autorc](./autorc#plugins).
 
 > :warning: Specifying a plugin overrides the defaults.
 

docs/pages/docs/extras/changelog.md

@@ -2,7 +2,7 @@
 
 ## Changelog Titles
 
-You can customize the changelog titles and even add custom ones. To see configuration [go here](../autorc.md#changelog-titles).
+You can customize the changelog titles and even add custom ones. To see configuration [go here](../configuration/autorc#changelog-titles).
 
 ## Additional Release notes
 

docs/pages/docs/extras/release.md

@@ -24,4 +24,4 @@ You will need to push the tags to github first:
 ## Github Release Details
 
 The details / description published with the Github release will be identical to those generated by the `auto changelog` command.
-See information regarding the release note format [here](./changelog.md#changelog-titles).
+See information regarding the release note format [here](./changelog#changelog-titles).

docs/pages/docs/extras/shipit.md

@@ -12,7 +12,7 @@ The following shows how those flags can effect the workflow.
 ## Managing Old Major Versions
 
 This command also has the ability to help you manage old major versions too!
-This feature is off by default, to enable set `versionBranches` to `true` in your [.autorc](../autorc.md#versionbranches).
+This feature is off by default, to enable set `versionBranches` to `true` in your [.autorc](../configuration/autorc#versionbranches).
 
 With this feature enabled `auto shipit` will:
 
@@ -36,7 +36,7 @@ You can customize what the branch names will be by setting `versionBranches` to
 
 If you are interested in pre-releases (ex: `alpha`, `beta`, `next`) `auto` has the ability to publish pre-releases in various ways.
 
-Read more about preparing you project for pre-releases [here](../generated/next.md#setting-up-protected-branches).
+Read more about preparing you project for pre-releases [here](./next#setting-up-protected-branches).
 
 ### Strategies
 
@@ -45,7 +45,7 @@ Read more about preparing you project for pre-releases [here](../generated/next.
 The suggested way to create pre-releases is by managing 2 branches for your repo: `master` and `next`.
 `master` contains the `latest` stable version of the code, and `next` contains future updates.
 
-You can change what branches `auto` treats as pre-release branches in your [`.autorc`](../autorc.md#prerelease-branches).
+You can change what branches `auto` treats as pre-release branches in your [`.autorc`](../configuration/autorc#prerelease-branches).
 
 ![Example git tree](/next-branch.png)
 

docs/pages/docs/extras/version.md

@@ -2,4 +2,4 @@ Useful in conjunction with `npm version` to auto-version releases.
 
 ## Configure Versioning Labels
 
-You can customize the versioning labels in the `.autorc`. To see configuration [go here](./autorc.md#versioning-labels).
+You can customize the versioning labels in the `.autorc`. To see configuration [go here](../configuration/autorc#labels).

docs/pages/docs/index.mdx

@@ -1,3 +1,5 @@
+import { GetStarted } from "../../plugins/get-started-button";
+
 <div className="w-full">
   <picture>
     <source
@@ -26,8 +28,8 @@ With the set of tools we provide you can automate every part of contribution!
 **Release Features:**
 
 - Calculate semantic version bumps from PRs
-- Publish [canaries](./generated/canary.md) (test versions) directly from PRs or locally
-- Generate changelogs with fancy headers, authors, and [detailed release notes](./generated/changelog.md#additional-release-notes)
+- Publish [canaries](./docs/generated/canary) (test versions) directly from PRs or locally
+- Generate changelogs with fancy headers, authors, and [detailed release notes](./docs/generated/changelog#additional-release-notes)
 - Make GitHub releases
 
 **Pull Request Interaction Features:**
@@ -53,3 +55,7 @@ pre: (optional) Check if new version
 `auto` makes no assumptions about your publishing process.
 Each tool is a function that can be run in isolation and only does one thing really well.
 For instance, you could just use `auto changelog` to generate the changelog and nothing else or use `auto version` to calculate just the `semver` bump.
+
+<div className="my-20 flex align-center justify-center w-full">
+  <GetStarted />
+</div>

docs/pages/docs/plugins/changelog-hooks.mdx

@@ -3,7 +3,7 @@ title: Changelog Hooks
 ---
 
 One of the main outputs from `auto` is the changelogs it produces.
-The changelog is created from a set of commits that has been parsed using the [log parser](./log-parse.md).
+The changelog is created from a set of commits that has been parsed using the [log parser](./log-parse-hooks).
 The hooks it provides allow you to customize everything about how the changelog renders.
 
 - [onCreateChangelog](#oncreatechangelog)

docs/pages/docs/plugins/configuration-hooks.mdx

@@ -101,7 +101,7 @@ auto.hooks.getRepository.tapPromise('NPM', async () => {
 ## validateConfig
 
 Validate how your plugin is configured.
-Make sure to account for the [different ways you plugin can be included](./plugins.md#plugin-declaration) in an `.autorc`.
+Make sure to account for the [different ways you plugin can be included](../configuration/plugins#plugin-declaration) in an `.autorc`.
 
 ```ts
 auto.hooks.validateConfig.tapPromise("test", (name, options) => {

docs/pages/docs/plugins/hook-api-docs.mdx

@@ -6,11 +6,11 @@ Plugins work by "hooking" into various parts of `auto` to control or add to its
 
 The categories of hooks available to plugins are:
 
-- [Init](./init-hooks.md) - Add functionality to `auto init`
-- [Configuration](./configuration-hooks.md) - Detect, modify and validate `auto`'s configuration
-- [Log Parser](./log-parse-hooks.md) - Extend how `auto` analyzes commits
-- [Changelog](./changelog-hooks.md) - Change how `auto` renders changelogs
-- [Release Lifecycle](./release-lifecycle-hooks.md) - Called during various release commands, these facilitate publishing the package
+- [Init](./init-hooks) - Add functionality to `auto init`
+- [Configuration](./configuration-hooks) - Detect, modify and validate `auto`'s configuration
+- [Log Parser](./log-parse-hooks) - Extend how `auto` analyzes commits
+- [Changelog](./changelog-hooks) - Change how `auto` renders changelogs
+- [Release Lifecycle](./release-lifecycle-hooks) - Called during various release commands, these facilitate publishing the package
 
 The hooks that are called depends on the command is run.
 Some hooks are specific to a single command, such as the "Init" hooks, and others are called for every command.

docs/pages/docs/plugins/writing-plugins.mdx

@@ -6,7 +6,7 @@ If you've ever written a `webpack` plugin it's a lot like that.
 
 A plugin definition is:
 
-- a name for the plugin, should match the [name of the package](../plugins.md#plugin-declaration) (REQUIRED)
+- a name for the plugin, should match the [name of the package](../configuration/plugins#plugin-declaration) (REQUIRED)
 - a class the has an `apply` function where a plugin hooks into various functions in auto (REQUIRED)
 
 ```ts
@@ -40,7 +40,7 @@ module.exports = class TestPlugin {
 
 Plugins work by hooking into various actions that `auto` has to do in order to facilitate a release or interact with your GitHub repo.
 
-[Read more about using hooks](./hook-api-docs.md)
+[Read more about using hooks](./hook-api-docs)
 
 ## Adding Options
 
@@ -178,4 +178,4 @@ export default class NPMPlugin {
 }
 ```
 
-[Read more about creating publishing plugins.](./writing-publishing-plugins.md)
+[Read more about creating publishing plugins.](./writing-publishing-plugins)

docs/pages/docs/plugins/writing-publishing-plugins.mdx

@@ -134,7 +134,7 @@ Your package management platform needs to support a few things for canaries to b
 1. Separate Releases Lines - you should be able to publish to a release line that doesn't effect your main users (ex: when installing for the first time they should never get a `canary`)
 2. Lots of releases - it must support a lot of releases, especially if you make a bunch of PRs
 
-[Read more about the `canary` hook.](./release-lifecycle-hooks.md#canary)
+[Read more about the `canary` hook.](./release-lifecycle-hooks#canary)
 
 ### `next`
 
@@ -144,7 +144,7 @@ Think of it like an `alpha` or `beta` release line.
 
 Like the `canary` hook your package management platform must support separate release lines.
 
-[Read more about the `next` hook.](./release-lifecycle-hooks.md#next)
+[Read more about the `next` hook.](./release-lifecycle-hooks#next)
 
 ## Other Useful Hooks
 

docs/pages/docs/welcome/getting-started.mdx

@@ -88,8 +88,8 @@ https_proxy=<PROXYHOST>:<PROXYPORT>
 
 After that, you need to set up the labels on your github project. The types of labels that `auto` uses are:
 
-- Versioning Labels - used to calculate version numbers and make releases. To change them refer to [this](./autorc.md#versioning-labels).
-- Changelog Labels - These labels do not effect the version calculation but they will change the section the PR displays in the changelog. These are customizable too, and you can even add your own sections. Read more [here](./autorc.md#changelog-titles)
+- Versioning Labels - used to calculate version numbers and make releases. To change them refer to [this](../configuration/autorc#labels).
+- Changelog Labels - These labels do not effect the version calculation but they will change the section the PR displays in the changelog. These are customizable too, and you can even add your own sections. Read more [here](../configuration/autorc#changelog-titles)
 
 To create the labels for your project on GitHub, run the following command with your `GH_TOKEN`.
 
@@ -108,7 +108,7 @@ auto create-labels
 To version, changelog, publish and release your code all at the same time, we've included the `shipit` tool.
 This tool runs all commands in the default `auto` workflow and puts it into one meta-command.
 It is context aware and will make different type of releases based on where you run it.
-[Read more here.](./generated/shipit.md)
+[Read more here.](../generated/shipit)
 
 ```json
 {
@@ -182,4 +182,4 @@ fi
 
 ## Enterprise
 
-If you are using enterprise github `auto` lets you configure the github API URL that it uses. You can configure this by using the CLI option `--github-api`, by setting the value in your [.autorc](./autorc.md#githubApi), or during `auto init`.
+If you are using enterprise github `auto` lets you configure the github API URL that it uses. You can configure this by using the CLI option `--github-api`, by setting the value in your [.autorc](../configuration/autorc#githubapi), or during `auto init`.

docs/plugins/get-started-button.js

@@ -0,0 +1,11 @@
+import React from "react";
+
+/** A button that routes the user to the getting started page */
+export const GetStarted = () => (
+  <a
+    href="https://intuit.github.io/auto/docs/welcome/getting-started"
+    className="uppercase text-xl lg:text-2xl border-2 border-white rounded px-6 py-3 hover:bg-primary-500 hover:text-white"
+  >
+    <span className="pr-2">Get Started</span> 🎉
+  </a>
+);

docs/plugins/home.js

@@ -8,6 +8,7 @@ import {
   faAtom,
   faBacon,
 } from "@fortawesome/free-solid-svg-icons";
+import { GetStarted } from "./get-started-button";
 
 const Feature = ({ title, description, icon }) => (
   <div className="mb-8 flex items-start last:mb-0">
@@ -303,12 +304,7 @@ const Home = () => (
             Stop worrying about your release and hit that merge button!
           </h2>
 
-          <a
-            href="https://intuit.github.io/auto/docs"
-            className="uppercase text-xl lg:text-2xl border-2 border-white rounded px-6 py-3"
-          >
-            <span className="pr-2">Get Started</span> 🎉
-          </a>
+          <GetStarted />
         </div>
       </div>
     </main>

plugins/exec/README.md

@@ -20,7 +20,7 @@ Here is an example of replacing the `npm` plugins with a light-weight version.
 
 All args to a hook are exposed on the process in environment variables.
 The format looks like `$ARG_0`, `$ARG_1`, and so on.
-Please look at the docs for [writing plugins](../../docs/pages/writing-plugins.md) for more detail on what's available.
+Please look at the docs for [writing plugins](https://intuit.github.io/auto/docs/plugins/writing-plugins) for more detail on what's available.
 
 ```json
 {