diff --git a/src/docs/Ways-of-Working/PR-Format.md b/src/docs/Ways-of-Working/PR-Format.md
index 2be10a1..7f9d6af 100644
--- a/src/docs/Ways-of-Working/PR-Format.md
+++ b/src/docs/Ways-of-Working/PR-Format.md
@@ -92,28 +92,21 @@ Under each header:
 
 Do **not** mention internal function names, class names, private APIs, or refactoring decisions here.
 
-### 3. Technical details (optional)
+### 3. Required ending blocks
 
-```markdown
-## Technical Details
-```
-
-For reviewers and maintainers. Not part of the release note. Include:
-
-- Which internal functions, classes, or files were changed.
-- Implementation approach and design decisions.
-- Backward compatibility notes for developers.
-- **Implementation plan progress** — cross-reference Section 3 of the linked issue. Which tasks does this PR complete? Which remain?
+At the very end of every PR description, use this exact structure:
 
-Omit the section entirely if there's nothing noteworthy.
+```markdown
+---
+<details>
+<summary>Technical details</summary>
 
-### 4. Related issues
+...
 
-A collapsible `<details>` block at the very end of the description containing issue links. Always use fully qualified references (`Owner/Repo#N`) so links work across repositories.
+</details>
 
-```markdown
 <details>
-<summary>Related issues</summary>
+<summary>Relevant issues (or links)</summary>
 
 - Fixes Owner/Repo#123
 - Owner/OtherRepo#124
@@ -121,7 +114,16 @@ A collapsible `<details>` block at the very end of the description containing is
 </details>
 ```
 
-One bullet per linked issue. Use a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) (`Fixes`, `Closes`, `Resolves`) when the PR fully addresses the issue. Otherwise, list the reference without a keyword to indicate a relationship without auto-closing.
+The **Technical details** block is for reviewers and maintainers. Include internal implementation notes such as:
+
+- Which internal functions, classes, or files were changed.
+- Implementation approach and design decisions.
+- Backward compatibility notes for developers.
+- **Implementation plan progress** — cross-reference Section 3 of the linked issue. Which tasks does this PR complete? Which remain?
+
+The **Relevant issues (or links)** block is required and uses fully qualified references (`Owner/Repo#N`) so links work across repositories.
+
+Use one bullet per linked issue. Use a [closing keyword](https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue) (`Fixes`, `Closes`, `Resolves`) when the PR fully addresses the issue. Otherwise, list the reference without a keyword to indicate a relationship without auto-closing.
 
 If no issue is linked: **stop**. PRs without issues break the workflow. Route back to the Ideator role or proceed only on explicit user confirmation. The Shipper enforces this.
 
@@ -150,15 +152,19 @@ The `repo properties` command remains available if only the properties are neede
 
 Commands that query a specific repository, enterprise, or release by name now return nothing instead of throwing when the resource doesn't exist. This makes them safe to use in conditional logic without error handling.
 
-## Technical Details
+---
+<details>
+<summary>Technical details</summary>
 
 - The repository model's custom-properties field is now a typed collection rather than an untyped object.
 - The GraphQL query layer splits error handling into partial-success (data + errors → warnings) and full-failure (errors only → terminating error) branches.
 - Null guards added to the repository lookup helpers.
 - Implementation plan progress: tasks 1–3 in #218 completed; task 4 (integration tests) remains.
 
+</details>
+
 <details>
-<summary>Related issues</summary>
+<summary>Relevant issues (or links)</summary>
 
 - Fixes Owner/Repo#218
 - Owner/Repo#219