Senior Backend
Install this when you want opinionated Django 5 monolith defaults—DRF, Postgres, Celery, admin, and explicit anti-patterns—for a small team shipping CRUD or content-heavy products.
Overview
Senior-backend is an agent skill most often used in Build (also Ship for rate limiting and Operate for queue/cache choices) that applies a Django 5 modular-monolith profile with Postgres, DRF, and explicit stack anti-pat
Install
npx skills add https://github.com/alirezarezvani/claude-skills --skill senior-backendWhat is this skill?
- JSON profile schema for django-monolith: Django 5, Python 3.11–3.12, PostgreSQL 16+, Redis cache, Celery or django-rq
- Targets teams of 2–25 with shared multi-tenant pattern, PII tier, and customized django-admin
- API layer options: Django REST Framework or django-ninja when async is needed—explicit kill rule against running FastAPI
- Mandatory operational guardrails: DRF rate limiting, background work via Celery/arq—not raw threads
- Anti-recommendations block kills microservices split, deleting django-admin, and unjustified raw SQL at this scale
- Profile targets team_size 2–25 with shared-multi-tenant and modular-monolith pattern
- Stack specifies PostgreSQL 16+, Django 5, and pytest + pytest-django + factory-boy for testing
Adoption & trust: 964 installs on skills.sh; 17.5k GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need a consistent backend architecture for a small team but agent suggestions drift toward microservices, dual frameworks, or missing ops basics like rate limits and real job queues.
Who is it for?
Solo or indie builders planning or building Django SaaS, marketplaces, auctions, or content sites with 2–25 people in mind and a need for django-admin.
Skip if: Greenfield teams committed to Rust/Go microservices, serverless-only APIs with no Django admin, or products that explicitly reject Python monoliths.
When should I use this skill?
Starting or reviewing Django backend architecture for CRUD-heavy, admin-needed products where a monolith profile should override ad-hoc stack suggestions.
What do I get? / Deliverables
After the skill runs, implementation and review guidance match the django-monolith profile—stack, constraints, and kill/warn rules—so you can ship a single codebase with admin, API, and background work without contradict
- Architecture decisions aligned to the django-monolith JSON profile
- Explicit anti-pattern checks (no dual frameworks, no thread-based background work)
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Build because the skill is a stack profile and architecture contract for implementing the backend, not a one-off CLI task. Backend subphase fits modular-monolith API design, ORM, queues, cache, and auth choices called out in the profile schema.
Where it fits
Agent scaffolds apps, DRF serializers, and Postgres models using the pinned django-5 and pytest-django testing stack.
Review insists on DRF plus django-ratelimit instead of shipping a public API with no throttling.
You validate Redis cache and Celery workers match the profile before scaling traffic on a marketplace site.
How it compares
Use as a structured architecture profile instead of asking the agent for generic “best backend stack” chat without constraints.
Common Questions / FAQ
Who is senior-backend for?
Solo and indie builders (and small teams) shipping Django-based SaaS or content/CRUD products who want one authoritative monolith profile rather than mixed framework advice.
When should I use senior-backend?
In Build when choosing stack and module layout; in Ship when enforcing API rate limiting and background-job patterns; in Operate when validating cache, queue, and Postgres choices against the profile.
Is senior-backend safe to install?
Review the Security Audits panel on this Prism page before installing; the skill is documentation and schema guidance and does not define its own shell or network permissions in the excerpt.
SKILL.md
READMESKILL.md - Senior Backend
{ "$schema": "https://json-schema.org/draft-07/schema#", "profile_name": "django-monolith", "description": "Django 5 + Django REST Framework + Postgres. Team size 2-25, content-heavy CRUD, admin needs (auctions, marketplaces, content sites). Batteries-included beats hand-rolling.", "version": "1.0.0", "constraints": { "team_size_min": 2, "team_size_max": 25, "tenancy": "shared-multi-tenant", "data_sensitivity_tier_max": "pii", "pattern": "modular-monolith", "admin_panel_needed": true }, "stack": { "framework": "django-5", "language": "python-3.11-or-3.12", "api_layer_options": ["django-rest-framework", "django-ninja-when-async-needed"], "orm": "django-orm", "database": "postgresql-16+", "cache": "redis-via-django-cache", "queue": "celery-or-django-rq", "auth": "django-built-in-auth + django-allauth-for-social", "templates_when_html_needed": "django-templates-or-htmx", "testing": "pytest + pytest-django + factory-boy", "admin": "django-admin-customized" }, "anti_recommendations": { "fastapi-on-top-of-django": "kill — pick one; don't run two frameworks", "no-celery-but-spawning-threads": "kill — use celery or arq for background work", "no-rate-limiting": "kill — DRF + django-ratelimit is mandatory", "raw-sql-without-justification": "warn — Django ORM is good enough at this scale", "microservices": "kill — Django excels as a modular monolith", "deleting-django-admin": "warn — admin is one of Django's strongest value props" }, "success_thresholds": { "p50_api_latency_ms": 100, "p95_api_latency_ms": 350, "p99_api_latency_ms": 800, "uptime_target": 0.99, "test_coverage_min": 0.7, "security_scan_severity_max": "medium", "rpo_minutes_max": 60, "rto_minutes_max": 240 }, "named_approver_chain": { "schema_change_production": "tech-lead + on-call", "new-external-service": "tech-lead + cfo", "auth-or-authz-change": "tech-lead + security-owner" }, "canon_references": [ "Django 5 docs (Django Software Foundation, 2024)", "DRF docs (Tom Christie, 2014-2024)", "Two Scoops of Django 3.x (Daniel + Audrey Roy Greenfeld, 2020)", "Adam Johnson, Django blog (2018-2024)", "Carlton Gibson on async Django (2023-2024)" ] } { "$schema": "https://json-schema.org/draft-07/schema#", "profile_name": "fastapi-python", "description": "FastAPI + SQLAlchemy 2 + Postgres + async. Team size 1-20, customer-facing or ML-adjacent SaaS, type-safe Python ecosystem. Strong async story, fastest path when ML/data team already in Python.", "version": "1.0.0", "constraints": { "team_size_min": 1, "team_size_max": 20, "tenancy": "shared-multi-tenant", "data_sensitivity_tier_max": "pii", "pattern": "modular-monolith-or-domain-bounded" }, "stack": { "runtime": "python-3.11-or-3.12", "framework": "fastapi-0.110+", "orm": "sqlalchemy-2-async-mode", "migrations": "alembic", "database": "postgresql-16+", "cache": "redis-only-if-justified", "queue_options": ["arq-on-redis", "celery-only-if-team-knows-it", "pg-tasks-for-simple-cases"], "auth_options": ["fastapi-users", "authlib", "clerk-paid"], "validation": "pydantic-v2", "testing": "pytest + pytest-asyncio + httpx-async-test-client + testcontainers", "tracing": "opentelemetry-with-honeycomb-or-tempo", "background_jobs": "arq-or-pg-boss-equivalent", "package_manager": "uv-or-poetry" }, "anti_recommendations": { "flask-for-new-projects": "kill — FastAPI is the modern default; Flask has no async story", "django-rest-framework-for-greenfield": "warn — DRF is fine for full-Django shops; FastAPI wins for API-first", "sync-only-database-driver": "kill — async path matters for FastAPI throughput", "no-pydantic-validation": "kill — every request body validated", "celery-without-experience": "kill — operational complexity not worth it under 200 Q