Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add mattwynne/yaks --skill ubiquitous-languagegit clone --depth 1 https://github.com/mattwynne/yaksWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/mattwynne/yaks/ubiquitous-language)<a href="https://agentmods.dev/skills/mattwynne/yaks/ubiquitous-language"><img src="https://agentmods.dev/badge/skills/mattwynne/yaks/ubiquitous-language/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/mattwynne/yaks/ubiquitous-language"><img src="https://agentmods.dev/badge/skills/mattwynne/yaks/ubiquitous-language.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00037 | $0.02578 |
| Opus 5 | $0.00018 | $0.01289 |
| Sonnet 5 | $0.00007 | $0.00516 |
| Haiku 4.5 | $0.00004 | $0.00258 |
Grade A, and why
ubiquitous-language scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 12d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 306 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Ubiquitous Language Review
Overview
The ubiquitous language is the shared vocabulary a team uses for domain concepts — in conversation, code, tests, and docs. When the language is consistent, the code communicates clearly. When it drifts, misunderstandings hide in plain sight.
This skill produces a docs/terms.md glossary and a
commentary on the health of the language.
When to Use
- Onboarding to a codebase — to understand the domain
- After significant refactoring or feature work
- When naming debates keep recurring
- When new team members are confused by terms
- Periodically, as a hygiene check
Process
1. Harvest Terms
Scan the codebase for domain terms. Focus on these layers, in order of authority:
| Layer | Where to look | Why |
|---|---|---|
| Domain model | Domain types, enums, enum variants, struct fields, constants, naming conventions, validation rules | The core vocabulary — highest authority |
| Events | Event types and their payloads | Capture what happened in domain language |
| Commands / Use cases | Application layer, command handler | The verbs — what users can do |
| CLI surface | CLI commands, flags, help text | How users encounter the language |
| Feature files | See detailed guidance below | The richest source of natural-language domain terms |
| Other tests | Unit test names, integration test names | How developers talk about behaviour |
| Documentation | README, ADRs, design docs | How the team explains the system |
Reading Feature Files
Feature files deserve special attention. They are scenarios written in natural language — the closest thing to how the team talks about the domain. Read them carefully, extracting terms from:
- Rule names — these state business rules and often name domain distinctions that have no type in the code. A rule like "reserved fields cannot be overwritten" reveals the concept "reserved field" even though the code only has constants and a validation function.
- Scenario names — name specific instances and may reveal subcategories of a concept.
- Given/When/Then step phrasing — the steps are the ubiquitous language in sentence form. Terms that appear in steps but have no type in the code are candidates for missing abstractions.
- Feature-level descriptions — often name high-level concepts or provide context for why a group of rules exists.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 12d ago First seen · 306 lines · 37 tokens per session scan A 3c3f2c3765b2
ubiquitous-language is a skill published in the GitHub repository mattwynne/yaks (58 stars, last pushed 1mo ago), licensed MIT. It adds 37 tokens to every session and 2,578 once invoked, about $0.0002 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
coding
Use when five specialized coding agents (linter, perf, refactor, security, test) that enforce quality gates across the development lifecycle. From lint enforcement through performance profiling, refactoring, security auditing, and test coverage. Use when working with coding agents.
lavra-review
Perform exhaustive code reviews using multi-agent analysis and ultra-thinking.
lavra-eng-review
Engineering review -- parallel agents check architecture, simplicity, security, and performance.
improve-codebase-architecture
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.
receiving-code-review
Use when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performative agreement or blind implementation.
requesting-code-review
Use when completing tasks, implementing major features, or before merging to verify work meets requirements.