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 fitness app allows users to upgrade their membership from Standard to Premium tier. The upgrade process involves validating the user's account status, applying the new tier to their profile, and recording the tier change in an audit log. The backend team has no existing service object for this — the feature needs to be built from scratch. There are no existing tests covering this area of the codebase.
Your task is to implement the Memberships::UpgradeService service object. Your tech lead has asked you to maintain a detailed process_log.md file that documents your development process chronologically as you work through the implementation — capturing what you produced at each stage, what you expected to happen at each point, and how your thinking evolved before you committed to writing any business logic.
Produce the following files:
process_log.md — A chronological record of your development process. Include clearly labelled sections for each phase of work. For each phase: describe what artifact you worked on, explain your reasoning for the order in which things were produced, note what you anticipated would happen before the business logic existed, and document any design decisions you locked down before writing the implementation code.spec/services/memberships/upgrade_service_spec.rb — RSpec spec for the service covering the success path and at least two failure casesapp/services/memberships/upgrade_service.rb — The service implementationThe service should accept user_id: and tier: keyword parameters and return a structured result hash. Use # TODO: comments where you would normally call real database or external integrations (e.g. # TODO: fetch user from database). Do not create a full Rails app — just the service and spec files with realistic structure and content.
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