diff --git a/COMPILING.md b/COMPILING.md
index 06cebab44..20a2eb7ff 100644
--- a/COMPILING.md
+++ b/COMPILING.md
@@ -1,6 +1,6 @@
 ## Compilation
 
-Building the project is for advanced users.
+Building the project is for users that want to contribute code only.
 If you wish to build the emulator yourself, follow these steps:
 
 ### Step 1
@@ -20,4 +20,4 @@ Then type the following command: `dotnet build -c Release -o build`
 the built files will be found in the newly created build directory.
 
 Ryujinx system files are stored in the `Ryujinx` folder.
-This folder is located in the user folder, which can be accessed by clicking `Open Ryujinx Folder` under the File menu in the GUI.
\ No newline at end of file
+This folder is located in the user folder, which can be accessed by clicking `Open Ryujinx Folder` under the File menu in the GUI.
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index af47fc9d9..686ea3994 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -74,7 +74,7 @@ We use and recommend the following workflow:
 3. In your fork, create a branch off of main (`git checkout -b mybranch`).
     - Branches are useful since they isolate your changes from incoming changes from upstream. They also enable you to create multiple PRs from the same fork.
 4. Make and commit your changes to your branch.
-    - [Build Instructions](https://github.com/GreemDev/Ryujinx#building) explains how to build and test.
+    - [Build Instructions](https://github.com/GreemDev/Ryujinx/blob/master/COMPILING.md) explains how to build and test.
     - Commit messages should be clear statements of action and intent.
 6. Build the repository with your changes.
     - Make sure that the builds are clean.
@@ -83,7 +83,7 @@ We use and recommend the following workflow:
     - State in the description what issue or improvement your change is addressing.
     - Check if all the Continuous Integration checks are passing. Refer to [Actions](https://github.com/GreemDev/Ryujinx/actions) to check for outstanding errors.
 8. Wait for feedback or approval of your changes from the core development team
-    - Details about the pull request [review procedure](docs/workflow/ci/pr-guide.md).
+    - Details about the pull request [review procedure](docs/workflow/pr-guide.md).
 9. When the team members have signed off, and all checks are green, your PR will be merged.
     - The next official build will automatically include your change.
     - You can delete the branch you used for making the change.
diff --git a/docs/workflow/pr-guide.md b/docs/workflow/pr-guide.md
index c03db210b..50f44d87f 100644
--- a/docs/workflow/pr-guide.md
+++ b/docs/workflow/pr-guide.md
@@ -9,7 +9,7 @@ To merge pull requests, you must have write permissions in the repository.
 ## Quick Code Review Rules
 
 * Do not mix unrelated changes in one pull request. For example, a code style change should never be mixed with a bug fix.
-* All changes should follow the existing code style. You can read more about our code style at [docs/coding-guidelines](../coding-guidelines/coding-style.md).
+* All changes should follow the existing code style. You can read more about our code style at [docs/coding-style](../coding-guidelines/coding-style.md).
 * Adding external dependencies is to be avoided unless not doing so would introduce _significant_ complexity. Any dependency addition should be justified and discussed before merge.
 * Use Draft pull requests for changes you are still working on but want early CI loop feedback. When you think your changes are ready for review, [change the status](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request) of your pull request.
 * Rebase your changes when required or directly requested. Changes should always be commited on top of the upstream branch, not the other way around.