Architecture Review

Architecture Review

The architecture review validates that the complete body of architectural decisions covers all game design requirements, is internally consistent, and correctly targets the project's pinned engine version. It is the quality gate between Technical Setup and Pre-Production.

Argument modes:

• No argument / full: Full review — all phases
• coverage: Traceability only — which GDD requirements have no ADR
• consistency: Cross-ADR conflict detection only
• engine: Engine compatibility audit only
• single-gdd [path]: Review architecture coverage for one specific GDD
• rtm: Requirements Traceability Matrix — extends the standard matrix

to include story file paths and test file paths; outputs docs/architecture/requirements-traceability.md with the full GDD requirement → ADR → Story → Test chain. Use in Production phase when stories and tests exist.

---

Phase 1: Load Everything

Phase 1a — L0: Summary Scan (fast, low tokens)

Before reading any full document, use Grep to extract ## Summary sections from all GDDs and ADRs:

Grep pattern="## Summary" glob="design/gdd/*.md" output_mode="content" -A 4
Grep pattern="## Summary" glob="docs/architecture/adr-*.md" output_mode="content" -A 3

For single-gdd [path] mode: use the target GDD's summary to identify which ADRs reference the same system (Grep ADRs for the system name), then full-read only those ADRs. Skip full-reading unrelated GDDs entirely.

For engine mode: only full-read ADRs — GDDs are not needed for engine checks.

For coverage or full mode: proceed to full-read everything below.

Phase 1b — L1/L2: Full Document Load

Read all inputs appropriate to the mode:

Design Documents

• All in-scope GDDs in design/gdd/ — read every file completely
• design/gdd/systems-index.md — the authoritative list of systems

Architecture Documents

• All in-scope ADRs in docs/architecture/ — read every file completely
• docs/architecture/architecture.md if it exists

Engine Reference

• docs/engine-reference/[engine]/VERSION.md
• docs/engine-reference/[engine]/breaking-changes.md
• docs/engine-reference/[engine]/deprecated-apis.md
• All files in docs/engine-reference/[engine]/modules/

Project Standards

• .agents/docs/technical-preferences.md

Report a count: "Loaded [N] GDDs, [M] ADRs, engine: [name + version]."

Also read docs/consistency-failures.md if it exists. Extract entries with Domain matching the systems under review (Architecture, Engine, or any GDD domain being covered). Surface recurring patterns as a "Known conflict-prone areas" note at the top of the Phase 4 conflict detection output.

---

Phase 2: Extract Technical Requirements from Every GDD

Pre-load the TR Registry

Before extracting any requirements, read docs/architecture/tr-registry.yaml if it exists. Index existing entries by id and by normalized requirement text (lowercase, trimmed). This prevents ID renumbering across review runs.

For each requirement you extract, the matching rule is:

1. Exact/near match to an existing registry entry for the same system →

reuse that entry's TR-ID unchanged. Update the requirement text in the registry only if the GDD wording changed (same intent, clearer phrasing) — add a revised: [date] field.

1. No match → assign a new ID: next available TR-[system]-NNN for that

system, starting from the highest existing sequence + 1.

1. Ambiguous (partial match, intent unclear) → ask the user:

> "Does '[new requirement text]' refer to the same requirement as > TR-[system]-NNN: [existing text]', or is it a new requirement?" User answers: "Same requirement" (reuse ID) or "New requirement" (new ID).

For any requirement with status: deprecated in the registry — skip it. It was removed from the GDD intentionally.

For each GDD, read it and extract all technical requirements — things the architecture must provide for the system to work. A technical requirement is any statement that implies a specific architectural decision.

Categories to extract:

| Category | Example | |----------|---------| | Data structures | "Each entity has health, max health, status effects" → needs a component/data schema | | Performance constraints | "Collision detection must run at 60fps with 200 entities" → physics budget ADR | | Engine capability | "Inverse kinematics for character animation" → IK system ADR | | Cross-system communication | "Damage system notifies UI and audio simultaneously" → event/signal architecture ADR | | State persistence | "Player progress persists between sessions" → save system ADR | | Threading/timing | "AI decisions happen off the main thread" → concurrency ADR | | Platform requirements | "Supports keyboard, gamepad, touch" → input system ADR |

