diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 3ab3a38807..f1f7aa18f7 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -29,22 +29,6 @@ If a refactor, how is this better than the previous implementation?
 If there is a spec or design document for this feature, please link it here.
 -->
 
-### Type of Change
-
-<!--
-Please check [x] relevant options, delete irrelevant ones.
--->
-
-- [ ] Bug fix (non-breaking change which fixes an issue)
-- [ ] New feature (non-breaking change which adds functionality)
-- [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
-- [ ] Refactor (non-breaking change that only restructures code)
-- [ ] Performance (increase or change in throughput and/or latency)
-- [ ] Tests (you added tests for code that already exists, or your new feature included in this PR)
-- [ ] Documentation update
-- [ ] Chore (no impact to binary, e.g. `.gitignore`, formatting, dropping support for older tooling)
-- [ ] Release
-
 ### API Impact
 
 <!--
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 4bb1db8689..86bef765a5 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -127,26 +127,6 @@ tl;dr
 > 6. Wrap the body at 72 characters.
 > 7. Use the body to explain what and why vs. how.
 
-In addition to those guidelines, please add one of the following
-prefixes to the subject line if appropriate.
-
-- `fix:` - The primary purpose is to fix an existing bug.
-- `perf:` - The primary purpose is performance improvements.
-- `refactor:` - The changes refactor code without affecting
-  functionality.
-- `test:` - The changes _only_ affect unit tests.
-- `docs:` - The changes _only_ affect documentation. This can
-  include code comments in addition to `.md` files like this one.
-- `build:` - The changes _only_ affect the build process,
-  including CMake and/or Conan settings.
-- `chore:` - Other tasks that don't affect the binary, but don't fit
-  any of the other cases. e.g. formatting, git settings, updating
-  Github Actions jobs.
-
-Whenever possible, when updating commits after the PR is open, please
-add the PR number to the end of the subject line. e.g. `test: Add
-unit tests for Feature X (#1234)`.
-
 ## Pull requests
 
 In general, pull requests use `develop` as the base branch.
@@ -180,6 +160,23 @@ credibility of the existing approvals is insufficient.
 Pull requests must be merged by [squash-and-merge][squash]
 to preserve a linear history for the `develop` branch.
 
+### Type of Change
+
+In addition to those guidelines, please start your PR title with one of the following:
+
+- `build:` - The changes _only_ affect the build process, including CMake and/or Conan settings.
+- `feat`: New feature (change which adds functionality).
+- `fix:` - The primary purpose is to fix an existing bug.
+- `docs:` - The changes _only_ affect documentation.
+- `test:` - The changes _only_ affect unit tests.
+- `ci`: Continuous Integration (changes to our CI configuration files and scripts).
+- `style`: Code style (formatting).
+- `refactor:` - The changes refactor code without affecting functionality.
+- `perf:` - The primary purpose is performance improvements.
+- `chore:` - Other tasks that don't affect the binary, but don't fit any of the other cases. e.g. `git` settings, `clang-tidy`, removing dead code, dropping support for older tooling.
+
+First letter after the type prefix should be capitalized, and the type prefix should be followed by a colon and a space. e.g. `feat: Add support for Borrowing Protocol`.
+
 ### "Ready to merge"
 
 A pull request should only have the "Ready to merge" label added when it