diff --git a/.github/pull_request_template.md b/.github/pull_request_template.md
index bdc1cba7a..2dba24f1e 100644
--- a/.github/pull_request_template.md
+++ b/.github/pull_request_template.md
@@ -1,6 +1,6 @@
 ## Summary
 
-<!-- Outcome and scope in 1-2 sentences. Bare ticket key, no URLs. -->
+<!-- Up to 10 short bullets (aim for 5 or fewer), one per change (a one-change PR gets one bullet), in plain sentences a reviewer reads in seconds: what the change does, not how. Details go in Why and Risks. Bare ticket key, no URLs. -->
 
 ## Why
 
diff --git a/docs/standards/git-delivery.md b/docs/standards/git-delivery.md
index 39927d4b3..ee5216833 100644
--- a/docs/standards/git-delivery.md
+++ b/docs/standards/git-delivery.md
@@ -8,7 +8,7 @@ Detail for the delivery lines in `conventions`. Read this before committing, ope
 - **No changeset in a feature or fix PR.** Do not run `pnpm changeset` or add `.changeset/*.md` alongside code. Changesets are written in their own PR once the work has landed and the release is being prepared, so the bump and summary describe the final state, not every iteration.
 - **Green before review:** `pnpm verify` passes; `pnpm regen` after any contract/schema change.
 - **Branch off `dev`; never commit directly to `dev`/`stage`.** Promotion chain `dev -> stage` + release tags. Never push without an explicit per-action confirmation, except the branch `/ship` opens its PR from.
-- **PR description carries intent:** what / why / acceptance criteria / ticket key. Follow `.github/pull_request_template.md`; do not invent extra sections.
+- **PR description carries intent:** what / why / acceptance criteria / ticket key. Follow `.github/pull_request_template.md`; do not invent extra sections. Keep the Summary to at most 10 short bullets (aim for 5 or fewer) in plain language, one per change (one bullet for a one-change PR), saying what it does rather than how; implementation detail goes in Why or Risks.
 - **Diagram the flow.** A PR that adds or changes a flow across components (a request path through gates and ports, a state machine, an async job or webhook, a new module, port or table relation) fills the template's Diagram section with a Mermaid `flowchart` or `sequenceDiagram`. Name the nodes as the code does (routes, services, ports, tables), keep it under ~15 nodes, show the refusal and failure branches, not only the happy path. No flow (docs, deps, a one-file fix): delete the section.
 - **No test plan or CI checklist in the description.** The `verify` and `commitlint` checks are already on the PR, so "typecheck clean", "159/159 passing" or "full gate passed" is noise a reviewer can see for themselves. Only write down verification CI cannot show: a manual walkthrough, a sandbox call against a vendor, a data migration run by hand.
 - **No sensitive/internal data in titles, descriptions, or commits** - they are the public record. Bare ticket key (`ABC-45`), never the URL; no internal links, hostnames, secrets, PII. When in doubt, leave it out.