ddd-ubiquitous-language
Use when a Ruby on Rails feature, bug, or architecture discussion has fuzzy business terminology and you need a Domain-Driven Design ubiquitous language. Covers canonical terms, synonyms, overloaded words, naming conflicts, and glossary output for Rails-first workflows.
78
72%
Does it follow best practices?
Impact
Pending
No eval scenarios have been run
Passed
No known issues
Optimize this skill with Tessl
npx tessl skill review --optimize ./ddd-ubiquitous-language/SKILL.mdQuality
Discovery
75%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
The description has strong completeness with an explicit 'Use when' clause and a clearly distinctive niche combining DDD and Rails. However, it could be more specific about the concrete actions performed (it lists concepts rather than verbs/actions) and could include more natural trigger terms that users would actually say when needing this skill.
Suggestions
Rewrite the capability list using action verbs: e.g., 'Identifies canonical terms, resolves naming conflicts, maps synonyms to a single concept, and generates a glossary document' instead of just listing nouns.
Add more natural trigger term variations users might say, such as 'DDD,' 'shared vocabulary,' 'bounded context naming,' 'what should we call this model,' or 'terminology alignment.'
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | The description names the domain (DDD ubiquitous language for Rails) and mentions some outputs like 'canonical terms, synonyms, overloaded words, naming conflicts, and glossary output,' but these read more like a list of concepts than concrete actions the skill performs (e.g., 'generates a glossary,' 'resolves naming conflicts'). | 2 / 3 |
Completeness | The description explicitly answers both 'what' (covers canonical terms, synonyms, overloaded words, naming conflicts, glossary output for Rails workflows) and 'when' (when a Rails feature/bug/architecture discussion has fuzzy business terminology and you need a DDD ubiquitous language). | 3 / 3 |
Trigger Term Quality | Includes relevant terms like 'Domain-Driven Design,' 'ubiquitous language,' 'Rails,' 'glossary,' and 'naming conflicts,' but misses common user phrasings like 'define terms,' 'shared vocabulary,' 'bounded context,' 'what should we call this,' or simpler triggers like 'DDD glossary.' | 2 / 3 |
Distinctiveness Conflict Risk | The combination of DDD ubiquitous language + Ruby on Rails + fuzzy business terminology creates a very specific niche that is unlikely to conflict with other skills. The triggers are narrow and well-scoped. | 3 / 3 |
Total | 10 / 12 Passed |
Implementation
70%Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
This is a well-structured skill for establishing DDD ubiquitous language in Rails contexts. Its strengths are clear workflow sequencing, good output format specification with a concrete example, and well-signaled integration points. Its main weakness is that actionability could be improved with Rails-specific concrete examples (e.g., showing how to extract terms from a Rails codebase or a before/after glossary from a real-ish domain), and some content is mildly redundant.
Suggestions
Add a concrete Rails-specific example showing the full process: e.g., given a set of models/controllers with inconsistent naming, show the resulting glossary table with real-ish domain terms.
Consolidate 'Common Mistakes' and 'Red Flags' into a single section to reduce redundancy and improve conciseness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Generally efficient but includes some sections that could be tightened. The 'Common Mistakes' and 'Red Flags' sections overlap conceptually, and some table entries explain things Claude would already understand (e.g., 'Bad language produces bad boundaries and bad models'). The quick reference table is lean, but overall there's mild redundancy. | 2 / 3 |
Actionability | The process steps are clear and the output format is well-specified with a concrete table example, which is good. However, there's no executable code or concrete Rails-specific commands/examples. The guidance is more procedural than copy-paste ready—step 1 says 'Pull candidate nouns' but doesn't show how to do this concretely in a Rails codebase (e.g., grepping models, reading schema). | 2 / 3 |
Workflow Clarity | The 6-step process is clearly sequenced and logically ordered (collect → group → choose → define → flag → hand off). The HARD-GATE section provides explicit validation constraints (don't rename until glossary justifies it, flag overloaded terms before modeling). The hand-off step and integration table provide clear next-step guidance. For a non-destructive analytical skill, this level of workflow clarity is appropriate. | 3 / 3 |
Progressive Disclosure | Content is well-organized into clearly labeled sections (Quick Reference, When to Use, Process, Output Style, Common Mistakes, Red Flags, Integration). The integration table provides clear one-level-deep references to related skills with explicit chaining conditions. For a skill of this size and scope, the structure is appropriate and navigable. | 3 / 3 |
Total | 10 / 12 Passed |
Validation
100%Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.
Validation — 11 / 11 Passed
Validation for skill structure
No warnings or errors.
- Repository
- igmarin/rails-agent-skills
- Commit
ae8ea63
- Reviewed
Table of Contents
Is this your skill?
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.