Curated library of AI agent skills for Ruby on Rails development. Covers code review, architecture, security, testing (RSpec), engines, service objects, DDD patterns, and workflow automation.
98
99%
Does it follow best practices?
Impact
98%
1.38xAverage score across 26 eval scenarios
Passed
No known issues
Use this skill when a bug report exists but the right reproduction path and fix sequence are not yet clear.
Core principle: Do not guess at fixes. Reproduce the bug, choose the right failing spec, then plan the smallest safe repair.
rails-tdd-slices -> rspec-best-practices -> implementation skill.Return findings in this shape:
Example (wrong status code bug):
1. Observed: POST /orders returns 500 when product is out of stock
2. Expected: Returns 422 with { error: "Out of stock" }
3. Boundary: Request layer — visible in HTTP contract
4. First spec: spec/requests/orders/create_spec.rb
5. Fix path: Orders::CreateOrder should return { success: false, error: "Out of stock" }
when inventory check fails; controller renders 422
6. Next: rails-tdd-slices → write request spec → rspec-best-practices → fixSkeleton failing spec:
# spec/requests/orders/create_spec.rb
RSpec.describe "POST /orders", type: :request do
context "when product is out of stock" do
let(:product) { create(:product, stock: 0) }
it "returns 422 with an error message" do
post orders_path, params: { order: { product_id: product.id, quantity: 1 } }, as: :json
expect(response).to have_http_status(:unprocessable_entity)
expect(response.parsed_body["error"]).to eq("Out of stock")
end
end
endRun it before implementing the fix: bundle exec rspec spec/requests/orders/create_spec.rb
See BOUNDARY_GUIDE.md for the full bug-shape → spec-type mapping and layer diagnosis tips.
Quick reference:
| Bug shape | Likely first spec |
|---|---|
| HTTP symptoms (status, JSON, redirect) | Request spec |
| Data symptoms (wrong value, validation) | Model or service spec |
| Timing symptoms (missing job, email) | Job spec |
| Engine routing/generator regression | Engine spec in dummy app |
| Pitfall | What to do |
|---|---|
| Unit spec when the bug is visible at request level | Start where the failure is actually observed |
| Bundling reproduction, refactor, and new features | Fix the bug in the smallest safe slice only |
| Flaky evidence treated as green light to patch | Stabilize reproduction before touching code |
| The explanation relies on "probably" or "maybe" | Ambiguity means the reproduction step isn't done yet |
| Skill | When to chain |
|---|---|
| rails-tdd-slices | To choose the strongest first failing spec for the bug |
| rspec-best-practices | To run the TDD loop correctly after the spec is chosen |
| refactor-safely | When the bug sits inside a risky refactor area and behavior must be preserved first |
| rails-code-review | To review the final bug fix for regressions and missing coverage |
| rails-architecture-review | When the bug points to a deeper boundary or orchestration problem |
api-rest-collection
create-prd
ddd-boundaries-review
ddd-rails-modeling
ddd-ubiquitous-language
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
generate-tasks
mcp_server
rails-architecture-review
rails-background-jobs
rails-bug-triage
rails-code-conventions
rails-code-review
rails-engine-compatibility
rails-engine-docs
rails-engine-extraction
rails-engine-installers
rails-engine-release
rails-engine-reviewer
rails-engine-testing
rails-graphql-best-practices
rails-migration-safety
rails-review-response
rails-security-review
rails-skills-orchestrator
rails-stack-conventions
rails-tdd-slices
refactor-safely
rspec-best-practices
rspec-service-testing
ruby-service-objects
strategy-factory-null-calculator
ticket-planning
yard-documentation