diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 877c03e4..b5f57c5c 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -10,3 +10,7 @@
 ## How Has This Been Tested?
 
 <!-- Describe how the changes have been tested. Provide test instructions or details. -->
+
+### Contributor Checklist
+- [ ] **LLM Usage** If an LLM was used to generate any code, please ensure and confirm you have read
+  and followed the [AI usage guide](../CONTRIBUTING.md#ai-usage).
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 00000000..14d3f054
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,52 @@
+# Contributing Guide
+
+Thank you for your interest in contributing. This guide covers the expectations and process for
+contributing to this library.
+
+## Reporting Bugs
+
+Before opening a bug report, please:
+
+1. Check the existing issues to see if the bug has already been reported.
+2. Reproduce the problem with the latest version of the library.
+3. Include a minimal, self-contained reproduction case.
+
+## Reporting Feature Requests
+
+Before opening a feature request, please:
+
+1. Check the existing issues to confirm the feature has not already been requested.
+2. Describe the problem you are trying to solve, not just the solution you have in mind. This helps
+   maintainers understand the use case and evaluate alternative approaches.
+3. Keep the scope narrow. A focused request is easier to reason about and more likely to be acted on
+   than a broad one covering multiple unrelated capabilities.
+
+Feature requests are not guaranteed to be implemented. If a request is out of scope or unlikely to
+be prioritized, it may be closed without action.
+
+## Pull Request Guidelines
+
+- **Small is better.** A focused, easy-to-review PR is far more likely to be merged promptly than a
+  large one.
+- **Update tests.** All bug fixes must include a regression test. All behaviour changes must update
+  or add tests accordingly.
+- **Update documentation.** If the public API or behaviour changes, update the relevant comments,
+  README, or other docs in the same PR.
+- **Pass CI.** Ensure all existing tests pass locally before opening the PR. New failures introduced
+  by your change will block review.
+
+## Maintainer Response Time
+
+This library is maintained on a best-effort basis alongside other priorities. Please allow
+reasonable time for a response. Pinging a PR repeatedly or opening duplicate issues will not speed
+up the process.
+
+## AI Usage
+AI-assisted contributions are welcome. When using AI tools, contributors remain responsible for the
+final submission. Before opening a pull request:
+
+* Review and understand every change.
+* Verify that the code follows the project's style and conventions.
+* Write commit messages and pull request descriptions yourself.
+
+Do not submit code that you do not understand or cannot explain during review.