For each GDD, produce a structured list:

GDD: [filename]
System: [system name]
Technical Requirements:
  TR-[GDD]-001: [requirement text] → Domain: [Physics/Rendering/etc]
  TR-[GDD]-002: [requirement text] → Domain: [...]

This becomes the requirements baseline — the complete set of what the architecture must cover.

---

Phase 3: Build the Traceability Matrix

For each technical requirement extracted in Phase 2, search the ADRs:

1. Read every ADR's "GDD Requirements Addressed" section
2. Check if it explicitly references the requirement or its GDD
3. Check if the ADR's decision text implicitly covers the requirement
4. Mark coverage status:

| Status | Meaning | |--------|---------| | ✅ Covered | An ADR explicitly addresses this requirement | | ⚠️ Partial | An ADR partially covers this, or coverage is ambiguous | | ❌ Gap | No ADR addresses this requirement |

Build the full matrix:

## Traceability Matrix

| Requirement ID | GDD | System | Requirement | ADR Coverage | Status |
|---------------|-----|--------|-------------|--------------|--------|
| TR-combat-001 | combat.md | Combat | Hitbox detection  Last Updated: [date]
> Mode: /architecture-review rtm
> Coverage: [N]% full chain complete (GDD → ADR → Story → Test)

## How to read this matrix

| Column | Meaning |
|--------|---------|
| TR-ID | Stable requirement ID from tr-registry.yaml |
| GDD | Source design document |
| ADR | Architectural decision governing implementation |
| Story | Story file that implements this requirement |
| Test File | Automated test file path |
| Test Status | COVERED / MISSING / NONE / NO STORY |

## Full Traceability Matrix

| TR-ID | GDD | Requirement | ADR | Story | Test File | Status |
|-------|-----|-------------|-----|-------|-----------|--------|
[Full matrix rows from Phase 3b]

## Coverage Summary

| Status | Count | % |
|--------|-------|---|
| COVERED — full chain complete | [N] | [%] |
| MISSING test — story exists, no test | [N] | [%] |
| NO STORY — ADR exists, not yet implemented | [N] | [%] |
| NO ADR — architectural gap | [N] | [%] |
| **Total requirements** | **[N]** | **100%** |

## Uncovered Requirements (Priority Fix List)

Requirements where the full chain is broken, prioritised by layer:

### Foundation layer gaps
[list with suggested action per gap]

### Core layer gaps
[list]

### Feature / Presentation layer gaps
[list — lower priority]

## History

| Date | Full Chain % | Notes |
|------|-------------|-------|
| [date] | [%] | Initial RTM |

TR Registry Update

Also ask: "May I update docs/architecture/tr-registry.yaml with new requirement IDs from this review?"

If yes:

• Append any new TR-IDs that weren't in the registry before this review
• Update requirement text and revised date for any entries whose GDD

wording changed (ID stays the same)

• Mark status: deprecated for any registry entries whose GDD requirement

no longer exists (confirm with user before marking deprecated)

• Never renumber or delete existing entries
• Update the last_updated and version fields at the top

This ensures all future story files can reference stable TR-IDs that persist across every subsequent architecture review.

Reflexion Log Update

After writing the review report, append any 🔴 CONFLICT entries found in Phase 4 to docs/consistency-failures.md (if the file exists):

### [YYYY-MM-DD] — /architecture-review — 🔴 CONFLICT
**Domain**: Architecture / [specific domain e.g. State Ownership, Performance]
**Documents involved**: [ADR-NNNN] vs [ADR-MMMM]
**What happened**: [specific conflict — what each ADR claims]
**Resolution**: [how it was or should be resolved]
**Pattern**: [generalised lesson for future ADR authors in this domain]

Only append CONFLICT entries — do not log GAP entries (missing ADRs are expected before the architecture is complete). Do not create the file if missing — only append when it already exists.

Session State Update

After writing all approved files, silently append to production/session-state/active.md:

