Rails + Tailwind + Docker rules for AI coding agents

# AGENTS.md - this project

Instructions for AI coding agents working in this repository.

## Project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

## Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

## Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

## Reference docs

- [Rails guides](https://guides.rubyonrails.org)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Dockerfile best practices](https://docs.docker.com/build/building/best-practices/)

# CLAUDE.md - this project

Project instructions for Claude Code.

## Project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

## Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

## Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

## Reference docs

- [Rails guides](https://guides.rubyonrails.org)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Dockerfile best practices](https://docs.docker.com/build/building/best-practices/)

---
description: "Core rules for this project"
alwaysApply: true
---

# this project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
description: "Ruby on Rails conventions: Ruby on Rails app with Hotwire."
globs: app/**/*.rb, app/**/*.erb, config/**/*.rb, db/**/*.rb
alwaysApply: false
---

# Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

Docs: https://guides.rubyonrails.org

---
description: "Tailwind CSS v4 conventions: Utility-first styling with Tailwind CSS v4."
globs: **/*.css, **/*.tsx, **/*.vue, **/*.svelte, **/*.astro, **/*.html, **/*.blade.php, **/*.erb
alwaysApply: false
---

# Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

Docs: https://tailwindcss.com/docs

---
description: "Docker conventions: Containerised builds and local services with Docker."
globs: Dockerfile, **/Dockerfile, compose.yaml, docker-compose.yml, .dockerignore
alwaysApply: false
---

# Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

Docs: https://docs.docker.com/build/building/best-practices/

# Cursor rules - this project

You are an expert Ruby on Rails, Tailwind CSS v4, Docker engineer working on this codebase. Follow these rules.

## Project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

## Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

## Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

## Reference docs

- [Rails guides](https://guides.rubyonrails.org)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Dockerfile best practices](https://docs.docker.com/build/building/best-practices/)

# Copilot instructions - this project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
applyTo: "app/**/*.rb,app/**/*.erb,config/**/*.rb,db/**/*.rb"
---

# Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

---
applyTo: "**/*.css,**/*.tsx,**/*.vue,**/*.svelte,**/*.astro,**/*.html,**/*.blade.php,**/*.erb"
---

# Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

---
applyTo: "Dockerfile,**/Dockerfile,compose.yaml,docker-compose.yml,.dockerignore"
---

# Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

---
trigger: always_on
---

# this project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

---
trigger: glob
globs: app/**/*.rb, app/**/*.erb, config/**/*.rb, db/**/*.rb
---

# Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

---
trigger: glob
globs: **/*.css, **/*.tsx, **/*.vue, **/*.svelte, **/*.astro, **/*.html, **/*.blade.php, **/*.erb
---

# Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

---
trigger: glob
globs: Dockerfile, **/Dockerfile, compose.yaml, docker-compose.yml, .dockerignore
---

# Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

# GEMINI.md - this project

Project context for Gemini CLI.

## Project

A Ruby on Rails + Tailwind CSS v4 + Docker project.

Stack: Ruby on Rails, Tailwind CSS v4, Docker.

## Commands

- Dev server: `bin/dev`
- Generate migration: `bin/rails generate migration <Name>`
- Migrate: `bin/rails db:migrate`
- Tests: `bin/rails test`
- Lint: `bin/rubocop`
- Local services: `docker compose up -d`

## How to work in this repo

- Read the relevant files before editing. Follow the patterns already in the codebase over these generic rules.
- Make the smallest change that solves the task. Do not refactor or reformat unrelated code.
- Before saying a task is done, run the type-check, lint and tests listed under Commands and fix what you broke.
- If requirements are ambiguous, ask one clear question instead of guessing.
- Never commit secrets, API keys or `.env` files. Use env vars and keep `.env.example` up to date.
- Do not add a new dependency when the standard library or an existing dependency already covers it.
- Ask before adding, removing or upgrading any dependency.
- Ask before changing database schemas, auth, payments or CI configuration.
- Never delete files, drop data or run destructive commands (`rm -rf`, `git push --force`, `DROP TABLE`) without explicit approval.
- Keep each change under ~200 changed lines where possible; split larger work into steps.

## Ruby on Rails

- Follow Rails conventions (naming, RESTful routes, `resources`) before inventing structure.
- Use strong parameters (`params.expect` in Rails 8, `params.require(...).permit(...)` before) in every controller that writes data.
- Put validations on the model; keep controllers thin.
- Avoid N+1 queries with `includes` / `preload`.
- Use Hotwire (Turbo + Stimulus) for interactivity before adding a JS framework.
- Generate schema changes with migrations; never edit `db/schema.rb` by hand.
- Background work goes in Active Job (Solid Queue by default in Rails 8).

## Tailwind CSS v4

- Tailwind v4 is configured in CSS: `@import "tailwindcss";` plus `@theme { ... }` for design tokens. Do not create a `tailwind.config.js` unless the project already has one.
- Use theme tokens (colors, spacing) instead of arbitrary values like `w-[37px]`.
- Build responsive layouts mobile-first with `sm:`, `md:`, `lg:` prefixes.
- Extract repeated class lists into components, not `@apply` chains.
- Support dark mode with the `dark:` variant when the project uses it.

## Docker

- Use multi-stage builds and slim, pinned base images.
- Run the app as a non-root user in the final image.
- Keep a `.dockerignore` that excludes `.git`, `node_modules`, `.env` and build output.
- Never bake secrets into images; pass them at runtime.

## Reference docs

- [Rails guides](https://guides.rubyonrails.org)
- [Tailwind CSS docs](https://tailwindcss.com/docs)
- [Dockerfile best practices](https://docs.docker.com/build/building/best-practices/)