ce-dhh-rails-style

Applies 37signals DHH Rails conventions to Ruby and Rails code generation and review.

Updated Mar 17, 2026
One-click install
npx skills add https://github.com/Norfolk-Group/marcela-norfolk-ai --skill ce-dhh-rails-style-norfolk-group
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: ce-dhh-rails-style
Source: https://github.com/Norfolk-Group/marcela-norfolk-ai/tree/main/skills/compound-engineering/skills/ce-dhh-rails-style
Command: npx skills add https://github.com/Norfolk-Group/marcela-norfolk-ai --skill ce-dhh-rails-style-norfolk-group

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Writing idiomatic Rails code in the 37signals/DHH style requires deep knowledge of conventions like REST purity, fat models, state-as-records, and Hotwire patterns that are scattered across production codebases and hard to learn. ## Core Features & Use Cases - Style-Guided Code Generation: Write controllers, models, views, and tests following DHH conventions such as CRUD-only controllers, concerns, and Current attributes. - Code Review Against DHH Style: Review existing Ruby/Rails code against patterns extracted from 265 pull requests of the Fizzy codebase. - Architecture Guidance: Get patterns for routing, multi-tenancy, authentication, background jobs, caching, and gem selection (what to use vs avoid). - Use Case: When asked to add a "close card" feature, the skill produces a Cards::ClosuresController with a Card::Closure state record instead of a custom controller action with a boolean column. ## Quick Start Ask the assistant to write or review a Rails controller, model, or feature using DHH and 37signals style conventions.

Frequently Asked Questions about ce-dhh-rails-style

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

FAQPage Schema
How do I write Rails controllers in DHH style?

Map every action to CRUD on a resource by converting verbs into noun resources, such as POST /cards/:id/closure instead of a custom close action. Use controller concerns like CardScoped for shared behavior and respond with Turbo Streams for partial updates.

How does 37signals track model state without boolean columns?

State is tracked as separate records, such as a Card::Closure model, instead of boolean columns. Predicates like card.closed? check for the presence of the related record, and queries use joins or where.missing to filter open versus closed cards.

Should I use RSpec or Minitest for Rails testing?

This style uses Minitest with fixtures because it ships with Rails, has less DSL magic, and boots faster. Fixtures provide deterministic preloaded data, and tests ship in the same commit as the feature rather than following strict TDD.

Does DHH Rails style use Devise for authentication?

No, it replaces Devise with a custom magic link authentication of roughly 150 lines using Session and MagicLink models. This avoids password storage liability and gives full control over the authentication flow.

What gems does 37signals avoid in Rails apps?

They avoid devise, pundit, sidekiq, redis, view_component, GraphQL, factory_bot, RSpec, and Tailwind. Instead they use Solid Queue, Solid Cache, fixtures, Minitest, standard partials, and native CSS with layers and OKLCH colors.

When should I not use service objects in Rails?

In DHH style, business logic stays in fat models with verb methods like card.close rather than service objects like CardCloser.call(card). Plain Ruby objects are only used for namespaced presentation or bundling logic under parent models.