Agent skill

dhh-rails-style

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.

Stars 0
Forks 0

Install this agent skill to your Project

npx add-skill https://github.com/jjeremycai/claudekit/tree/main/plugins/compound-engineering/skills/dhh-rails-style

SKILL.md

<essential_principles>

Core Philosophy

"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 </essential_principles>
  1. Controllers - REST mapping, concerns, Turbo responses, API patterns
  2. Models - Concerns, state records, callbacks, scopes, POROs
  3. Views & Frontend - Turbo, Stimulus, CSS, partials
  4. Architecture - Routing, multi-tenancy, authentication, jobs, caching
  5. Testing - Minitest, fixtures, integration tests
  6. Gems & Dependencies - What to use vs avoid
  7. Code Review - Review code against DHH style
  8. General Guidance - Philosophy and conventions

Specify a number or describe your task.

After reading relevant references, apply patterns to the user's code.

<quick_reference>

Naming Conventions

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

ruby
# 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:

ruby
Card.joins(:closure)         # closed cards
Card.where.missing(:closure) # open cards

Current Attributes:

ruby
belongs_to :creator, default: -> { Current.user }

Authorization on Models:

ruby
class User < ApplicationRecord
  def can_administer?(message)
    message.creator == self || admin?
  end
end

</quick_reference>

<reference_index>

Domain Knowledge

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
</reference_index>

<success_criteria> Code follows DHH style when:

  • Controllers map to CRUD verbs on resources
  • Models use concerns for horizontal behavior
  • State is tracked via records, not booleans
  • No unnecessary service objects or abstractions
  • Database-backed solutions preferred over external services
  • Tests use Minitest with fixtures
  • Turbo/Stimulus for interactivity (no heavy JS frameworks)
  • Native CSS with modern features (layers, OKLCH, nesting)
  • Authorization logic lives on User model
  • Jobs are shallow wrappers calling model methods </success_criteria>

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

Expand your agent's capabilities with these related and highly-rated skills.

jjeremycai/claudekit

himalaya

Use when the user asks to read, send, search, or manage email from the terminal. Himalaya is a CLI email client supporting IMAP, Maildir, Notmuch, SMTP, and Sendmail backends. Trigger on: email, inbox, send email, check mail, reply to email, forward email, email folders.

0 0
Explore
jjeremycai/claudekit

gh-fix-ci

Use when a user asks to debug or fix failing GitHub PR checks that run in GitHub Actions; use `gh` to inspect checks and logs, summarize failure context, draft a fix plan, and implement only after explicit approval. Treat external providers (for example Buildkite) as out of scope and report only the details URL.

0 0
Explore
jjeremycai/claudekit

yeet

Use only when the user explicitly asks to stage, commit, push, and open a GitHub pull request in one flow using the GitHub CLI (`gh`).

0 0
Explore
jjeremycai/claudekit

ashby

This skill should be used when the user asks about "Ashby API", "how to use Ashby tools", "Ashby authentication", "recruiting workflows", "candidate pipeline", "interview scheduling", "hiring process", "move candidate through pipeline", "schedule an interview", "manage applications", "track hiring progress", "source candidates", or "advance to next stage". Provides complete API reference and recruiting workflow guidance for the Ashby ATS integration.

0 0
Explore
jjeremycai/claudekit

skill-installer

Install Codex skills into $CODEX_HOME/skills from a curated list or a GitHub repo path. Use when a user asks to list installable skills, install a curated skill, or install a skill from another repo (including private repos).

0 0
Explore
jjeremycai/claudekit

skill-creator

Guide for creating effective skills. This skill should be used when users want to create a new skill (or update an existing skill) that extends Codex's capabilities with specialized knowledge, workflows, or tool integrations.

0 0
Explore

Didn't find tool you were looking for?

Be as detailed as possible for better results