Make Rails Active Job workloads resumable with Job Iteration
Use Job Iteration to turn long-running Rails Active Job workloads into checkpointed, interruptible jobs that coding or operations agents can safely generate, review, and run.
npx skills add agentskillexchange/skills --skill make-rails-active-job-workloads-resumable-with-job-iteration
Use Job Iteration when an agent or operator needs to implement Rails background jobs that may process large tables, CSV imports, tenant moves, shard maintenance, notifications, or other long-running work across deploys, worker restarts, pod evictions, or queue shutdowns. The repeatable workflow is to replace fragile all-in-one Active Job loops with a JobIteration::Iteration job, define a cursor-aware build_enumerator, keep each_iteration idempotent and bounded, choose the supported queue adapter behavior, and review the generated job for checkpointing, retry, throttling, and parallel-iteration safety.
What this skill actually does
Invoke this instead of ordinary Rails job code when an agent is asked to write or refactor background work that should survive interruption without starting over or double-processing early records. The scope boundary is narrow: resilient Rails Active Job iteration for long-running operator or agent-triggered maintenance work. It is not a generic scheduler, an MCP server, a Rails dashboard, or a broad background-job framework listing.
Inputs and prerequisites: Ruby 3.1 or later, Rails 7.1 or later, Active Job, the job-iteration gem, and a supported queue adapter such as Sidekiq, Resque, GoodJob, Solid Queue, Amazon SQS, or Delayed::Job.
Setup notes: Add gem ‘job-iteration’ to the Rails application’s Gemfile, run bundle install, include JobIteration::Iteration in the target Active Job class, replace perform loops with build_enumerator(cursor:) and each_iteration methods, then verify the chosen queue adapter handles graceful interruption as documented upstream.
Source and verification boundary: use https://www.rubydoc.info/gems/job-iteration as the canonical reference before running the workflow; keep commands, API calls, CLI usage, and generated outputs reviewable against that upstream source.
Framework fit: publish this as a Custom Agents workflow only when the operator can invoke the documented toolchain directly, rather than treating the upstream project as a generic product listing.