diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index a568e4f5..08ba803d 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -42,3 +42,12 @@ Some resources here are **exploratory** and may never ship to the PowerShell Gal
 - Review `CONTRIBUTING.md` (root) for workflow and CLA requirements.
 - New resources or significant changes should be discussed via an issue first, referencing `doc/specs` where applicable.
 - CI runs via Azure Pipelines (`pipelines/`).
+
+## Issues and Pull Requests
+
+- Before filing an issue, search existing open and closed issues for duplicates.
+- Use the GitHub issue forms in `.github/ISSUE_TEMPLATE/`; do not file a blank issue unless a maintainer explicitly asks for one.
+- Bug reports should include the form fields for brief description, steps to reproduce, expected behavior, actual behavior, and environment.
+- Feature requests should include the form fields for feature or enhancement description and proposed technical implementation details when known.
+- Keep issue bodies concise and evidence-based. Do not paste large speculative patches into issue bodies; open a pull request or link a branch when code is available.
+- Before opening a pull request, review `CONTRIBUTING.md`, follow the PR template, keep the change focused, and summarize validation performed.
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 00000000..847b1bb7
--- /dev/null
+++ b/AGENTS.md
@@ -0,0 +1,22 @@
+# Agent instructions
+
+Follow `.github/copilot-instructions.md` for repository-specific development guidance.
+
+## Issues
+
+Before filing a GitHub issue in this repository:
+
+1. Search existing open and closed issues for duplicates.
+2. Use the GitHub issue forms in `.github/ISSUE_TEMPLATE/`; do not file a blank issue unless a maintainer explicitly asks for one.
+3. For bugs, include the same information requested by the Bug Report form: brief description, steps to reproduce, expected behavior, actual behavior, and environment.
+4. For feature requests, include the same information requested by the Feature Request form: description of the new feature or enhancement and proposed technical implementation details when known.
+5. Keep issue bodies concise and evidence-based. Do not paste large speculative patches into issue bodies; open a pull request or link a branch when code is available.
+
+## Pull requests
+
+Before opening a pull request:
+
+1. Review `CONTRIBUTING.md` and follow the repository PR template.
+2. Keep each PR focused on one logical change.
+3. Include or update tests, resource help, samples, and documentation when changing resource behavior or schema.
+4. Summarize validation performed, or explain why validation was not run.