Add Copilot instructions

.devcontainer/devcontainer.json

@@ -26,10 +26,11 @@
     },
     "vscode": {
       "extensions": [
-        "tamasfe.even-better-toml",
         "editorconfig.editorconfig",
+        "GitHub.copilot",
         "rust-lang.rust-analyzer",
         "streetsidesoftware.code-spell-checker",
+        "tamasfe.even-better-toml",
         "vadimcn.vscode-lldb"
       ]
     }

.github/copilot-instructions.md

@@ -0,0 +1,39 @@
+# Instructions
+
+You are an expert Rust programmer. You write safe, efficient, maintainable, and well-tested code.
+
+* Use an informal tone.
+* Do not be overly apologetic and focus on clear guidance.
+* If you cannot confidently generate code or other content, do not generate anything and ask for clarification.
+
+## Code Generation
+
+Use these instructions for test generation as well.
+
+* Write readable and well-documented code that follows Rust style conventions:
+  * Type names and variants are PascalCase.
+  * Constants and statics are UPPER_SNAKE_CASE.
+  * Field and function names are snake_case.
+  * Parameter names are snake_case.
+  * Crate and module names are snake_case.
+* Prioritize safety, efficiency, and correctness.
+* Respect Rust's ownership and borrowing rules.
+* Use short, descriptive names for fields, functions, parameters, and variables.
+* Handle errors using Rust's `Result` type using the `?` operator when the parent function returns a `Result`.
+* Avoid declaring lifetime parameters in public types or functions except when necessary.
+* Manage dependencies using `cargo`:
+  * Dependencies should be defined in the root workspace's `Cargo.toml` file.
+  * Crates under the `sdk/` folder should inherit those dependencies using `workspace = true` in their own `Cargo.toml` files.
+* Document public API using a concise summary, followed by a blank line, then concise details about the API.
+* Public API documentation should use Rust's document comment syntax denoted by `///` and using markdown.
+* Use `clippy` to validate that generated code does not contain lint errors.
+* If you have trouble generating safe, efficient, maintainable, and lint-free code, insert a `TODO` comment describing what should happen.
+
+## Test Generation
+
+* Tests should be generated in a `tests` module defined within the module file being tested.
+* The `tests` module should be defined at the bottom after all the existing code to test.
+* If the `tests` module already exists, only add test functions and merge imports as needed.
+* The `tests` module should be conditioned on `#[cfg(test)]`.
+* The `tests` module should always import APIs from `super`.
+* Do not begin test function names with "test" unless necessary to disambiguate from the function being tested.

.vscode/extensions.json

@@ -1,9 +1,10 @@
 {
   "recommendations": [
-    "tamasfe.even-better-toml",
     "editorconfig.editorconfig",
+    "GitHub.copilot",
     "rust-lang.rust-analyzer",
     "streetsidesoftware.code-spell-checker",
+    "tamasfe.even-better-toml",
     "vadimcn.vscode-lldb"
   ]
 }

.vscode/settings.json

@@ -2,6 +2,16 @@
   "azure-pipelines.1ESPipelineTemplatesSchemaFile": true,
   "cSpell.enabled": true,
   "editor.formatOnSave": true,
+  "github.copilot.chat.commitMessageGeneration.instructions": [
+    {
+      "file": "doc/git-commit-recommendations.md"
+    }
+  ],
+  "github.copilot.chat.pullRequestDescriptionGeneration.instructions": [
+    {
+      "file": "doc/github-pullrequest-recommendations.md"
+    }
+  ],
   "markdownlint.config": {
     "MD024": false
   },

doc/git-commit-recommendations.md

@@ -0,0 +1,18 @@
+# Recommendations for Git Commits
+
+* Git commits should follow the standard form:
+
+  ```markdown
+  title of no more than 50 characters
+
+  multi-line descriptions
+  ```
+
+* Summarize changes for a title of no more than 50 character ideally, with a hard stop at 80 characters.
+* Descriptions can be multiple lines or even paragraphs.
+* Descriptions can be detailed but should not be overly verbose and repeat a large amount of content found within changed files.
+* Summarize changes for each file if no more than 10 files are changed.
+* If multiple files contain the same changes, group them together when summarizing changes.
+* Emphasize why changes were made and less about what was changed.
+* If any comments reference fixing an issue like "Fixes #1234" include that same text in the description.
+* If the branch name includes an issue number like "issue1234" include "Fixes #1234" in the description.

doc/github-pullrequest-recommendations.md

@@ -0,0 +1,18 @@
+# Recommendations for GitHub Pull Requests
+
+* GitHub Pull Requests should follow the standard form for Git commits:
+
+  ```markdown
+  title of no more than 50 characters
+
+  multi-line descriptions
+  ```
+
+* Summarize changes for a title of no more than 50 character ideally, with a hard stop at 80 characters.
+* Descriptions can be multiple lines or even paragraphs using markdown.
+* Descriptions can be detailed but should not be overly verbose and repeat a large amount of content found within changed files.
+* Summarize changes for each file if no more than 10 files are changed.
+* If multiple files contain the same changes, group them together when summarizing changes.
+* Emphasize why changes were made and less about what was changed.
+* If any commits reference fixing or resolving an issue number like "Fixes #1234", include that same text in the description.
+* If multiple issues are fixed or resolved, include that same text separately for each issue like "Fixes #1234 and fixes #5678".