docs: require a detailed PR description

.github/ISSUE_TEMPLATE/bug_report.md

@@ -24,3 +24,10 @@ A clear and concise description of what actually happened.
 - Rust toolchain: [e.g. rustc --version]
 - Soroban CLI version (if applicable):
 - Commit / branch:
+
+---
+
+**If you pick this issue up:** the pull request that closes it needs a **detailed
+description** — what was wrong, the approach you took, anything the reviewer
+should look at closely, and how you verified it. A one-line description will be
+sent back before review. See CONTRIBUTING.md.

.github/ISSUE_TEMPLATE/feature_request.md

@@ -16,3 +16,10 @@ A clear and concise description of any alternative solutions or features you've
 
 ## Additional Context
 Add any other context or screenshots about the feature request here.
+
+---
+
+**If you pick this issue up:** the pull request that closes it needs a **detailed
+description** — what was wrong, the approach you took, anything the reviewer
+should look at closely, and how you verified it. A one-line description will be
+sent back before review. See CONTRIBUTING.md.

.github/ISSUE_TEMPLATE/good_first_issue.md

@@ -22,3 +22,10 @@ Explicitly what's in/out of scope, so PRs don't sprawl.
 
 ## Definition of done
 The single, concrete, verifiable condition that means this issue is finished.
+
+---
+
+**If you pick this issue up:** the pull request that closes it needs a **detailed
+description** — what was wrong, the approach you took, anything the reviewer
+should look at closely, and how you verified it. A one-line description will be
+sent back before review. See CONTRIBUTING.md.

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,6 +1,16 @@
 ## Summary
 
-<!-- Briefly describe what this pull request changes and why. -->
+<!--
+Describe what changed and why, in enough detail that a reviewer who has NOT read
+the issue can follow it. A single line is not enough — PRs with a one-line
+description will be sent back.
+
+Cover:
+  - The problem this solves, and what the behaviour was before
+  - The approach you took, and any alternative you considered and rejected
+  - Anything the reviewer should look at closely, or that you are unsure about
+  - How you verified it (tests added, commands run, manual checks)
+-->
 
 ## Related Issue
 

CONTRIBUTING.md

@@ -187,3 +187,27 @@ Please report unacceptable behaviour by opening an issue in this repository.
 ---
 
 Apache-2.0 — contributions welcome.
+
+## Writing the pull request description
+
+**Every pull request needs a detailed description.** A one-line summary, a
+restatement of the issue title, or "fixes the issue" is not enough, and a PR
+that arrives with one will be sent back before review.
+
+Write it for a reviewer who has *not* read the issue. Cover:
+
+- **What was wrong** — the problem or gap, and the behaviour before your change.
+- **What you did** — the approach you took, and any alternative you considered
+  and rejected, with the reason.
+- **What to look at** — anything subtle, risky, or that you are unsure about.
+  Flagging your own uncertainty speeds review up; it does not count against you.
+- **How you verified it** — tests you added, commands you ran, manual checks.
+
+Two things this is not: it is not a diff summary — the diff already says which
+lines changed, and the description should say *why*. And it is not a place to
+hide problems. If something is incomplete or a known limitation remains, say so
+explicitly.
+
+Keep the `Closes #<issue-number>` reference in the description itself. GitHub
+ignores closing keywords written in PR comments, so a link posted as a comment
+will not close the issue on merge.