diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 0000000..ac727ba
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,71 @@
+# How to contribute to Meshcore Open
+
+Before submitting any pull requests (PR), please review the following information.
+
+Unsolicited PRs without previous discussion or open issues may be
+rejected. As may changes that are too broad (i.e. 100 files changed) or that
+cover too many separate changes. If the changes are clearly AI generated they
+may also be rejected. [See more](#ai-use)
+
+## First Step Checklist
+
+### **Did you find a bug?**
+
+* **Ensure the bug was not already reported** by searching on GitHub under [Issues](https://github.com/zjs81/meshcore-open/issues).
+
+* If you're unable to find an open issue addressing the problem, [open a new one](https://github.com/zjs81/meshcore-open/issues/new).
+Be sure to include a **title and clear description**, as much relevant
+information as possible, and a **code sample** or an **executable test case**
+demonstrating the expected behavior that is not occurring. You can also include
+screenshots or video.
+
+* DO NOT start work and submit a PR at this time, please discuss the issue and
+your implementation plan first.
+
+### **Did you fix whitespace, format code, or make a purely cosmetic patch?**
+
+Changes that are cosmetic in nature and do not add anything substantial to the
+stability, functionality, or testability of the application will generally not
+be accepted.
+
+### **Do you intend to add a new feature or change an existing one?**
+
+* Suggest your change in a new issue as a feature request.
+
+* DO NOT start work and submit a PR at this time, please discuss the change and
+your implementation plan first.
+
+* After it is generally decided that the feature or change fits the goals of the
+project you can start work or open a PR if you have already started.
+
+## Submitting your patch
+
+* All changes should be based on the `dev` branch. When creating your PR please
+be sure to change the target to merge into dev, and when starting work on a new
+branch be sure to start on latest `dev`.
+
+* Ensure the PR description clearly describes the problem and solution. Include
+the relevant issue number if applicable.
+
+* The PR should contain **one commit** only, the commit message should have a
+clear title followed by a new line and then brief description if needed. PR with
+multiple commits will be squashed into one before merging if required. See
+[Git Mastery](https://git-mastery.org/lessons/commitMessage/) for more
+information on good commit messages.
+
+* **Before committing changes** on your branch, be sure to run both
+`dart format .` and `flutter analyze`. The continuous development checks will
+fail if issues here are not addressed before hand.
+
+## AI-use
+
+Everyone loves some help, AI agents are a tool in many of our belts. The project
+is not anti-AI.
+
+There are some limits to acceptable use however. Generally:
+
+* All code generated by AI should be thoroughly reviewed by the contributor.
+* The changes should be tightly controlled to not change anything out of scope
+for the patch, bug fix, etc.
+* The contributor should have a good understanding of what the code does and how
+the application works in order to effectively be able to manage the agent.