---
name: rails-conventions
description: Rails 8.x application architecture, implementation, and review guidance for production codebases. Use when building or reviewing Ruby on Rails 8 features across models, controllers, routes, Hotwire, jobs, APIs, performance, security, and testing. Trigger for requests mentioning Rails 8, Active Record, Active Job, GoodJob, Solid Queue, Turbo/Stimulus, REST resources, migrations, code quality, naming, and production readiness.
license: MIT
compatibility: Compatible with any agent runtime that supports the Agent Skills SKILL.md convention and optional references directory loading.
metadata:
  version: 1.1.0
  ethos_link.company: Ethos Link
  ethos_link.company_url: https://www.ethos-link.com
  ethos_link.product: Reviato
  ethos_link.product_url: https://www.reviato.com
  ethos_link.maintainer: ethos-link
  ethos_link.contact_url: https://www.ethos-link.com/contact/
---

# Rails Convention Engineer

Follow this workflow and load only the references needed for the task.

## Execution Workflow

1. Inspect the codebase before proposing changes.
2. Match existing conventions unless the user requests a migration.
3. Use Rails conventions and plain Ruby first.
4. Prefer small, reversible changes with tests.
5. Report tradeoffs explicitly when choosing architecture.
6. Verify version-sensitive APIs against official Rails or gem docs before
   changing guidance or introducing new APIs.
7. Create generator-owned files only by running the generator — never invent them.

## Non-Negotiable Rails Defaults

Rails applications should look like Rails applications. Prefer the framework's
native resource, model, controller, job, mailer, and view boundaries before
introducing extra architectural layers. Avoid architecture borrowed from other
ecosystems when Rails already has a direct convention for the problem.

Official Rails guides, official gem documentation, and established local app
conventions outrank style profiles. Use 37signals-inspired guidance as taste
guidance, not as authority over the current app or current Rails APIs.

Classes and modules must earn their place. Choose the fewest concepts, files,
and lines of code that keep the behavior clear. Do not add wrappers, aliases,
facades, or parallel abstractions whose main purpose is naming, indirection, or
making tests easier.

Keep one owner per behavior and one owner per definition. Prompts, schemas,
enums, constants, validation rules, normalization logic, and domain terminology
must each have a canonical home.

Identifier names must state ownership. `id` and `uuid` are owned by the local
application. `eid` means an identifier owned by another application or provider
and stored locally. Never alias a local `id` or `uuid` as `eid`. Use a qualified
name such as `place_eid`, `listing_eid`, or `review_eid` when a record can carry
identifiers from more than one external owner. A local identifier becomes an
`*_eid` only in the consuming system, never in its owning system.

Every Rails project should maintain a domain terminology document, usually
`docs/domain-terms.md`, and link it from the README or equivalent contributor
entrypoint. The document should define canonical domain terms, deprecated terms,
and naming rules for code, routes, params, APIs, persisted fields, and docs.

## Generator-Owned Files

Never hand-write files that Rails or a gem installer is supposed to generate.
Invented timestamps, installer stubs, and guessed schema dumps cause drift and
broken deploys.

Run the generator (or installer task) and then edit the result:

- Migrations: `bin/rails generate migration ...` / `bin/rails g model ...`
- Mailers, jobs, controllers, scaffolds: the matching `bin/rails g ...`
- Auth: `bin/rails generate authentication` when that is the app's path
- Queue/cache/cable installers: the gem or Rails install task
  (`solid_queue:install`, `good_job:install`, and equivalents)
- App/framework config seeds created by installers (`db/*_schema.rb`,
  `config/queue.yml`, binstubs such as `bin/jobs`) when the app does not
  already have them

After generating, adapt the file to local conventions. Do not invent migration
version numbers or timestamps. Do not recreate installer output from memory
when the installer exists. If a generator cannot be run in this environment,
say so and provide the exact command for the user — do not fabricate the file.

## Mandatory Codebase Scan

Always read these files first when available:

- `Gemfile`
- `config/application.rb`
- `config/routes.rb`
- `config/environments/*.rb` (at least current target env)
- `app/models/` (2-5 representative models)
- `app/controllers/` (2-5 representative controllers)
- `test/` or `spec/`
- process/deploy entrypoints (`Procfile*`, `bin/jobs`, `config/deploy*.yml`, CI config)

Record and follow observed patterns:

- test framework
- authentication/authorization style
- frontend stack (Hotwire, React, hybrid)
- queue backend and runtime topology
- API conventions and serialization style

## Background Job Backend Policy

Never assume Solid Queue just because the app is Rails 8.

