CtrlK
BlogDocsLog inGet started
Tessl Logo

igmarin/rails-agent-skills

Curated library of AI agent skills for Ruby on Rails development. Covers code review, architecture, security, testing (RSpec), engines, service objects, DDD patterns, and workflow automation.

98

1.38x
Quality

99%

Does it follow best practices?

Impact

98%

1.38x

Average score across 26 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

SKILL.mdddd-ubiquitous-language/

name:
ddd-ubiquitous-language
description:
Use when a Ruby on Rails feature, bug, or architecture discussion has fuzzy business terminology and you need shared vocabulary. Identifies canonical terms, resolves naming conflicts, maps synonyms to one concept, and generates a glossary for Rails-first workflows. Trigger words: DDD, shared vocabulary, define terms, bounded context naming, what should we call this, terminology alignment, DDD glossary, naming inconsistency.

DDD Ubiquitous Language

Use this skill when the domain language is fuzzy, overloaded, or inconsistent.

Core principle: Agree on business language before choosing models, services, or boundaries.

Quick Reference

TopicRule
Canonical termPick one business term for one concept
SynonymsCapture them, then choose one preferred term
Overloaded wordsFlag them early; split meanings explicitly
NamingPrefer business meaning over technical shorthand
OutputReturn a usable glossary, not abstract theory

HARD-GATE

DO NOT introduce DDD terminology without grounding it in the user's real domain language.
DO NOT rename code concepts until the glossary is explicit enough to justify the change.
ALWAYS flag overloaded or conflicting terms before recommending modeling changes.

When to Use

  • The user uses multiple words for what might be the same business concept.
  • A feature or bug discussion is blocked by unclear naming.
  • You need a glossary before doing boundary review or Rails modeling.
  • Next step: Chain to ddd-boundaries-review when the glossary reveals multiple contexts, or to ddd-rails-modeling when the main problem is tactical modeling in Rails.

Process

  1. Collect terms: Pull candidate nouns, roles, states, events, and actions from the request, PRD, tickets, existing docs, and code names. In a Rails codebase, scan class and file names across layers: 
    grep -rh "^class \|^module " app/models app/controllers app/services --include="*.rb" | sort
  2. Group synonyms: Identify words that appear to mean the same thing and words that are overloaded across multiple meanings.
  3. Choose canonical terms: Prefer the clearest business term; keep aliases only as migration notes or search hints.
  4. Define each term: Write one short definition, expected invariants, and related concepts.
  5. Flag ambiguity: List terms that need user confirmation or that likely indicate multiple bounded contexts.
  6. Hand off: Continue with ddd-boundaries-review, ddd-rails-modeling, or create-prd / generate-tasks depending on the workflow stage.

Output Style

When using this skill, return:

  1. Canonical term
  2. Aliases / conflicting words
  3. Definition
  4. Key invariant or business rule
  5. Likely related context
  6. Open questions

Example — Naming Inconsistency in a Rails App

A Rails app has Booking (model), ReservationsController, and HoldService all referring to the same concept. The resulting glossary resolves it:

Canonical termAliasesDefinitionInvariantContext
ReservationBooking, HoldA customer claim on an inventory slot for a future dateMust expire or be confirmed within 24hFleet Booking

Once the glossary is agreed, rename code toward the canonical term incrementally — do not rename all 50 call sites in one PR.

Common Mistakes

MistakeReality
Keeping every synonym alive foreverPick one preferred business term or the codebase stays muddy
Using technical class names as domain truthDomain language comes from the business, not from current code accidents
Jumping to aggregates before agreeing on wordsOverloaded terms produce bad boundaries and bad models
One term meaning different things in different screensFlag it early — it usually signals multiple bounded contexts

Integration

SkillWhen to chain
create-prdWhen a PRD needs cleaner business language before approval
ddd-boundaries-reviewWhen the glossary suggests multiple bounded contexts or language leakage
ddd-rails-modelingWhen the terms are clear enough to decide entities, value objects, and services
rails-architecture-reviewWhen naming confusion already appears in the code structure

ddd-ubiquitous-language

SKILL.md

README.md

tile.json