diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md
index cff632ea80..8d0039bbc4 100644
--- a/.github/copilot-instructions.md
+++ b/.github/copilot-instructions.md
@@ -161,6 +161,15 @@ void WorkflowTask(Execution::Context& context)
 - Follow existing code style (see `stylecop.json`)
 - CI runs on Azure Pipelines (`azure-pipelines.yml`)
 
+## 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 relevant area, command if applicable, brief description, steps to reproduce, expected behavior, actual behavior, and environment.
+- Feature requests should include the form fields for relevant area, 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.
+
 ## Useful Commands
 
 ```powershell
diff --git a/AGENTS.md b/AGENTS.md
new file mode 100644
index 0000000000..7bc0701783
--- /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: relevant area, command if applicable, 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: relevant area, 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 and documentation when the change affects behavior, command output, user guidance, or public APIs.
+4. Summarize validation performed, or explain why validation was not run.