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
A B2B SaaS platform has a multi-step user onboarding flow that was originally written as a single 200-line controller action. The flow involves: creating the user account, setting up the workspace, assigning a default billing plan, and sending a welcome email notification. The team is now refactoring this into a proper service layer. The current controller action mixes HTTP concerns (checking request.format, calling render json:) directly into the business logic, which has made testing painful.
The team wants a clean service layer where each step is independently testable, the overall flow is easy to understand, and no service class is responsible for producing HTTP responses. The onboarding service will be called from both the web controller and a future REST API endpoint, so it must work identically regardless of calling context.
Your task is to write the Ruby service layer for this onboarding flow. Design it so the main orchestrator coordinates the individual steps without implementing all the details inline. The individual steps (user creation, workspace setup, billing assignment, and notification) should be separate concerns.
Produce the following files:
app/services/<module>/onboarding_service.rb — the main orchestratorspec/services/<mirrored_path>/onboarding_service_spec.rb — specs covering successful onboarding and at least one failure scenarioDo not build a full Rails app. Use stub method bodies with comments (e.g. # TODO: User.create!(...)) so the architecture and boundaries can be reviewed without a running application. The focus is on the service structure, delegation pattern, and return value contracts.
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