Neexo Worker Agent

A background-job agent pattern for queue processing, render jobs, asset pipelines, and other asynchronous workflows in Neexo projects.

workerjobsautomation

Overview

Use this agent pattern for changes to background jobs, workers, queue handlers, render pipelines, or other asynchronous task processors.

When to Use

Editing queue consumer/producer code
Adding or modifying scheduled jobs (cron, intervals)
Changing render pipeline steps or asset post-processing
Reviewing retry logic, dead-letter queues, or failure recovery

Guardrails

Idempotency — verify that reprocessing the same job produces the same result without side effects
Retry behavior — check retry limits, exponential backoff, and dead-letter handling
Failure paths — ensure failed jobs log actionable context (job ID, attempt count, error) without leaking secrets or customer data
Payload schemas — keep job payloads versioned and narrow; avoid passing entire database rows
Timeouts — set explicit timeouts on job execution to prevent zombie workers

Validation

Run the smallest available worker or queue test before broader integration tests
For render jobs, validate with a single lightweight asset before triggering full batch renders
Check that failed jobs appear in monitoring/alerting and are not silently dropped

Example Agent Instruction

You are a worker-agent. Before modifying any job handler:
1. Read the job schema and check recent processing logs
2. Verify idempotency — would rerunning this job cause duplicate side effects?
3. Confirm retry/failure behavior is tested
4. Keep the change scoped — do not refactor unrelated worker code

Raw content

Copy this into your project — e.g. .instructions.md, .agent.md, or SKILL.md

## Overview

Use this agent pattern for changes to background jobs, workers, queue handlers, render pipelines, or other asynchronous task processors.

## When to Use

- Editing queue consumer/producer code
- Adding or modifying scheduled jobs (cron, intervals)
- Changing render pipeline steps or asset post-processing
- Reviewing retry logic, dead-letter queues, or failure recovery

## Guardrails

- **Idempotency** — verify that reprocessing the same job produces the same result without side effects
- **Retry behavior** — check retry limits, exponential backoff, and dead-letter handling
- **Failure paths** — ensure failed jobs log actionable context (job ID, attempt count, error) without leaking secrets or customer data
- **Payload schemas** — keep job payloads versioned and narrow; avoid passing entire database rows
- **Timeouts** — set explicit timeouts on job execution to prevent zombie workers

## Validation

- Run the smallest available worker or queue test before broader integration tests
- For render jobs, validate with a single lightweight asset before triggering full batch renders
- Check that failed jobs appear in monitoring/alerting and are not silently dropped

## Example Agent Instruction

```markdown
You are a worker-agent. Before modifying any job handler:
1. Read the job schema and check recent processing logs
2. Verify idempotency — would rerunning this job cause duplicate side effects?
3. Confirm retry/failure behavior is tested
4. Keep the change scoped — do not refactor unrelated worker code
```