linguistic-boundary-verifier

Detect ubiquitous language leakage across bounded context boundaries in modular systems.

40|39|Updated Apr 1, 2026
One-click install
npx skills add https://github.com/Architekt-Jutra/architekt-jutra-code --skill linguistic-boundary-verifier
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: linguistic-boundary-verifier
Source: https://github.com/Architekt-Jutra/architekt-jutra-code/tree/main/week10/linguistic-boundary-verifier
Command: npx skills add https://github.com/Architekt-Jutra/architekt-jutra-code --skill linguistic-boundary-verifier

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill solves the problem of ubiquitous language leaking across bounded context boundaries in modular software systems, which creates hidden coupling between modules that should be independent. Standard architectural dependency tools miss these leaks because they often take the form of string literals, event language, or misdirected API calls that do not show up in import graphs.

Core Features & Use Cases

  • Boundary Violation Detection: Analyzes language.md files to map module relationships and vocabulary, then scans code for foreign terms, reversed event flow, and wrong-direction API calls.
  • Type-Specific Fix Proposals: Suggests targeted fixes for each violation type: behavior generalization for string leaks, ACL translation for event leaks, and dependency inversion for misdirected API calls.
  • Visual Reporting: Generates clear before/after ASCII diagrams for each violation to make problems and fixes immediately understandable, plus a full boundary report artifact.
  • Use Cases: Use for architectural reviews of multi-module changes, single-module PR checks for new concept consistency, quarterly architecture health checks, and post-refactoring boundary validation.

Quick Start

Invoke the linguistic-boundary-verifier skill with your module names to scan for language leakage across bounded context boundaries and receive a report with proposed fixes and visual diagrams.

Frequently Asked Questions about linguistic-boundary-verifier

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

FAQPage Schema
How do I detect ubiquitous language leakage across bounded contexts in microservices?

To detect ubiquitous language leakage across bounded contexts, you need to scan module code for foreign string literals, reversed event flows, and misdirected API calls. This process maps module vocabulary using language.md files to identify hidden coupling that standard dependency tools miss.

Why does standard architecture review miss coupling between DDD bounded contexts?

Standard architecture review misses coupling between DDD bounded contexts because ubiquitous language leakage often takes the form of foreign string literals, event language, or misdirected API calls that do not appear in import graphs. Dedicated linguistic analysis is required to catch these hidden dependencies.

How do I fix language leakage when a module uses foreign string literals from another bounded context?

To fix language leakage from foreign string literals, you should apply behavior generalization to abstract the specific foreign terms. This restores proper linguistic isolation by ensuring the module relies on generalized behaviors rather than external vocabulary.

Can I check a single microservice pull request for bounded context consistency?

Yes, you can check a single microservice pull request for bounded context consistency by auditing the module's language.md file. This verifies that new code changes align with the module's defined ubiquitous language and do not introduce foreign concepts.

What is the best way to prevent reversed event language flow in a modular software system?

The best way to prevent reversed event language flow in a modular software system is to implement ACL translation. This translates external event vocabulary into the local ubiquitous language, ensuring proper linguistic isolation and preventing hidden coupling at integration points.

When do I need dependency inversion to fix misdirected API calls between bounded contexts?

You need dependency inversion to fix misdirected API calls between bounded contexts when a module directly invokes another module's API using foreign vocabulary. Dependency inversion restores proper linguistic isolation by reversing the dependency direction and abstracting the integration points.