Session memory extraction + tiered context loading improvements

- /review-all-gdds, /architecture-review, /story-done: auto-append Session
  Extract block to active.md after report write (verdict, flags, next action)
- /review-all-gdds, /architecture-review, /create-epics-stories, /content-audit:
  L0 summary scan phase before full document load (reduces token cost)
- GDD template: added Summary section + Cross-References table + Last Verified field
- ADR template: added Summary section + Last Verified field

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>

.claude/docs/templates/architecture-decision-record.md

@@ -6,12 +6,25 @@
 
 ## Date
 
-[YYYY-MM-DD]
+[YYYY-MM-DD — when this ADR was written]
+
+## Last Verified
+
+[YYYY-MM-DD — when this ADR was last confirmed accurate against the current
+engine version and design. Update this date when you re-read and confirm it
+is still correct, even if nothing changed.]
 
 ## Decision Makers
 
 [Who was involved in this decision]
 
+## Summary
+
+[2 sentences: what problem this ADR solves, and what was decided. Written for
+tiered context loading — a skill scanning 20 ADRs uses this to decide whether
+to read the full decision. Be specific: name the system, the problem, and the
+chosen approach.]
+
 ## Engine Compatibility
 
 | Field | Value |

.claude/docs/templates/game-design-document.md

@@ -3,8 +3,17 @@
 > **Status**: Draft | In Review | Approved | Implemented
 > **Author**: [Agent or person]
 > **Last Updated**: [Date]
+> **Last Verified**: [Date — when this doc was last confirmed accurate against current design]
 > **Implements Pillar**: [Which game pillar this supports]
 
+## Summary
+
+[2–3 sentences: what this system is, what it does for the player, and why it
+exists in this game. Written for tiered context loading — a skill scanning
+20 GDDs uses this section to decide whether to read further. No jargon.]
+
+> **Quick reference** — Layer: `[Foundation | Core | Feature | Presentation]` · Priority: `[MVP | Vertical Slice | Alpha | Full Vision]` · Key deps: `[System names or "None"]`
+
 ## Overview
 
 [One paragraph that explains this mechanic to someone who knows nothing about
@@ -174,6 +183,24 @@ These are subjective targets stated precisely enough to get consistent verdicts.
 | Information | Display Location | Update Frequency | Condition |
 |-------------|-----------------|-----------------|-----------|
 
+## Cross-References
+
+[Declare every explicit dependency on another GDD's specific mechanic, value, or
+rule. This table is machine-checked by `/review-all-gdds` Phase 2c — it replaces
+implicit prose references with verifiable declarations. If you reference another
+system's behaviour anywhere in this document, it must appear here.]
+
+| This Document References | Target GDD | Specific Element Referenced | Nature |
+|--------------------------|-----------|----------------------------|--------|
+| [e.g., "combo multiplier feeds score"] | `design/gdd/score.md` | `combo_multiplier` output value | Data dependency |
+| [e.g., "death triggers respawn"] | `design/gdd/respawn.md` | Death state transition | State trigger |
+| [e.g., "stamina gates dodge"] | `design/gdd/stamina.md` | Stamina depletion rule | Rule dependency |
+
+> **Note on "Nature"**: use one of — `Data dependency` (we consume their output),
+> `State trigger` (their state change triggers our behaviour), `Rule dependency`
+> (our rule assumes their rule is also true), `Ownership handoff` (we hand off
+> ownership of a value to them).
+
 ## Acceptance Criteria
 
 [Testable criteria that confirm this mechanic is working as designed.]