CtrlK
BlogDocsLog inGet started
Tessl Logo

igmarin/rails-agent-skills

Curated library of 28 public AI agent skills for Ruby on Rails development. Organized by category: testing, code-quality, engines, infrastructure, api, and context. Covers code review, architecture, security, testing (RSpec), engines, Hotwire, and TDD automation. Shared Ruby skills (YARD docs, DDD, service objects) have moved to ruby-core-skills. Repository agents remain documented in GitHub but are intentionally excluded from the Tessl tile.

93

1.78x
Quality

95%

Does it follow best practices?

Impact

93%

1.78x

Average score across 28 eval scenarios

SecuritybySnyk

Passed

No known issues

Overview
Quality
Evals
Security
Files

SKILL.mdskills/infrastructure/implement-background-job/

name:
implement-background-job
license:
MIT
description:
Use when adding or reviewing background jobs in Rails. Configures Active Job workers, implements idempotency checks, sets up retry/discard strategies, selects Solid Queue (Rails 8+) or Sidekiq based on scale, and defines recurring jobs via recurring.yml or sidekiq-cron. Trigger words: background job, Active Job, Solid Queue, Sidekiq, idempotency, retry, discard, recurring job, queue.
metadata:
{"version":"1.0.0","user-invocable":"true"}

Implement Background Job

Use this skill when the task is to add, configure, or review background jobs in a Rails application.

HARD-GATE

EVERY job MUST have its test written and validated BEFORE implementation.
  1. Write the job spec (idempotency, retry, error handling)
  2. Run the spec — verify the job does not yet exhibit the intended behavior
  3. ONLY THEN write the job class

EVERY job that performs a side effect (charge, email, API call) MUST have
an idempotency check BEFORE the side effect.

EVERY perform method should do only three things:
  1. Load the record from the passed ID
  2. Guard for idempotency / permanent no-op conditions
  3. Delegate the side effect or orchestration to a service object

If perform needs more than that, extract a service.

Core Rules

AspectRule
ArgumentsPass IDs, not objects. Load in perform.
IdempotencyCheck "already done?" before doing work
Retriesretry_on (explicit attempts:) for transient; discard_on for permanent errors
Backend (Rails 8)Solid Queue (database-backed, no Redis)
Backend (Rails 7)Sidekiq + Redis for high throughput
Recurringconfig/recurring.yml (Solid Queue) or cron/sidekiq-cron
Anti-patternsNo ActiveRecord objects as args; no :inline/:async in production; no business logic in perform

Core Process

  1. Write the job spec first — idempotency, retry, and error handling.
  2. Run the spec to confirm it fails.
  3. Write the job class: perform receives IDs, loads the record, guards for no-op, delegates to a service.
  4. Add retry_on with explicit attempts: limit and discard_on for at least one permanent error.
  5. Run the full test suite.
  6. Enqueue or perform the job twice — confirm the second run is a no-op.
  7. For recurring jobs, define them in config/recurring.yml (Rails 8) or the chosen scheduler config.

Extended Resources

Rails 8 vs Rails 7

AspectRails 7 and earlierRails 8
DefaultNo default; set queue_adapter (often Sidekiq)Solid Queue (database-backed)
Dev/test:async or :inlineSame
RecurringExternal (cron, sidekiq-cron)config/recurring.yml
DashboardThird-party (Sidekiq Web)Mission Control Jobs

Examples

Thin job with idempotency and retry:

class SendInvoiceReminderJob < ApplicationJob
  queue_as :default
  retry_on Net::OpenTimeout, wait: :polynomially_longer, attempts: 5
  discard_on ActiveRecord::RecordNotFound

  def perform(invoice_id)
    invoice = Invoice.find(invoice_id)
    return if invoice.reminder_sent_at?

    InvoiceReminders::Send.call(invoice:)
  end
end

Service owns the side effect and state update:

module InvoiceReminders
  class Send
    def self.call(invoice:)
      InvoiceMailer.overdue(invoice).deliver_now
      invoice.update!(reminder_sent_at: Time.current)
    end
  end
end
  • BACKENDS.md
  • assets/job_patterns.md
  • assets/retry_examples.md

Output Checklist

  • Backend decision stated (Rails version/scale → Solid Queue or Sidekiq)
  • Job spec shown first; command run; confirms failure before implementation
  • perform receives IDs, loads record, guards idempotency, delegates to service
  • retry_on with attempts: limit and discard_on for permanent error
  • Double-run verification confirms second run is a no-op
  • Recurring job (if any) defined in config/recurring.yml or scheduler config
  • If ops docs requested: record backend, retry, recurring schedule, and idempotency decisions in process_log.md

Integration

SkillWhen to chain
review-migrationSolid Queue uses DB tables; add migrations safely
security-checkJobs receive serialized input; validate like any entry point
write-testsTDD gate: write job spec before implementation; use perform_enqueued_jobs
create-service-objectKeep perform thin; call service objects for business logic

skills

infrastructure

README.md

tile.json