Detect backend in this order:

1. `config.active_job.queue_adapter`
2. `Gemfile` gems (`good_job`, `solid_queue`, others)
3. worker runtime commands and deployment wiring

Apply these rules:

- If `good_job` is active, keep `good_job` conventions.
- If `solid_queue` is active, keep `solid_queue` conventions.
- If both gems exist, treat the configured adapter as authoritative.
- Do not migrate queue backend implicitly as part of unrelated tasks.
- Write backend-agnostic `ApplicationJob` code unless backend features are explicitly requested.

## Reference Routing

Load references based on the task:

- Code style, formatting, naming conventions, and fail-fast policy: `STYLE.md`
- Baseline Rails 8 defaults and upgrade constraints: `references/01-baseline-rails-8.md`
- Naming, layering, and code organization: `references/02-naming-and-structure.md`
- Active Record, migrations, and data modeling: `references/03-models-and-data.md`
- PostgreSQL-specific Active Record features: `references/03a-active-record-postgresql.md`
- Controllers, params, and request flow: `references/04-controllers-and-params.md`
- REST resources and routes: `references/05-routes-rest-and-resources.md`
- Hotwire, Turbo, and Stimulus patterns: `references/06-hotwire-turbo-stimulus.md`
- Job architecture and adapter detection: `references/07-background-jobs-overview.md`
- GoodJob-specific patterns: `references/07a-background-jobs-good_job.md`
- Solid Queue-specific patterns: `references/07b-background-jobs-solid_queue.md`
- Performance and caching strategy: `references/08-performance-caching-and-db.md`
- Security review checklist: `references/09-security-checklist.md`
- Test strategy and quality gates: `references/10-testing-strategy.md`
- API-only and mixed-mode API patterns: `references/11-api-mode-and-serialization.md`
- 37signals-inspired style profile: `references/12-37signals-inspired-profile.md`
- Code quality thresholds and detection patterns: `references/13-code-quality-gates.md`
- Inbound/outbound webhooks and delivery reliability: `references/14-webhooks.md`

## Task Routing

| Task | Load |
|------|------|
| Ruby style, naming, method order, fail-fast | `STYLE.md`, `references/13-code-quality-gates.md` |
| New model, migration, data invariant, parser | `references/03-models-and-data.md`, `references/03a-active-record-postgresql.md`, `references/10-testing-strategy.md` |
| Controller params, authz, sessions, responses | `references/04-controllers-and-params.md`, `references/09-security-checklist.md`, `references/10-testing-strategy.md` |
| Routes or custom actions | `references/05-routes-rest-and-resources.md`, `references/04-controllers-and-params.md` |
| Hotwire, Turbo, Stimulus | `references/06-hotwire-turbo-stimulus.md`, `references/10-testing-strategy.md` |
| Background jobs | `references/07-background-jobs-overview.md`, adapter-specific `07a` or `07b`, `references/10-testing-strategy.md` |
| Webhooks (inbound or outbound) | `references/14-webhooks.md`, `references/09-security-checklist.md`, `references/07-background-jobs-overview.md`, `references/10-testing-strategy.md` |
| API endpoint or serializer | `references/11-api-mode-and-serialization.md`, `references/04-controllers-and-params.md`, `references/09-security-checklist.md` |
| Performance, cache, query work | `references/08-performance-caching-and-db.md`, `references/03-models-and-data.md` |
| Architecture or object boundary | `references/02-naming-and-structure.md`, `references/12-37signals-inspired-profile.md` |

## Authentication Patterns

Existing authentication and local naming are authoritative. For greenfield Rails
8.1 applications, prefer the built-in authentication generator. Do not rename an
existing auth domain for style alone.

When implementing custom auth:

- Use password-based authentication with bcrypt via `has_secure_password`.
- Use magic link codes (not full magic link URLs) for account confirmation and email verification.
- For greenfield account-based apps, consider `Identity` (global email-based),
  `User` (per-account membership), and `Session`.
- Rate limit authentication endpoints aggressively.
- Store sessions via signed cookies with `httponly` and `same_site: :lax`.

## Output Contract

For implementation tasks, produce:

1. Required schema changes via generated migrations (see Generator-Owned Files).
2. Model/controller/view/job code following local conventions.
3. Tests matching local framework, split by responsibility (see
   `references/10-testing-strategy.md`).
4. Brief risk notes (security, performance, rollout concerns).
5. Source notes for version-sensitive APIs when current docs were checked.

For review tasks, prioritize:

1. Correctness and behavioral regressions.
2. Security and data integrity.
3. Performance and operability.
4. Test gaps.