Backend · apply by default

/backend-jobs

Implement background processing, scheduling, and recovery

Use for durable background work; arch-event-flow defines cross-service consistency.

Make it your own.

In Claude Code, use the slash command and add your context. In Codex, select backend-jobs from the just-vibe skill picker, then send the same brief.

Version 0.11.0 also supports /jv backend-jobs, /just-vibe backend-jobs and /jv:backend-jobs in Claude. See shortcut setup and context examples.

Example · apply
/just-vibe:backend-jobs Implement a resumable worker with bounded retries and poison-message handling.
edge · apply
/just-vibe:backend-jobs Implement a resumable job that might receive the same message concurrently.
blocked · inspect
/just-vibe:backend-jobs Plan worker behavior with unknown broker delivery guarantees.

What the agent does

  1. Specify payload version, stable job identity, lease expiry, ack timing, bounded retry and dead-letter inspection before coding the worker.
  2. Implement idempotent effects and checkpoints where needed.
  3. Test crash and restart before and after the effect.

Inputs

  • job purpose, payload, scheduling/retry policy, concurrency, and environment.

Optional context: scope, references, constraints, successCriteria, environment, mode, budget.

Scope

Reads
Worker implementation and local/test registration; live scheduling must be requested.
Writes
Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
Mode
Apply; job purpose, payload, scheduling/retry policy, concurrency, and environment.
Prerequisites
Service source, data/interface contracts, framework/runtime versions, and test environment. Default apply operations target local code and isolated tests; live infrastructure/data mutations require their own requested scope.

Expected output

  • Worker and configuration with its job state machine, retry/lease rules, observable failure handling and crash-before/after-effect tests.

How the work is checked

  • A worker crash can resume without duplicate irreversible effects; poison messages stop retrying after a defined bound.

When to stop or clarify

  • No unrequested recurring jobs. Unknown provider delivery guarantees require explicit assumptions and corresponding safeguards.

Handling missing context

Infer
Trace service callers, request contracts, authorization, transactions, retries and existing test infrastructure.
Assume
Use the existing persistence and framework; isolate local tests from live services.
Ask
Resolve ambiguous durability, duplication or consistency requirements before encoding them; absent production access does not prevent local implementation.

Technical guidance

Evidence
Inspect queue delivery guarantees, claim/lease mechanism, retry policy, payload version and effect identity.
Method
Couple durable progress with business-effect deduplication; define stale lease takeover, poison-message handling and resumable checkpoints.
Pitfall
Acknowledging before durable progress loses work; assuming a timed-out worker stopped can duplicate an effect.
Check
Interrupt before effect, after effect and before acknowledgment, then restart; verify bounded retries and no duplicate business result.

Situational decisions

When a worker dies after the external effect but before acknowledgement: Reconcile the effect using durable identity before replaying it.

The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.

Keep exploring