services

A set of Rails guidelines for service objects, which are small classes that perform business operations outside models and controllers. They focus on keeping each operation focused, reusable, testable, and clear about errors.

In plain words
What is it for?
Use them for operations such as user registration, payment processing, order fulfillment, transactions across multiple models, external API integrations, background jobs, and detailed error handling.
Why use it?
They provide a place for multi-step work, external service calls, and logic involving several data records without making models or controllers too large. Consistent inputs and results also make the code easier to test.

Cursor rule for Cursor

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add rules/levifig/rails-instructions/services
Clone the repo
git clone --depth 1 https://github.com/levifig/rails-instructions

Made for: Cursor.

Per session 0 Nothing until a file matches its globs; then the whole rule loads.
When invoked 956 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00000 $0.00956
Opus 5 $0.00000 $0.00478
Sonnet 5 $0.00000 $0.00191
Haiku 4.5 $0.00000 $0.00096

Measured 2d ago against content hash fb095da4bf55, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

services scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

.cursor/rules/rails/services.mdc · 165 lines

How it starts

The opening of the file, as written. The whole thing — 165 lines — stays where its author put it; the contents beside it link to each section on GitHub.

Rails Service Objects Guide

Core Philosophy

  • Service objects encapsulate complex business operations
  • Keep services focused on single responsibilities
  • Make services easy to test and understand
  • Use services to keep models and controllers thin
  • Design for reusability and composability

When to Use Service Objects

  • Complex operations spanning multiple models
  • External API integrations
  • Multi-step processes with transactions
  • Business logic that doesn't fit naturally in models
  • Operations requiring detailed error handling
  • Background job processing logic

Service Design Principles

  • One service, one responsibility
  • Clear, descriptive naming that explains the operation
  • Consistent interface across services
  • Explicit dependencies and parameters
  • Predictable return values and error handling

Naming Conventions

  • Use verb-based names that describe the action
  • Include the domain context in the name
  • Examples: UserRegistrationService, PaymentProcessor, OrderFulfillment
  • Keep names specific and intention-revealing
  • Avoid generic names like UserService

Service Structure

  • Include ActiveModel modules for validations when needed
  • Define clear public interface
  • Keep implementation details private
  • Use dependency injection for testability
  • Document complex logic thoroughly

Input Handling

  • Validate inputs early and clearly
  • Use ActiveModel::Attributes for parameter handling
  • Define explicit attribute types
  • Provide meaningful validation messages
  • Handle optional parameters gracefully

Return Values

  • Return consistent, predictable results
  • Use success/failure pattern for operations
  • Include relevant data in responses
  • Provide clear error information
  • Consider using Result objects for complex returns

Error Handling

  • Anticipate and handle expected failures
  • Use exceptions for unexpected errors
  • Provide actionable error messages
  • Log errors with appropriate context
  • Design for graceful degradation

Transaction Management

  • Wrap related database changes in transactions
  • Handle rollbacks appropriately
  • Keep transactions as short as possible
  • Document transaction boundaries
  • Test rollback scenarios

Read the full file on GitHub · 165 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 165 lines · 0 tokens per session scan A fb095da4bf55

Subscribe to this mod's changes

services is a cursor rule published in the GitHub repository levifig/rails-instructions (54 stars, last pushed 1y ago), licensed MIT. It costs nothing until one of its globs matches a file; then it loads 956 tokens. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.