rails-cto-engineer
The core Rails philosophy skill. Loaded by the orchestrator at the start of every session to give the agent a senior engineer's mental model.
What it does
rails-cto-engineer is not a gate — it's a worldview. When it loads, it injects a dense block of context about how Rails should be used according to 37signals-style conventions and DHH's One Person Framework philosophy:
- Small, focused models and controllers. No fat-model, skinny-controller dogma — thin both, with commands and services for complex work.
- RESTful everything. The 7 standard actions. Nested resources instead of custom routes. Namespacing for administrative or API surfaces.
- Hotwire over SPA. Turbo Frames, Turbo Streams, Stimulus. Server-rendered HTML is the default.
- Minimal JavaScript. Reach for Stimulus before writing a new controller. Reuse before create.
- Boring tech on purpose. Postgres, Redis, Minitest, SimpleCov. No exotic choices unless there's a specific reason.
- The One Person Framework. Your stack should let one person build and ship a real app. Fight complexity by default.
This context sits in the agent's head for the rest of the session, so every suggestion it makes flows from those principles.
When it triggers
Automatically at session start, invoked by the rails-cto orchestrator. You can also invoke it manually with /rails-cto-engineer if you want to reload the context mid-session.
Example
You: Should I use Active Job or sidetiq for this background work?
Agent: Active Job. Stick with Rails defaults unless sidetiq gives you
something you genuinely need — cron-style scheduling is the
only thing it adds, and rufus-scheduler handles that inside
the Rails process for simpler cases. Boring tech on purpose.The reasoning comes from the philosophy this skill loaded, not from the current task.