diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md
new file mode 100644
index 0000000..1d42fcf
--- /dev/null
+++ b/.github/ISSUE_TEMPLATE/bug_report.md
@@ -0,0 +1,22 @@
+---
+name: Bug report
+about: Something is broken or a reconstruction behaves unexpectedly
+labels: bug
+---
+
+## What happened
+
+<!-- What you expected, what you got instead, and the full traceback if there is one.
+     For reconstruction problems, a figure of the result helps a lot. -->
+
+## How to reproduce
+
+<!-- A minimal script, the engine and its parameters, and the dataset if you can
+     share it (or a link to it). -->
+
+## Environment
+
+- PtyLab version: <!-- pip show ptylab or the git commit -->
+- Python version:
+- OS:
+- CPU or GPU (and CuPy/CUDA version if GPU):
diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index 29a966c..3e8838a 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,37 +1,12 @@
-<!-- One or two lines: what this changes, and how it relates to what came before
-     (a series, an issue, an earlier PR). Bold the one thing a reviewer must not
-     miss — a breaking change, changed numerical output, "no runtime code is
-     touched". Delete any section below that does not apply. -->
+## What and why
 
-## Why
+<!-- What this changes and why. Link the related issue or PR, if any. -->
 
-<!-- The problem, stated concretely. A traceback, a measurement, or a file:line
-     beats a description of the problem. If it is a bug: what breaks, where, and
-     for whom. If it is performance: the number that justifies the work. -->
+## How it was tested
 
-## What changed
+<!-- Tests added or run, or how you checked the change works.
+     If possible, add a demo figure or screenshot showing the result. -->
 
-<!-- The change itself, in the order a reviewer would want to read it. Tables for
-     measurements. Before/after code only where the diff alone is not obvious. -->
+## Notes
 
-## Verification
-
-<!-- Evidence the change does what it claims, and that the tests would have
-     caught the bug. Reverting the fix and showing the new tests fail is the
-     standard here — a test that passes on `main` proves nothing. -->
-
-## Tests
-
-<!-- New/changed test files and what each covers, then the suite count:
-     N → M passing. -->
-
-## Notes and follow-ups
-
-<!-- Anything deliberately left out, pre-existing problems this diff makes
-     visible but does not fix, and any decision a reviewer is being asked to
-     make. -->
-
-## Version
-
-<!-- `x.y.z` → `x.y.z`, and whether that publishes on merge. "No bump — nothing
-     ships from this" is a valid answer, but say it explicitly. -->
+<!-- Optional: breaking changes, changed reconstruction results, follow-ups. -->