ddd-boundaries-review
Use when reviewing a Ruby on Rails app for Domain-Driven Design boundaries, bounded contexts, language leakage, cross-context orchestration, or unclear ownership. Covers context mapping, leakage detection, and smallest credible boundary improvements.
90
87%
Does it follow best practices?
Impact
91%
1.49xAverage score across 3 eval scenarios
Passed
No known issues
Quality
Discovery
89%Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.
This is a strong description that clearly defines when to use the skill with explicit trigger conditions and covers a distinctive niche (DDD review for Rails apps). The trigger terms are excellent and domain-appropriate. The main weakness is that the 'what it does' portion could be more concrete about specific actions and outputs rather than using somewhat abstract DDD terminology.
Suggestions
Add more concrete action verbs describing specific outputs, e.g., 'Identifies misplaced models, recommends module boundaries, produces context maps' to strengthen specificity.
| Dimension | Reasoning | Score |
|---|---|---|
Specificity | Names the domain (Ruby on Rails, DDD) and some actions like 'context mapping, leakage detection, and smallest credible boundary improvements,' but these are somewhat abstract rather than concrete step-by-step actions. It doesn't list specific outputs or deliverables clearly. | 2 / 3 |
Completeness | Explicitly answers both 'what' (reviews for DDD boundaries, covers context mapping, leakage detection, boundary improvements) and 'when' (starts with 'Use when reviewing a Ruby on Rails app for...' with clear trigger conditions). | 3 / 3 |
Trigger Term Quality | Includes strong natural keywords a user would say: 'Domain-Driven Design', 'bounded contexts', 'language leakage', 'cross-context orchestration', 'ownership', 'context mapping', 'Ruby on Rails'. These cover the natural vocabulary of someone seeking DDD review help. | 3 / 3 |
Distinctiveness Conflict Risk | Highly distinctive niche combining Ruby on Rails with Domain-Driven Design review. The specific DDD terminology (bounded contexts, language leakage, cross-context orchestration) makes it very unlikely to conflict with other skills. | 3 / 3 |
Total | 11 / 12 Passed |
Implementation
85%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, concise skill that clearly defines when and how to perform a DDD boundaries review in a Rails context. Its strengths are excellent organization, clear workflow sequencing, and appropriate scoping via hard-gates and integration pointers. The main weakness is that actionability could be improved with more concrete detection techniques (e.g., specific grep patterns, code analysis commands, or more detailed code examples showing how to identify leakage in practice).
Suggestions
Add concrete detection techniques such as grep/ripgrep patterns to find cross-context references (e.g., `rg 'Billing.*Fleet|Fleet.*Billing' app/` or searching for cross-namespace constant references).
Include a more complete before/after code example showing a leaked boundary and the smallest credible fix applied, making the output more copy-paste actionable.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Every section earns its place. No unnecessary explanations of what DDD is or how Rails works. Tables are compact, examples are minimal but illustrative, and the hard-gate constraints are terse and clear. | 3 / 3 |
Actionability | The review order provides a clear sequence of steps, and the output style section gives a concrete template for findings. However, the guidance is primarily instructional rather than executable—there are no concrete commands, grep patterns, or code snippets that Claude could use to actually detect leakage in a codebase. The Ruby examples illustrate findings but don't show how to discover them. | 2 / 3 |
Workflow Clarity | The 5-step review order is clearly sequenced and logically ordered (map → name → find leakage → check ownership → propose improvement). The hard-gate acts as a validation checkpoint preventing premature structural changes, and the output style section provides a structured template ensuring consistent deliverables. The 'smallest credible improvement' principle serves as a built-in constraint against destructive over-refactoring. | 3 / 3 |
Progressive Disclosure | Content is well-organized with a quick reference table up front, detailed sections below, and clear integration pointers to related skills (ddd-rails-modeling, refactor-safely, etc.) with explicit chaining conditions. The skill stays at the right level of abstraction for an overview without burying details in nested references. | 3 / 3 |
Total | 11 / 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.