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
Core principle: Every API surface (Rails app or engine) has a single API collection file that stays in sync with its endpoints.
| Aspect | Rule |
|---|---|
| When | Create or update collection when creating or modifying any REST API endpoint (route + controller action) |
| Format | Postman Collection JSON v2.1 (schema or info.schema references v2.1) is a good default standard |
| Location | One file per app or engine — docs/api-collections/<app-or-engine-name>.json or spec/fixtures/api-collections/; if a collection folder already exists, update the existing file |
| Language | All request names, descriptions, and variable names must be in English |
| Variables | Use {{base_url}} (or equivalent) for the base URL so the collection works across environments |
| Per request | method, URL (with variables for base URL), headers (Content-Type, Authorization if needed), body example when applicable |
| Validation | See validation steps in the HARD-GATE section below |
When you create or modify a REST API endpoint (new or changed route and controller action),
you MUST also create or update the corresponding API collection file so the
flow can be tested. Do not leave the collection missing or outdated.
EXCEPTION: GraphQL endpoints — use rails-graphql-best-practices instead.After generating or updating the collection, validate the output:
{{base_url}} (or equivalent) is used consistently.Minimum per request — method, url with {{base_url}}, headers, body for POST/PUT:
{
"name": "Create order",
"request": {
"method": "POST",
"header": [{ "key": "Content-Type", "value": "application/json" }],
"url": "{{base_url}}/orders",
"body": { "mode": "raw", "raw": "{\"product_id\": 1}" }
}
}See EXAMPLES.md for a multi-endpoint collection with auth token variables.
| Mistake | Reality |
|---|---|
| Missing Content-Type or body for POST/PUT | Include headers and example body so the request works out of the box |
| Skipping validation after generation | Always verify the JSON is well-formed and imports correctly before committing (see HARD-GATE) |
| Skill | When to chain |
|---|---|
| rails-engine-author | When the engine exposes HTTP endpoints |
| rails-engine-docs | When documenting engine API or how to test endpoints |
| rails-code-review | When reviewing API changes (ensure collection was updated) |
| rails-engine-testing | When adding request/routing specs (collection can mirror those flows) |
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