Aider · Ruby · Rails · Popular baseline

# Aider · Ruby + Rails  
Generated February 10, 2026  
Agent: Aider  
Language: Ruby  
Framework: Rails

## Global rules
- Start by reading existing project instructions and architecture docs before changing behavior.

- Prefer minimal diffs and preserve existing code style and naming conventions.

- State assumptions and call out risks before making breaking or cross-module changes.

- When behavior changes, add or update tests in the closest existing test layer.

- Never commit secrets, tokens, credentials, or generated private keys.

Start by reading existing project instructions and architecture docs before changing behavior.

Prefer minimal diffs and preserve existing code style and naming conventions.

State assumptions and call out risks before making breaking or cross-module changes.

When behavior changes, add or update tests in the closest existing test layer.

Never commit secrets, tokens, credentials, or generated private keys.

## Agent-specific
- Keep patches surgical; avoid touching unrelated files.

- Show the exact commands used to validate important changes.

- When uncertain, ask one focused clarification question before broad edits.

## Language-specific
- Prefer small POROs/service objects for business logic; keep controllers focused on HTTP concerns.

- Use clear method names and keyword args for public APIs.

- Favor ActiveRecord scopes for reusable query logic.

## Framework-specific
- Use RESTful routes and keep controllers thin; move domain logic to services/models.

- Use strong params and validate user input at boundaries.

- Prefer Turbo Stream updates for interactive CRUD when already using Hotwire.

## Options

### Testing rules
- Require tests for changed behavior or document why tests were not added.

- Run the smallest relevant test subset first, then broaden if needed.

### Architecture rules
- Preserve module boundaries and avoid leaking internal abstractions.

- Prefer incremental refactors over large rewrites.

### View/controller conventions
- Keep view templates focused on presentation; move branching logic to helpers/services.

- Keep controller actions narrow and predictable.

### Security rules
- Validate and sanitize all user-controlled input.

- Apply least-privilege defaults for data access and actions.

### Ask before changing public API
- Before changing a public API, present the impact and ask for explicit confirmation.

- If approved, document the migration path for consumers.

### Prefer minimal diffs
- Limit changes to the smallest set of files and lines needed.

- Defer unrelated cleanup to separate follow-up changes.