shared-language

Create a domain language glossary by generating a project CONTEXT.md file that centralizes terminology and definitions. This reduces miscommunication and onboarding friction by enforcing frontmatter-driven naming conventions.

Tracking architectural decisions is best done using Architecture Decision Records (ADRs) to log trade-offs, motivations, and context. This ensures traceability for future readers when significant architectural changes occur.

Update project documentation and ADRs at project initiation, when new terminology emerges, or when making significant architectural trade-offs. This ongoing update process keeps terminology aligned with actual project decisions.

Yes, applying this at project initiation establishes a shared domain language and records hard-to-reverse architectural decisions early. It enforces ADR formatting and frontmatter-driven naming to centralize context.

Maintaining a shared context glossary requires triggering updates to CONTEXT.md whenever terminology evolves or new constraints emerge. This ongoing process ensures traceability across the codebase and keeps definitions aligned.

Frontmatter-driven naming matters because it enforces consistent structural metadata across your CONTEXT.md glossary and ADRs. This consistency reduces miscommunication by standardizing how domain language and architectural decisions are recorded.