docs(infra): clarify PR description expectations (#38007)

PR authors get clearer guidance for writing descriptions that reviewers
can understand quickly. The template and contributor guidance now ask
for a short explanation of who benefits, what problem they had, and how
the change solves it instead of a generic summary.

.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.

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.

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.