docs: add pull request description template

.github/ISSUE_TEMPLATE/bug.yml

@@ -0,0 +1,30 @@
+name: Bug report
+description: Report something that is not working.
+labels: ["Bug"]
+body:
+  - type: input
+    id: environment
+    attributes:
+      label: Extension and versions
+      description: Include the affected extension, Pi version, Node.js version, and OS.
+    validations:
+      required: true
+  - type: textarea
+    id: reproduction
+    attributes:
+      label: Steps to reproduce
+      description: Provide the smallest example or steps that reproduce the bug.
+    validations:
+      required: true
+  - type: textarea
+    id: behavior
+    attributes:
+      label: Expected and actual behavior
+      description: What did you expect, and what happened instead?
+    validations:
+      required: true
+  - type: textarea
+    id: evidence
+    attributes:
+      label: Logs or screenshots (optional)
+      description: Redact secrets and personal information before posting.

.github/ISSUE_TEMPLATE/feature.yml

@@ -0,0 +1,22 @@
+name: Feature request
+description: Suggest an improvement.
+labels: ["Feature Request"]
+body:
+  - type: input
+    id: scope
+    attributes:
+      label: Affected extension or area
+    validations:
+      required: true
+  - type: textarea
+    id: problem
+    attributes:
+      label: Problem or use case
+      description: What are you trying to do, and what is missing today?
+    validations:
+      required: true
+  - type: textarea
+    id: solution
+    attributes:
+      label: Suggested solution or alternatives (optional)
+      description: How might this work? Other approaches are welcome.

.github/pull_request_template.md

@@ -0,0 +1,53 @@
+<!-- Keep this concise and high-level. Remove optional sections that do not apply. -->
+
+## Summary
+
+<!-- Give a high-level overview in 150 words or fewer. -->
+-
+
+## What
+
+<!-- What changed? Mention the affected package(s), code, or shared tooling -->
+-
+
+## Why
+<!-- What problem does this solve, and why this approach? -->
+-
+
+## Related issues
+
+<!-- Link relevant issues (e.g. "Closes #123"), or write "None". An issue is optional. -->
+-
+
+## Testing
+
+<!--
+- List pi version, commands run and their results, plus relevant manual checks.
+- For package changes, use npm run <script> --prefix <package>:
+  lint, typecheck, test, build
+- For shared tooling changes: npm run test:tooling
+- For Pi behavior/UI changes, describe how you verified the change in Pi.
+- If a check was not run, say why. Docs-only changes can say "Not run (docs only)".
+-->
+-
+
+## Compatibility
+
+<!-- Note breaking changes, new dependencies, configuration/permission changes,
+or migration steps. Write "None" if there are no compatibility concerns. -->
+-
+
+## Risk
+
+<!-- What could this change break? Be specific, or explain why the risk is low. -->
+-
+
+## Screenshots / recordings (optional)
+
+<!-- For visible UI changes, show before/after where useful. Redact secrets and personal data. -->
+
+## Checklist
+
+- [ ] The change is focused; unrelated changes are excluded.
+- [ ] Tests cover behavior changes, or the testing section explains why not.
+- [ ] Relevant documentation is updated, or no documentation changes are needed.