DonchitosandClaude Opus 5.5
be8993bbc5
Fix release for 1.1.2: the 14 longest skills keep their later phases after a compaction, a question nobody answered is never taken as an answer, settings read the same from a subfolder, the commit check works for a project in a subfolder of a larger repository, every skill opens with a title, and the shipped allow rules no longer approve deleting a branch or writing files without asking. Details in CHANGELOG.md; upgrade steps in UPGRADING.md (v1.1.2 → v1.1.3). Refs #83 Refs #133 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0185en4t76fPn7315q4c3nko
2.7 KiB
/architecture-review — Phase 2: Extract Technical Requirements
Part of
/architecture-review.SKILL.mdnames when to read this file; the settings it resolved and the rules under its later headings still apply here.
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:
- Exact/near match to an existing registry entry for the same system →
reuse that entry's TR-ID unchanged. Update the
requirementtext in the registry only if the GDD wording changed (same intent, clearer phrasing) — add arevised: [date]field. - No match → assign a new ID: next available
TR-[system]-NNNfor that system, starting from the highest existing sequence + 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.