Agent skill
rails-controller-patterns
Analyzes and recommends Rails controller patterns including RESTful design, strong parameters, before_actions, response handling, and routing. Use when building controllers, defining routes, handling params, or managing request/response flow. NOT for model validations, service object internals, view templates, or background job logic.
Install this agent skill to your Project
npx add-skill https://github.com/ag0os/rails-dev-plugin/tree/main/skills/rails-controller-patterns
SKILL.md
Rails Controller Patterns
Generate controllers following standard Rails RESTful conventions (7 actions, resourceful routing, before_actions, strong params).
Supporting Documentation
- patterns.md - Detailed controller patterns and examples
Core Principles
- Thin controllers: Handle HTTP concerns only; delegate business logic. Omakase: delegate to models and concerns. Service-oriented: delegate to service objects
- RESTful by default: Stick to 7 standard actions; create new resource controllers for custom actions
- Strong parameters always: Never trust user input; use
params.expect(Rails 8+) - Consistent responses:
redirect_toafter success,render :action, status:on failure - One resource per controller: Avoid multi-resource controllers
- Dedicated resource controllers: Prefer
Cards::ClosuresControlleroverpost :closeonCardsController
Strong Parameters: params.expect (Rails 8+)
params.expect replaces params.require().permit() with a cleaner, more secure API. Check Gemfile.lock for Rails version before using.
# Basic
params.expect(post: [:title, :content])
# Arrays
params.expect(post: [:title, tags: []])
# Nested attributes
params.expect(user: [:name, :email, profile_attributes: [:bio, :avatar]])
# Dynamic hash attributes
params.expect(product: [:name, :price, metadata: {}])
# Legacy syntax (Rails < 8)
params.require(:post).permit(:title, :content)
Dedicated Resource Controllers
Treat state changes as resources instead of adding custom member actions. This keeps controllers focused and RESTful.
# Bad - custom actions bloat the controller
resources :cards do
post :close
post :reopen
end
# Good - resource controllers
resources :cards do
scope module: :cards do
resource :closure # create = close, destroy = reopen
resource :pin # create = pin, destroy = unpin
end
end
Error Handling
class ApplicationController < ActionController::Base
rescue_from ActiveRecord::RecordNotFound, with: :not_found
rescue_from ActionPolicy::Unauthorized, with: :forbidden
private
def not_found
respond_to do |format|
format.html { render "errors/not_found", status: :not_found }
format.json { render json: { error: "Not found" }, status: :not_found }
end
end
def forbidden
respond_to do |format|
format.html { redirect_back fallback_location: root_path, alert: "Not authorized." }
format.json { render json: { error: "Forbidden" }, status: :forbidden }
end
end
end
Anti-Patterns
| Anti-Pattern | Problem | Fix |
|---|---|---|
| Fat controllers (50+ line actions) | Hard to test and maintain | Omakase: move logic to model methods/concerns. Service-oriented: extract to service objects |
| Business logic in controllers | Violates SRP | Omakase: move to models. Service-oriented: move to services |
Custom member actions (:close, :archive) |
Controller grows unbounded | Create dedicated resource controllers (Cards::ClosuresController) |
params.permit! |
Allows all params (mass assignment) | Use params.expect with explicit fields |
| Deeply nested routes (>1 level) | Confusing URLs and helpers | Use shallow: true or flat routes |
| Skipping authentication filters | Security vulnerability | Apply before_action broadly, skip selectively |
Multiple respond_to blocks |
Code duplication | Use respond_to once or separate API controllers |
Status Code Checklist
- Return
status: :unprocessable_entity(422) for validation failures - Return
status: :not_found(404) for missing records - Return
status: :forbidden(403) for authorization failures - Return
status: :see_other(303) forredirect_toafter DELETE - Use
rescue_fromin ApplicationController for consistent error responses
Output Format
When analyzing or creating controllers, provide:
- Controller file with proper structure and thin actions
- Route entries for
config/routes.rb - Before actions for auth, resource loading
- Strong params method with explicit field list
- Error handling strategy (rescue_from or inline)
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
rails-caching-patterns
Caching patterns for Rails applications including fragment caching, low-level caching, HTTP caching, Russian doll caching, and cache invalidation strategies. Automatically invoked when working with Rails.cache, cache stores, stale?/fresh_when, fragment caching, cache keys, or performance optimization through caching. Triggers on "cache", "caching", "Rails.cache", "fragment cache", "Russian doll", "stale?", "fresh_when", "cache key", "cache store", "Redis cache", "Solid Cache", "memcached", "ETag", "cache invalidation", "cache bust". NOT for CDN configuration (use rails-devops-patterns) or database query optimization (use rails-model-patterns).
rails-graphql-patterns
Analyzes and recommends GraphQL patterns for Rails using graphql-ruby including schema design, types, resolvers, mutations, subscriptions, DataLoader, and query complexity. Use when building GraphQL APIs, defining types, writing mutations, optimizing N+1 queries, or structuring app/graphql. NOT for REST API controllers, ActiveRecord queries outside GraphQL, or Turbo Stream responses.
ruby-object-design
Automatically invoked when making decisions about Ruby code structure and organization. Triggers on "class or module", "should this be a class", "struct vs class", "PORO", "data object", "design pattern", "class vs module", "when to use class", "module vs class", "stateless class", "value object", "data container", "object factory", "extend self", "singleton class". Provides guidance on choosing the right Ruby construct (class, module, Struct, Data, Hash). NOT for code smell identification or refactoring (use ruby-refactoring) or Rails-specific framework patterns.
rails-views-patterns
Analyzes Rails view templates, partials, layouts, helpers, and form patterns for best practices. Use when reviewing ERB templates, improving view performance with fragment caching, fixing form helpers, organizing partials, adding accessibility attributes, or evaluating collection rendering. NOT for Stimulus/Turbo logic (use hotwire-patterns), controller concerns, or API-only responses.
rails-architecture-patterns
Provides architectural planning, design decisions, and coordination guidance for Rails applications. Use when planning new features, choosing between design approaches (STI vs polymorphic, service vs concern, monolith vs engine), evaluating system architecture, or deciding which domain skill or agent to delegate to. NOT for implementation details within a single domain (use the domain-specific skill instead).
rails-mailer-patterns
Action Mailer patterns for Rails applications. Automatically invoked when working with email delivery, mailer classes, email templates, mailer previews, interceptors, or delivery configuration. Triggers on "mailer", "email", "ActionMailer", "deliver_later", "deliver_now", "mail template", "email preview", "SMTP", "SendGrid", "Postmark", "notification email". NOT for push notifications, SMS, or in-app messaging.
Didn't find tool you were looking for?