Vanilla Rails as Default Architecture for AI Agents

Where this fits

You're building a Rails feature with an AI coding agent. The agent proposes a UserNotifierService, an Interactor for a simple update action, and a custom query object for a scope that already exists. You feel the codebase drifting toward ceremony. This skill makes the agent stop and reconsider: use Vanilla Rails — thin controllers, rich models, and no layer unless genuinely justified. It loads automatically when the agent touches controllers, models, routes, or anywhere business logic might land, so you avoid having to constantly correct architectural drift.

Why agents benefit

• Applies the default proactively – The skill triggers on file edits and design decisions, not just when you say "vanilla rails." It steers the agent toward the simple path without prompting.
• Prevents over-engineering – When extracting a service or form object, the skill checks whether it's truly necessary. It can veto an unnecessary layer and inlines the logic into the model or controller instead.
• Keeps Rails conventions intact – It knows when a custom action is better than a nested resource, and guides the agent to use standard Rails routing and RESTful patterns.
• Enforces thin controllers – The skill reminds the agent to delegate to model methods, keeping controllers readable and testable.
• Useful for reviews – It can analyze existing code and suggest simplifications, making it a valuable pair for refactoring sessions.

Practical scenarios

Adding a custom action to a controller

An agent is asked to implement "mark as read" for a message. Instead of adding a MessagesController#custom_action with a service object, the skill guides it to add member do in routes and a mark_as_read! method on the model. The controller stays two lines, the logic lives where it belongs.

Deciding where business logic lives

When the agent needs to send a welcome email after user creation, the skill prevents creating a WelcomeMailerService. It suggests either a model callback (if simple) or calling UserMailer.welcome(user).deliver_later directly from the controller. No extra layer needed.

Extracting a form object

For a complex signup form with multiple models, the agent might normally jump to an Interactor. The skill evaluates: is this genuinely complex enough? If not, it suggests using accepts_nested_attributes_for or a simple FormObject only when the complexity is real, keeping the architecture lean.

Add it to your agent workflow

Install the skill using the skills CLI:

npx skills add iuhoay/skills --skill vanilla-rails

After installation, the skill activates automatically. For example, when you open a Rails controller and start typing a new action, the agent will suggest a model method instead of a service object. You can also invoke it explicitly in a prompt: "Review this Rails code with vanilla-rails in mind."

Compare before adopting

Before committing to this skill, compare it with alternatives:

• Quality signals – Check if the skill covers the exact Rails patterns you care about (e.g., ActiveRecord callbacks, custom actions vs. nested resources).
• Maintenance freshness – Verify the GitHub repo is active and aligned with current Rails versions.
• Alternatives – Other skills might focus on strict DDD or service-oriented architecture; this one is opinionated toward simplicity.
• Workflow fit – Ensure it doesn't conflict with your team's existing architecture standards. It works best if you already endorse the 37signals philosophy.

Why it is worth tracking

With 52 stars and a focused README, this skill targets a real pain point: AI agents default to over-engineering. The 37signals philosophy is well-documented and battle-tested in Basecamp itself, so the skill's guidance is credible. Track it if you're building Rails apps with agents and want consistent, maintainable code. Evaluate it early — it's a small, opinionated skill that can save hours of refactoring later. See more details on the OpenAgentSkill page to decide if it fits your stack.