Use relative link where possible

code-review.qmd

@@ -10,7 +10,7 @@ The ways of working for code reviews within Epiverse-TRACE packages follows many
 - Progress over perfection: accept pull requests which better the code without needing to be perfect to prevent slowdowns.
 - Adhere to the established code style. This is automatically checked by the [lintr continuous integration workflow](https://github.com/epiverse-trace/packagetemplate/blob/main/.github/workflows/lint-changed-files.yaml)
 - When changes are non-trivial test out new changes locally. This is especially important if the changes are user-facing.
-- To enable [agile development](https://epiverse-trace.github.io/blueprints/principles.html#lean-and-agile-collaboration-framework) PRs should be swiftly, but thoroughly, reviewed. The pace of code review is predominantly influenced by the size of the PR, so but keeping changes in PRs functionality small and [focused](https://code-review.tidyverse.org/author/focused.html), will enable the team to review and close PRs and keep momentum with development.
+- To enable [agile development](principles.html#lean-and-agile-collaboration-framework) PRs should be swiftly, but thoroughly, reviewed. The pace of code review is predominantly influenced by the size of the PR, so but keeping changes in PRs functionality small and [focused](https://code-review.tidyverse.org/author/focused.html), will enable the team to review and close PRs and keep momentum with development.
 - Use suggestions when beneficial, for example typos, to allow the PR author to easily apply changes through commits directly in GitHub.
 - Take advantage of [GitHub's keyword mechanism](https://docs.github.com/en/get-started/writing-on-github/working-with-advanced-formatting/using-keywords-in-issues-and-pull-requests) to reference and close issues through commits and then refer to these in the description of the PR.
 - Once a conversation on a PR is resolved, the "Resolve conversation" button can collapse that specific discussion. The PR author should resolve conversations. It is good practice to add a comment with a link to the commit SHA (which can be copied from GitHub commit history) to let those involved in the conversation know where the changes were applied. In the case a PR author misses resolving a conversation but has messaged with the commit SHA the PR reviewer can resolve it. Additionally, it is perfectly reasonable to merge an approved PR with some conversations left open, assuming they have been addressed in the PR.