diff --git a/.github/PULL_REQUEST_TEMPLATE.md b/.github/PULL_REQUEST_TEMPLATE.md
index ef903ab111d..4fa136e2deb 100644
--- a/.github/PULL_REQUEST_TEMPLATE.md
+++ b/.github/PULL_REQUEST_TEMPLATE.md
@@ -22,7 +22,7 @@ Thank you for contributing to LangChain! Follow these steps to have your pull re
 
 2. PR description:
 
-  - Write 1-2 sentences summarizing the change.
+  - Write 1-2 sentences that make the change easy to understand: who benefits, what problem they had, and how this solves it. Prefer a simple user story over a long summary.
   - The `Fixes #xx` line at the top is **required** for external contributions — update the issue number and keep the keyword. This links your PR to the approved issue and auto-closes it on merge.
   - If there are any breaking changes, please clearly describe them.
   - If this PR depends on another PR being merged first, please include "Depends on #PR_NUMBER" in the description.
diff --git a/AGENTS.md b/AGENTS.md
index 8e3de8d5c58..98e8d0ce056 100644
--- a/AGENTS.md
+++ b/AGENTS.md
@@ -138,7 +138,7 @@ The description *is* the summary — do not add a `# Summary` header.
 
   Only `Closes`, `Fixes`, and `Resolves` auto-close the referenced issue on merge. `Related:` or similar labels are informational and do not close anything.
 
-- Explain the *why*: the motivation and why this solution is the right one. Limit prose.
+- Explain the *why*: who benefits, what problem they had, and how this solves it. Prefer a simple user story over a long summary.
 - Write for readers who may be unfamiliar with this area of the codebase. Avoid insider shorthand and prefer language that is friendly to public viewers — this aids interpretability.
 - Do **not** cite line numbers; they go stale as soon as the file changes.
 - Rarely include full file paths or filenames. Reference the affected symbol, class, or subsystem by name instead.
diff --git a/CLAUDE.md b/CLAUDE.md
index 8e3de8d5c58..98e8d0ce056 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -138,7 +138,7 @@ The description *is* the summary — do not add a `# Summary` header.
 
   Only `Closes`, `Fixes`, and `Resolves` auto-close the referenced issue on merge. `Related:` or similar labels are informational and do not close anything.
 
-- Explain the *why*: the motivation and why this solution is the right one. Limit prose.
+- Explain the *why*: who benefits, what problem they had, and how this solves it. Prefer a simple user story over a long summary.
 - Write for readers who may be unfamiliar with this area of the codebase. Avoid insider shorthand and prefer language that is friendly to public viewers — this aids interpretability.
 - Do **not** cite line numbers; they go stale as soon as the file changes.
 - Rarely include full file paths or filenames. Reference the affected symbol, class, or subsystem by name instead.