## Session Extract — /architecture-review [date]

• Verdict: [PASS / CONCERNS / FAIL]
• Requirements: [N] total — [X] covered, [Y] partial, [Z] gaps
• New TR-IDs registered: [N, or "None"]
• GDD revision flags: [comma-separated GDD names, or "None"]
• Top ADR gaps: [top 3 gap titles from the report, or "None"]
• Report: docs/architecture/architecture-review-[date].md

If active.md does not exist, create it with this block as the initial content. Confirm in conversation: "Session state updated."

The traceability index format:

# Architecture Traceability Index
Last Updated: [date]
Engine: [name + version]

## Coverage Summary
- Total requirements: [N]
- Covered: [X] ([%])
- Partial: [Y]
- Gaps: [Z]

## Full Matrix
[Complete traceability matrix from Phase 3]

## Known Gaps
[All ❌ items with suggested ADRs]

## Superseded Requirements
[Requirements whose GDD was changed after the ADR was written]

---

Phase 9: Handoff

After completing the review and writing approved files, present:

1. Immediate actions: List the top 3 ADRs to create (highest-impact gaps first,

Foundation layer before Feature layer)

1. Pre-gate checklist: Check whether these exist via Glob and mark each ✅ or ❌:

• tests/unit/ and tests/integration/ directories — if ❌: run /test-setup
• .github/workflows/tests.yml — if ❌: run /test-setup
• design/accessibility-requirements.md — if ❌: run /ux-design
• design/ux/interaction-patterns.md — if ❌: run /ux-design

Present ❌ items as required steps before gate-check. Do not offer /gate-check as an option if any item is ❌ — offer the missing skill to run instead.

1. Rerun trigger: "Re-run /architecture-review after each new ADR is written

to verify coverage improves"

Then close with AskUserQuestion tailored to the pre-gate checklist state:

• If ADR gaps remain or any pre-gate item is ❌:
• "Architecture review complete. What would you like to do next?"
• [A] Write a missing ADR — open a fresh session and run /architecture-decision [system]
• [B] Run /test-setup — required before gate-check (only show if test infrastructure is ❌)
• [C] Run /ux-design — required before gate-check (only show if UX/accessibility files are ❌)
• [D] Stop here for this session
• If all pre-gate checklist items are ✅ and no blocking ADR gaps remain:
• "Architecture review complete. All pre-gate items confirmed. What would you like to do next?"
• [A] Run /gate-check pre-production
• [B] Write a missing ADR — open a fresh session and run /architecture-decision [system]
• [C] Stop here for this session

---

Error Recovery Protocol

If any spawned agent returns BLOCKED, errors, or fails to complete:

1. Surface immediately: Report "[AgentName]: BLOCKED — [reason]" before continuing
2. Assess dependencies: If the blocked agent's output is required by a later phase, do not proceed past that phase without user input
3. Offer options via AskUserQuestion with three choices:

• Skip this agent and note the gap in the final report
• Retry with narrower scope (fewer GDDs, single-system focus)
• Stop here and resolve the blocker first

1. Always produce a partial report — output whatever was completed so work is not lost

---

Collaborative Protocol

1. Read silently — do not narrate every file read
2. Show the matrix — present the full traceability matrix before asking for

anything; let the user see the state

1. Don't guess — if a requirement is ambiguous, ask: "Is [X] a technical

requirement or a design preference?"

1. Draft before approval — always show the content that will be written (the

report, the updated ADR section, the systems-index row) inline in the conversation before requesting approval. Never ask to write something the user has not yet seen.

1. Use AskUserQuestion for write approvals — plain text "May I?" is not

sufficient. Use the structured tool with labeled options [A]/[B]/[C] so the user can choose between "write now", "show full draft first", and "not yet". Multi-file changesets must list every file and what changes, then ask once with grouped options — not a separate plain-text question per file.

1. Non-blocking — the verdict is advisory; the user decides whether to continue

despite CONCERNS or even FAIL findings

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: bullish0x
• Source: bullish0x/GameStudio
• License: MIT

Install and usage instructions live in the source repository linked above.