dhh-rails-style

Apply 37signals DHH Rails conventions to Ruby and Rails code.

12|2|Updated Jan 27, 2026
One-click install
npx skills add https://github.com/jikig-ai/soleur --skill dhh-rails-style-jikig-ai
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: dhh-rails-style
Source: https://github.com/jikig-ai/soleur/tree/main/plugins/soleur/skills/dhh-rails-style
Command: npx skills add https://github.com/jikig-ai/soleur --skill dhh-rails-style-jikig-ai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

Helps teams and engineers produce Ruby on Rails code that follows David Heinemeier Hansson's 37signals conventions so codebases remain RESTful, maintainable, and aligned with Hotwire-driven UX patterns.

Core Features & Use Cases

  • Opinionated architecture: promotes fat models, thin controllers, concerns for horizontal sharing, and state-as-records instead of boolean columns.
  • REST and routing guidance: maps verbs to noun resources, encourages shallow nesting and singular resources for one-per-parent semantics.
  • Frontend and interactivity: favors Turbo Streams and Stimulus controllers with native CSS patterns over heavy JS frameworks and Tailwind.
  • Testing and tooling: recommends Minitest with fixtures, database-backed queues/caches, and minimal external dependencies.
  • Use Case: review or refactor an existing Rails controller, model, or view to adopt DHH conventions and produce idiomatic, production-ready changes.

Quick Start

Ask the dhh-rails-style skill to review my Rails controller and refactor it to use RESTful resources, concerns, and Turbo responses where appropriate.

Frequently Asked Questions about dhh-rails-style

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I refactor Rails controllers to follow DHH and 37signals conventions?

To refactor Rails controllers in DHH style, enforce thin controllers by moving business logic to fat models, use concerns for horizontal sharing, and map actions to RESTful resources. This keeps controllers focused on routing and REST purity.

What is the recommended way to handle state in Rails models according to DHH conventions?

DHH conventions recommend using state-as-records instead of boolean columns for Rails models. This approach aligns with fat models and maintains data integrity by representing state transitions as actual database records.

Does the DHH Rails style use Hotwire and Turbo Streams for frontend interactivity?

Yes, DHH Rails style favors Hotwire patterns including Turbo Streams and Stimulus controllers with native CSS. It prioritizes these over heavy JavaScript frameworks to maintain a Rails-first implementation approach.

Can I use RSpec and Sidekiq when applying 37signals Rails conventions to my codebase?

37signals conventions recommend Minitest with fixtures and database-backed queues and caches. They favor minimal gem dependencies and Rails-first implementations, so replacing RSpec and Sidekiq aligns better with this style.

What's the best way to structure RESTful routing in a Rails app following 37signals style?

The best way to structure RESTful routing in 37signals style is mapping verbs to noun resources, encouraging shallow nesting, and using singular resources for one-per-parent semantics to maintain REST purity.