django-celery

django-celery provides production-grade patterns for background and asynchronous task processing in Django using Celery with Redis or RabbitMQ. It is meant for adding background jobs or async processing to a Django app, implementing periodic or scheduled tasks, offloading slow operations such as email, PDF generation, or API calls from the request cycle, setting up Celery Beat for cron-like scheduling, debugging task failures, retries, or queue backlogs, and writing tests for Celery tasks.

The skill covers project setup end to end: installing celery[redis], django-celery-results, and django-celery-beat; defining the Celery app in config/celery.py with config_from_object and autodiscover_tasks; and configuring Django settings including CELERY_BROKER_URL, CELERY_RESULT_BACKEND (django-db), JSON serialization, task behavior flags like CELERY_TASK_TIME_LIMIT, CELERY_TASK_SOFT_TIME_LIMIT, CELERY_WORKER_PREFETCH_MULTIPLIER, and CELERY_TASK_ACKS_LATE, and the DatabaseScheduler for Beat. It shows how to run workers and the beat scheduler and route queues with --concurrency and -Q. Task design patterns include basic shared_task definitions, retryable tasks using max_retries, autoretry_for, retry_backoff, retry_backoff_max, and retry_jitter, idempotent tasks that guard updates, and soft-time-limit handling via SoftTimeLimitExceeded. It demonstrates calling tasks with delay and apply_async (countdown, eta, queue routing), plus running synchronously with apply for tests. Beat scheduling is shown both code-defined via CELERY_BEAT_SCHEDULE with crontab, and database-defined through django_celery_beat models like PeriodicTask and CrontabSchedule. Canvas workflows cover chain, group, and chord for sequencing, parallelizing, and combining tasks with callbacks.

The skill is aimed at Django developers building reliable background processing, emphasizing production-safe defaults such as prefetch multiplier of 1 to prevent worker hoarding, acks-late to re-queue on crashes, and idempotent task design so tasks can safely run multiple times. It notes practical guidance like never combining worker and beat in production, and using synchronous execution only in tests or debugging. It is documented in a single SKILL.md with extensive code examples and originates from the ECC collection.