Triage failed Ruby automation jobs with Resque
Inspect a bounded set of Resque failures, correlate exception evidence and failure IDs, and prepare a recovery plan without retrying or deleting jobs.
npx skills add agentskillexchange/skills --skill triage-failed-ruby-automation-jobs-with-resque
Use this runbook when an existing Ruby application uses Resque for agent or automation work and an operator needs an evidence-backed explanation of failed jobs. Give the agent the application environment, Redis namespace, queue scope, observation window and maximum record count. It loads the application’s existing bundle and configuration, inspects a bounded page of failures, correlates records with logs or an exception tracker, and returns a diagnosis and a proposed recovery action for human review.
What this skill actually does
The workflow is read-only failure triage. Run a short Ruby script inside the configured application environment with bundle exec ruby, require the application and resque/failure, obtain the failure count with Resque::Failure.count, and read a bounded page with Resque::Failure.all(offset, limit, queue). Match the queue argument and field layout to the configured backend. Record the observation time, list position, queue, job class, relevant arguments, exception, traceback and any failure_id; redact credentials and personal data from the report. Group repeated failures by job class and exception and explain which evidence supports each proposed cause. Counts and positions are a changing snapshot, not stable job identifiers.
When present, the upstream failure ID can correlate the same exception across Redis and other failure backends. Check each record individually: older records and installations with generation disabled may lack the field. It does not provide constant-time lookup or atomic protection. A report may recommend a targeted retry after checking the job’s side effects, but this skill does not call requeue, remove, clear, enqueue or worker-control methods. Before any separately authorized mutation, re-resolve and reread the selected record; an ID comparison alone does not close the race with concurrent list changes.
Invoke this instead of opening the Resque dashboard normally when multiple failed automation jobs need a bounded, reproducible incident report with cross-backend correlation and a reviewable recovery plan. The deliverable is that report, including gaps where logs or correlation IDs are absent. Scope excludes building a generic queue service, defining recurring schedules, starting workers, changing Redis configuration and automatically replaying jobs.
Prerequisites are an existing Resque application, its configured failure backend, authorized Redis access and the application’s supported Ruby dependencies. Upstream currently states Ruby 3.2 or newer and Redis server 4.0 or newer; check the installed release’s requirements rather than upgrading during an incident. Resque is a Ruby library with no model or agent-runtime dependency: a tool-capable assistant can invoke the same application-local diagnostic script. Multi-Framework describes this portable operator interface, not an MCP server or a claimed native plugin. Metadata and upstream invocation were inspected; no application execution or security review was performed.