architecture-language

Standardize architectural vocabulary across codebases using LANGUAGE.md terms.

12|2|Updated Nov 20, 2025
One-click install
npx skills add https://github.com/alexandrbasis/claudops --skill architecture-language
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: architecture-language
Source: https://github.com/alexandrbasis/claudops/tree/main/.claude/skills/architecture-language
Command: npx skills add https://github.com/alexandrbasis/claudops --skill architecture-language

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Shared vocabulary for every architectural suggestion in this repo. Use these terms exactly — don't substitute "component", "service", "API", or "boundary". Consistent language is the point.

Core Features & Use Cases

  • Canonical terms for architecture discussion (Module, Interface, Implementation, Depth, Seam, Adapter, Leverage, Locality).
  • Clear guidance on terminology to improve communication during reviews, planning, and refactoring.
  • Reference: the canonical glossary lives in LANGUAGE.md and aligns with upstream sources.

Quick Start

Load the LANGUAGE.md vocabulary into your architecture review workflow.

Frequently Asked Questions about architecture-language

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I standardize architecture vocabulary across my codebase?

Standardize architecture vocabulary by applying canonical terms like Module, Interface, and Seam during reviews and planning. This ensures consistent communication across the team by referencing a shared glossary.

What is an architectural seam and when do I need it?

An architectural seam is a canonical vocabulary term defining a boundary where modules interact. You need it during architecture reviews and refactoring to align team terminology and clarify structural boundaries.

Why use canonical architecture terms instead of generic words like component or service?

Canonical architecture terms prevent ambiguity during design sessions. Using generic substitutes like component or service breaks consistent communication, whereas defined terms like Module, Interface, and Adapter align team understanding.

How do I align team terminology for architecture reviews?

Align team terminology by loading canonical vocabulary terms into your architecture review workflow. This defines relationships and guidance for consistent communication, referencing a shared markdown glossary as the source.

Can I substitute generic terms like boundary or API during architecture planning?

No, substituting generic terms like boundary or API defeats the purpose of a shared vocabulary. You must use canonical terms exactly to maintain consistent language during architecture planning and design discussions.

Do I need a markdown glossary to standardize module and interface definitions?

Yes, a markdown glossary serves as the canonical source for standardizing module and interface definitions. It defines architectural terms and relationships to guide consistent communication across codebases.