Curated library of 39 AI agent skills for Ruby on Rails development. Organized by category: planning, testing, code-quality, ddd, engines, infrastructure, api, patterns, context, orchestration, and workflows. Includes 5 callable workflow skills (rails-tdd-loop, rails-review-flow, rails-setup-flow, rails-quality-flow, rails-engines-flow) for complete development cycles. Covers code review, architecture, security, testing (RSpec), engines, service objects, DDD patterns, and TDD automation.
95
98%
Does it follow best practices?
Impact
95%
1.20xAverage score across 35 eval scenarios
Passed
No known issues
Use this skill when documenting Ruby classes and public methods with YARD.
Core principle: Every public class and public method has YARD documentation so the contract is clear and tooling can generate API docs.
After any feature or fix that adds or changes public Ruby API (classes, modules, public methods):
1. Add or update YARD on those surfaces before the work is considered done.
2. All YARD text must be in English unless user explicitly requests otherwise.
Task lists from generate-tasks MUST include explicit YARD sub-tasks after implementation.Canonical examples for common tags: EXAMPLES.md — includes @param, @return, and @raise tag usage.
| Scope | Rule |
|---|---|
| Classes | One-line summary; optional @since if version matters |
| Public methods | All tags required unless explicitly inapplicable: @param, @option (for hash params), @return, @raise |
Public initialize | Add @param for constructor inputs when initialization is part of the public contract |
| Private methods | Document only if behavior is non-obvious; same tag rules |
# Responsible for validating and executing animal transfers between shelters.
# @since 1.2.0
module AnimalTransfers
class TransferServiceUse @option for every valid key in hash params. Include at least one @example on .call or the main public entry point.
# Performs the transfer and returns a standardized response.
# @param params [Hash] Transfer parameters
# @option params [Hash] :source_shelter Shelter hash with :shelter_id
# @option params [Hash] :target_shelter Target shelter with :shelter_id
# @return [Hash] Result with :success and :response keys
# @example Basic usage
# result = TransferService.call(source_shelter: { shelter_id: 1 }, target_shelter: { shelter_id: 2 })
# result[:success] # => true
def self.call(params)Document @raise for every exception a method can raise — even if the method rescues it internally. One tag per exception class.
# Processes the billing update for the given plan.
# @param plan_id [Integer] ID of the target plan
# @raise [InvalidPlanError] when the plan does not exist or is inactive
# @raise [PaymentGatewayError] when the payment provider rejects the charge
# @return [Hash] Result with :success and :response keys
def self.call(plan_id:)# Validates source and target shelters and returns the first validation error.
# @param source_id [Integer] Source shelter ID
# @param target_id [Integer] Target shelter ID
# @return [nil, String] nil if valid, error message otherwise
def self.validate_shelters!(source_id, target_id)# Updates billing. (Too vague; no @param/@return/@raise)
def self.call(plan_id:)| Pitfall | What to do |
|---|---|
| Documenting only the class, not public methods | Callers need param types and return shape for every public method |
Skipping @option for hash params | Without it, consumers don't know valid keys or types |
Only one @raise for multiple exceptions | List EVERY exception type — one @raise per class, even if rescued internally |
| YARD text in a language other than English | Write in English unless the user explicitly requests otherwise |
YARD documents the contract; tagged notes (TODO: / FIXME: / HACK: / NOTE: / OPTIMIZE:) document the why on the same code. Every tag carries actionable context (owner, ticket, next step); naked tags fail review. See references/tagged-notes.md and rails-code-conventions.
Run validation before considering documentation complete:
yard stats --list-undocyard docFor advanced tags (@abstract, @deprecated, @api private, @yield, @overload) see ADVANCED_TAGS.md.
| Skill | When to chain |
|---|---|
| ruby-service-objects | Implementing or documenting service objects |
| ruby-api-client-integration | Documenting API client layers (Auth, Client, Fetcher, Builder) |
| rails-engine-docs | Documenting engine public API or extension points |
| rails-code-review | Reviewing that public interfaces are documented |
| generate-tasks | Generated task lists include YARD tasks after implementation |
docs
evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
scenario-8
scenario-9
scenario-10
scenario-11
scenario-12
scenario-13
scenario-14
scenario-15
scenario-16
scenario-17
scenario-18
scenario-19
scenario-20
scenario-21
scenario-22
scenario-23
scenario-24
scenario-25
scenario-26
scenario-27
scenario-28
scenario-29
scenario-30
scenario-31
scenario-32
scenario-33
scenario-34
scenario-35
mcp_server
skills
api
api-rest-collection
rails-graphql-best-practices
code-quality
rails-architecture-review
rails-code-conventions
rails-code-review
rails-review-response
rails-security-review
rails-stack-conventions
assets
snippets
refactor-safely
context
rails-context-engineering
rails-project-onboarding
ddd
ddd-boundaries-review
ddd-rails-modeling
ddd-ubiquitous-language
engines
rails-engine-compatibility
rails-engine-docs
rails-engine-extraction
rails-engine-installers
rails-engine-release
rails-engine-reviewer
rails-engine-testing
infrastructure
rails-api-versioning
rails-background-jobs
rails-database-seeding
rails-frontend-hotwire
rails-migration-safety
rails-performance-optimization
orchestration
rails-skills-orchestrator
patterns
ruby-service-objects
strategy-factory-null-calculator
yard-documentation
planning
create-prd
generate-tasks
ticket-planning
testing
rails-bug-triage
rails-tdd-slices
rspec-best-practices
rspec-service-testing