render-background-workers

Sets up and configures background workers on Render for queue-based job processing. Use when the user needs to process async jobs, consume from a queue, run Celery/Sidekiq/BullMQ/Asynq/Oban workers, handle graceful shutdown with SIGTERM, wire a worker to Key Value (Redis), or choose between workers and cron jobs for background work. Trigger terms: background worker, async jobs, queue consumer, Celery, Sidekiq, BullMQ, Asynq, Oban, job processing, SIGTERM, graceful shutdown.

Quality

93%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

87%Weight 40%Scale 1-3

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

The content is lean, actionable, and well-structured with a copy-paste YAML blueprint and one-level-deep references. Its only gap is the absence of explicit validation/verification checkpoints in the deploy and shutdown workflow.

Suggestions

Add an explicit verification step after deploy/shutdown, e.g. confirm the worker connected to Key Value and that in-flight jobs drained to zero before exit, to lift workflow_clarity from 2 to 3.

Tighten the 'How Workers Work' bullet that states the no-inbound-traffic point twice ('workers cannot receive private network traffic directed at them' repeats the preceding clause) to remove the small redundancy.

Optionally note how to observe a worker (logs/metrics) so users can validate graceful shutdown behavior in practice.

Dimension	Reasoning	Score
Conciseness	The body is lean and dense — no preamble explaining what a queue or worker is — with each section (when-to-use, framework table, KV pairing, worker-vs-cron, shutdown, blueprint YAML) earning its place; a single minor restatement of the no-inbound-traffic point keeps it just at level 3 rather than sliding to level 2.	3 / 3
Actionability	Provides a fully executable YAML blueprint with real fields (type: worker, fromService, property: connectionString, maxShutdownDelaySeconds 1-300 default 30) and concrete commands (celery -A tasks worker --loglevel=info, pip install -r requirements.txt) that are copy-paste ready, matching the executable-code anchor.	3 / 3
Workflow Clarity	The graceful-shutdown sequence is clearly enumerated (stop accepting jobs, finish/checkpoint, close connections, exit 0) and the SIGTERM->maxShutdownDelaySeconds->SIGKILL flow is stated, but no explicit verification or feedback loop (e.g., confirm the worker drained, check no jobs were dropped) is given, so checkpoints are missing rather than explicit — level 2, not level 3.	2 / 3
Progressive Disclosure	The body is an overview that splits per-framework setup and per-language shutdown handlers into two clearly signaled, one-level-deep reference files (both present on disk), with inline pointers and a References table for navigation — matching the well-signaled one-level-deep anchor.	3 / 3
	Total	11 / 12 Passed

Description

100%Weight 40%Scale 1-3

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

The description is specific, trigger-rich, and explicitly pairs a what statement with a Use-when clause scoped to Render background workers. It is concise without padding and unlikely to conflict with sibling skills.

Dimension	Reasoning	Score
Specificity	Lists multiple concrete actions — 'process async jobs, consume from a queue, run Celery/Sidekiq/BullMQ/Asynq/Oban workers, handle graceful shutdown with SIGTERM, wire a worker to Key Value (Redis)' — matching the multiple-specific-actions anchor rather than the partial coverage of level 2.	3 / 3
Completeness	Explicitly answers both what ('Sets up and configures background workers on Render for queue-based job processing') and when ('Use when the user needs to...') with explicit triggers, satisfying the level-3 anchor; the when clause is stated, not merely implied.	3 / 3
Trigger Term Quality	Provides strong coverage of natural terms a user would say — 'background worker, async jobs, queue consumer, Celery, Sidekiq, BullMQ, Asynq, Oban, job processing, SIGTERM, graceful shutdown' — across named frameworks and generic phrasings, not just some relevant keywords.	3 / 3
Distinctiveness Conflict Risk	Scoped to Render background worker services with framework-specific triggers, giving it a clear niche unlikely to fire for unrelated skills; it is well-distinguished, not merely 'somewhat specific'.	3 / 3
	Total	12 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository: openai/plugins
Path: plugins/render/skills/render-background-workers/SKILL.md
Commit: 11c74d6

Reviewed: 17 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.