Fix links (#322)

Author: olguzzar

_posts/2023-08-22-prebuild.md

@@ -33,7 +33,7 @@ If you're already using dev containers, you're likely already familiar with the
 
 You need to build your container once it has all the dependencies it needs, and rebuild anytime you add new dependencies. Since you may not need to rebuild often, it might be alright if it takes a while for that initial build. But if you or your teammates need to use that container on another machine, you'll need to wait for it to build again in those new environments.
 
-> **Note:** The [dev container CLI doc](/_implementors/reference.md#prebuilding) is another great resource on prebuilding.
+> **Note:** The [dev container CLI doc](/implementors/reference#prebuilding) is another great resource on prebuilding.
 
 ### <a href="#prebuilt-codespaces" name="prebuilt-codespaces" class="anchor"> Prebuilt Codespaces </a>
 
@@ -43,14 +43,14 @@ GitHub Codespaces prebuilds help to speed up the creation of new codespaces for
 
 By default, whenever you push changes to your repository, GitHub Codespaces uses GitHub Actions to automatically update your prebuilds.
 
-You can learn more about codespaces prebuilds and how to manage them in the [codespaces docs]((https://docs.github.com/en/codespaces/prebuilding-your-codespaces/about-github-codespaces-prebuilds)).
+You can learn more about codespaces prebuilds and how to manage them in the [codespaces docs](https://docs.github.com/en/codespaces/prebuilding-your-codespaces/about-github-codespaces-prebuilds).
 
 ## <a href="#how-to" name="how-to" class="anchor"> How do I prebuild my image? </a>
 
 We try to make prebuilding an image and using a prebuilt image as easy as possible. Let's walk through the couple of steps to get started.
 
 **Prebuilding an image:**
-* Install the [Dev Container CLI](/_implementors/reference.md):
+* Install the [Dev Container CLI](/implementors/reference):
 
      ```bash
      npm install -g @devcontainers/cli
@@ -67,7 +67,7 @@ We try to make prebuilding an image and using a prebuilt image as easy as possib
 **Using a prebuilt image:**
 * Determine the published URL of the prebuilt image you want to use
 * Reference it in your `devcontainer.json`, Dockerfile, or Docker Compose file
-     * In our previous guide on ["Using Images, Dockerfiles, and Docker Compose,"](/_posts/2022-12-16-dockerfile.md) we also showed how you can use prebuilt images, Dockerfiles, or Docker Compose files for your configurations
+     * In our previous guide on ["Using Images, Dockerfiles, and Docker Compose,"](/guide/dockerfile) we also showed how you can use prebuilt images, Dockerfiles, or Docker Compose files for your configurations
 
 ### <a href="#prebuild-examples" name="prebuild-examples" class="anchor"> Prebuild Examples </a>
 
@@ -98,7 +98,7 @@ Let's walk through the Kubernetes prebuild as an example of how you can determin
           * We see it references a prebuilt image, which will include dependencies that don't need to be explicitly mentioned in this end user dev container. Let's next go explore the dev container defining this prebuilt image
 * **Explore the dev container defining your prebuilt image**
      * We next open the config that defines the prebuilt image. This is contained in the [`.github/.devcontainer` folder](https://github.com/craiglpeters/kubernetes-devcontainer/tree/master/.github/.devcontainer)
-     * We see there's a [`devcontainer.json`](https://github.com/craiglpeters/kubernetes-devcontainer/blob/master/.github/.devcontainer/devcontainer.json). It's much more detailed than the end user dev container we explored above and includes a variety of [Features](/_implementors/features.md)
+     * We see there's a [`devcontainer.json`](https://github.com/craiglpeters/kubernetes-devcontainer/blob/master/.github/.devcontainer/devcontainer.json). It's much more detailed than the end user dev container we explored above and includes a variety of [Features](/implementors/features)
 * **Explore content in the prebuilt dev container's config**
      * Each Feature defines additional functionality
      * We can explore what each of them installs in their associated repo. Most appear to be defined in the [devcontainers/features repo](https://github.com/devcontainers/features/tree/main/src) as part of the dev container spec
@@ -123,9 +123,9 @@ There are a variety of benefits (some of which we've already explored) to creati
 * We explored the prebuilt images we host as part of the spec in [devcontainers/images](https://github.com/devcontainers/images/tree/main/src). These can form a great base for other dev containers you'd like to create for more complex scenarios
 * The spec has a concept of Development container "Templates" which are source files packaged together that encode configuration for a complete development environment
      * A Template may be as simple as a `devcontainer.json` referencing a prebuilt image, and a `devcontainer-template.json`
-     * You can learn more about Templates in our [Templates documentation](../_implementors/templates.md)
-     * You can adopt and iterate on [existing Templates](../templates.html) from the spec and community, or you can [create and share your own](../_implementors/templates-distribution.md)
-* You can include Dev Container configuration and Feature metadata in prebuilt images via [image labels](https://docs.docker.com/config/labels-custom-metadata/). This makes the image self-contained since these settings are automatically picked up when the image is referenced - whether directly, in a `FROM` in a referenced Dockerfile, or in a Docker Compose file. You can learn more in our [reference docs](/_implementors/reference.md#metadata-in-image-labels)
+     * You can learn more about Templates in our [Templates documentation](../implementors/templates)
+     * You can adopt and iterate on [existing Templates](../templates.html) from the spec and community, or you can [create and share your own](../implementors/templates-distribution)
+* You can include Dev Container configuration and Feature metadata in prebuilt images via [image labels](https://docs.docker.com/config/labels-custom-metadata/). This makes the image self-contained since these settings are automatically picked up when the image is referenced - whether directly, in a `FROM` in a referenced Dockerfile, or in a Docker Compose file. You can learn more in our [reference docs](/implementors/reference#labels)
 * You can use multi-stage Dockerfiles to create a prod container from your dev container
      * You'd typically start with your prod image, then add to it
      * Features provide a quick way to add development and CI specific layers that you wouldn't use in production