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 subscription-based API platform enforces two behaviors that currently have no test coverage:
1. Subscription expiry logic: Subscriptions become inactive exactly 30 days after activation. The Subscription model has an #expired? instance method that returns true when more than 30 days have passed since activated_at and false otherwise. The edge case at exactly 30 days needs to be clearly tested.
2. Subscription-gated endpoints: Three API endpoints — GET /api/v1/reports, POST /api/v1/exports, and GET /api/v1/analytics — all require an active subscription. A user without one receives a 403 Forbidden response. A user with a valid subscription can access the endpoint normally. All three endpoints share this identical authorization behaviour.
You have been brought in to write spec coverage for both concerns. The team cares that the test suite is maintainable — repeated assertion patterns should be structured in a way that avoids duplication across the three endpoint specs.
Note: This project does NOT use test-prof.
Produce spec files covering:
Subscription#expired? model behavior (correct expiry at the 30-day boundary, both sides)Place files at appropriate paths. The model and endpoint specs should each be in their own files. Any supporting spec infrastructure (shared behavior definitions) should be placed in a spec/support/ file. Do not create a full Rails app — just the spec files with realistic, well-structured 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