"The best code is the code you don't write. The second best is the code that's obviously correct."
Vanilla Rails is plenty:
- Rich domain models over service objects
- CRUD controllers over custom actions
- Concerns for horizontal code sharing
- Records as state instead of boolean columns
- Database-backed everything (no Redis)
- Build solutions before reaching for gems
What they deliberately avoid:
- devise (custom ~150-line auth instead)
- pundit/cancancan (simple role checks in models)
- sidekiq (Solid Queue uses database)
- redis (database for everything)
- view_component (partials work fine)
- GraphQL (REST with Turbo sufficient)
- factory_bot (fixtures are simpler)
- rspec (Minitest ships with Rails)
- Tailwind (native CSS with layers)
Development Philosophy:
- Ship, Validate, Refine - prototype-quality code to production to learn
- Fix root causes, not symptoms
- Write-time operations over read-time computations
- Database constraints over ActiveRecord validations
- Controllers - REST mapping, concerns, Turbo responses, API patterns
- Models - Concerns, state records, callbacks, scopes, POROs
- Views & Frontend - Turbo, Stimulus, CSS, partials
- Architecture - Routing, multi-tenancy, authentication, jobs, caching
- Testing - Minitest, fixtures, integration tests
- Gems & Dependencies - What to use vs avoid
- Code Review - Review code against DHH style
- General Guidance - Philosophy and conventions
Specify a number or describe your task.
After reading relevant references, apply patterns to the user's code.
Verbs: card.close, card.gild, board.publish (not set_style methods)
Predicates: card.closed?, card.golden? (derived from presence of related record)
Concerns: Adjectives describing capability (Closeable, Publishable, Watchable)
Controllers: Nouns matching resources (Cards::ClosuresController)
Scopes:
chronologically, reverse_chronologically, alphabetically, latest
preloaded (standard eager loading name)
indexed_by, sorted_by (parameterized)
active, unassigned (business terms, not SQL-ish)
REST Mapping
Instead of custom actions, create new resources:
POST /cards/:id/close → POST /cards/:id/closure
DELETE /cards/:id/close → DELETE /cards/:id/closure
POST /cards/:id/archive → POST /cards/:id/archival
Ruby Syntax Preferences
# Symbol arrays with spaces inside brackets
before_action :set_message, only: %i[ show edit update destroy ]
# Private method indentation
private
def set_message
@message = Message.find(params[:id])
end
# Expression-less case for conditionals
case
when params[:before].present?
messages.page_before(params[:before])
else
messages.last_page
end
# Bang methods for fail-fast
@message = Message.create!(params)
# Ternaries for simple conditionals
@room.direct? ? @room.users : @message.mentionees
Key Patterns
State as Records:
Card.joins(:closure) # closed cards
Card.where.missing(:closure) # open cards
Current Attributes:
belongs_to :creator, default: -> { Current.user }
Authorization on Models:
class User < ApplicationRecord
def can_administer?(message)
message.creator == self || admin?
end
end
All detailed patterns in references/:
| File |
Topics |
| controllers.md |
REST mapping, concerns, Turbo responses, API patterns, HTTP caching |
| models.md |
Concerns, state records, callbacks, scopes, POROs, authorization, broadcasting |
| frontend.md |
Turbo Streams, Stimulus controllers, CSS layers, OKLCH colors, partials |
| architecture.md |
Routing, authentication, jobs, Current attributes, caching, database patterns |
| testing.md |
Minitest, fixtures, unit/integration/system tests, testing patterns |
| gems.md |
What they use vs avoid, decision framework, Gemfile examples |
|
|
Important Disclaimers:
- LLM-generated guide - may contain inaccuracies
- Code examples from Fizzy are licensed under the O'Saasy License
- Not affiliated with or endorsed by 37signals
1---2name: dhh-rails-style3description: This skill should be used when writing Ruby and Rails code in DHH's distinctive 37signals style. It applies when writing Ruby code, Rails applications, creating models, controllers, or any Ruby file. Triggers on Ruby/Rails code generation, refactoring requests, code review, or when the user mentions DHH, 37signals, Basecamp, HEY, or Campfire style. Embodies REST purity, fat models, thin controllers, Current attributes, Hotwire patterns, and the "clarity over cleverness" philosophy.4---5
6<objective>
7Apply 37signals/DHH Rails conventions to Ruby and Rails code. This skill provides comprehensive domain expertise extracted from analyzing production 37signals codebases (Fizzy/Campfire) and DHH's code review patterns.
8</objective>
9
10<essential_principles>
11## Core Philosophy
12
13"The best code is the code you don't write. The second best is the code that's obviously correct."
14
15**Vanilla Rails is plenty:**
16- Rich domain models over service objects
17- CRUD controllers over custom actions
18- Concerns for horizontal code sharing
19- Records as state instead of boolean columns
20- Database-backed everything (no Redis)
21- Build solutions before reaching for gems
22
23**What they deliberately avoid:**
24- devise (custom ~150-line auth instead)
25- pundit/cancancan (simple role checks in models)
26- sidekiq (Solid Queue uses database)
27- redis (database for everything)
28- view_component (partials work fine)
29- GraphQL (REST with Turbo sufficient)
30- factory_bot (fixtures are simpler)
31- rspec (Minitest ships with Rails)
32- Tailwind (native CSS with layers)
33
34**Development Philosophy:**
35- Ship, Validate, Refine - prototype-quality code to production to learn
36- Fix root causes, not symptoms
37- Write-time operations over read-time computations
38- Database constraints over ActiveRecord validations
39</essential_principles>
40
41<intake>
42What are you working on?
43
441. **Controllers** - REST mapping, concerns, Turbo responses, API patterns
452. **Models** - Concerns, state records, callbacks, scopes, POROs
463. **Views & Frontend** - Turbo, Stimulus, CSS, partials
474. **Architecture** - Routing, multi-tenancy, authentication, jobs, caching
485. **Testing** - Minitest, fixtures, integration tests
496. **Gems & Dependencies** - What to use vs avoid
507. **Code Review** - Review code against DHH style
518. **General Guidance** - Philosophy and conventions
52
53**Specify a number or describe your task.**
54</intake>
55
56<routing>
57| Response | Reference to Read |
58|----------|-------------------|
59| 1, "controller" | [controllers.md](./references/controllers.md) |
60| 2, "model" | [models.md](./references/models.md) |
61| 3, "view", "frontend", "turbo", "stimulus", "css" | [frontend.md](./references/frontend.md) |
62| 4, "architecture", "routing", "auth", "job", "cache" | [architecture.md](./references/architecture.md) |
63| 5, "test", "testing", "minitest", "fixture" | [testing.md](./references/testing.md) |
64| 6, "gem", "dependency", "library" | [gems.md](./references/gems.md) |
65| 7, "review" | Read all references, then review code |
66| 8, general task | Read relevant references based on context |
67
68**After reading relevant references, apply patterns to the user's code.**
69</routing>
70
71<quick_reference>
72## Naming Conventions
73
74**Verbs:** `card.close`, `card.gild`, `board.publish` (not `set_style` methods)
75
76**Predicates:** `card.closed?`, `card.golden?` (derived from presence of related record)
77
78**Concerns:** Adjectives describing capability (`Closeable`, `Publishable`, `Watchable`)
79
80**Controllers:** Nouns matching resources (`Cards::ClosuresController`)
81
82**Scopes:**
83- `chronologically`, `reverse_chronologically`, `alphabetically`, `latest`
84- `preloaded` (standard eager loading name)
85- `indexed_by`, `sorted_by` (parameterized)
86- `active`, `unassigned` (business terms, not SQL-ish)
87
88## REST Mapping
89
90Instead of custom actions, create new resources:
91
92```
93POST /cards/:id/close → POST /cards/:id/closure
94DELETE /cards/:id/close → DELETE /cards/:id/closure
95POST /cards/:id/archive → POST /cards/:id/archival
96```
97
98## Ruby Syntax Preferences
99
100```ruby
101# Symbol arrays with spaces inside brackets
102before_action :set_message, only: %i[ show edit update destroy ]
103
104# Private method indentation
105 private
106 def set_message
107 @message = Message.find(params[:id])
108 end
109
110# Expression-less case for conditionals
111case
112when params[:before].present?
113 messages.page_before(params[:before])
114else
115 messages.last_page
116end
117
118# Bang methods for fail-fast
119@message = Message.create!(params)
120
121# Ternaries for simple conditionals
122@room.direct? ? @room.users : @message.mentionees
123```
124
125## Key Patterns
126
127**State as Records:**
128```ruby
129Card.joins(:closure) # closed cards
130Card.where.missing(:closure) # open cards
131```
132
133**Current Attributes:**
134```ruby
135belongs_to :creator, default: -> { Current.user }
136```
137
138**Authorization on Models:**
139```ruby
140class User < ApplicationRecord
141 def can_administer?(message)
142 message.creator == self || admin?
143 end
144end
145```
146</quick_reference>
147
148<reference_index>
149## Domain Knowledge
150
151All detailed patterns in `references/`:
152
153| File | Topics |
154|------|--------|
155| [controllers.md](./references/controllers.md) | REST mapping, concerns, Turbo responses, API patterns, HTTP caching |
156| [models.md](./references/models.md) | Concerns, state records, callbacks, scopes, POROs, authorization, broadcasting |
157| [frontend.md](./references/frontend.md) | Turbo Streams, Stimulus controllers, CSS layers, OKLCH colors, partials |
158| [architecture.md](./references/architecture.md) | Routing, authentication, jobs, Current attributes, caching, database patterns |
159| [testing.md](./references/testing.md) | Minitest, fixtures, unit/integration/system tests, testing patterns |
160| [gems.md](./references/gems.md) | What they use vs avoid, decision framework, Gemfile examples |
161</reference_index>
162
163<success_criteria>
164Code follows DHH style when:
165- Controllers map to CRUD verbs on resources
166- Models use concerns for horizontal behavior
167- State is tracked via records, not booleans
168- No unnecessary service objects or abstractions
169- Database-backed solutions preferred over external services
170- Tests use Minitest with fixtures
171- Turbo/Stimulus for interactivity (no heavy JS frameworks)
172- Native CSS with modern features (layers, OKLCH, nesting)
173- Authorization logic lives on User model
174- Jobs are shallow wrappers calling model methods
175</success_criteria>
176
177<credits>
178Based on [The Unofficial 37signals/DHH Rails Style Guide](https://github.com/marckohlbrugge/unofficial-37signals-coding-style-guide) by [Marc Köhlbrugge](https://x.com/marckohlbrugge), generated through deep analysis of 265 pull requests from the Fizzy codebase.
179
180**Important Disclaimers:**
181- LLM-generated guide - may contain inaccuracies
182- Code examples from Fizzy are licensed under the O'Saasy License
183- Not affiliated with or endorsed by 37signals
184</credits>