alexandrbasis Architecture Language
Shared vocabulary for architectural reasoning. Prefer these terms when the distinction is
material, but preserve the target project's established domain and technical names; do
not rename existing service, API, component or boundary identifiers merely to
match this glossary.
The full glossary lives in LANGUAGE.md. Load it when:
- Reviewing architecture (
senior-architecture-reviewer,code-analysis) - Hunting deepening opportunities (
improve-codebase-architecture) - Designing interfaces or evaluating module shape
- TDD planning where module depth affects test surface
Why this exists
A codebase full of shallow modules is hard for both humans and AI to navigate. The vocabulary in LANGUAGE.md makes the distinction between deep and shallow sayable, which is the prerequisite for fixing it.
When reviewing or planning, use the precise term when it clarifies the architectural relationship — for example seam, interface, or adapter — while keeping the project's existing terminology in code and task artifacts.
When the architectural conversation advances a task, resolve its durable record through
../setup/references/task-context.md and link decisions there. A standalone vocabulary
lookup does not create a task artifact.
Upstream
The vocabulary and principles are adapted from Matt Pocock's improve-codebase-architecture/LANGUAGE.md (github.com/mattpocock/skills), which itself draws on Ousterhout (A Philosophy of Software Design) and Feathers (Working Effectively with Legacy Code).