AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Django

skill-arbazkhan971-godmode-django · by arbazkhan971

Django + FastAPI development. Project structure, DRF serializers/viewsets, Pydantic, async Django with ASGI, admin, ORM optimization, deployment.

No reviews yet
0 installs
28 views
0.0% view→install

Install

$ agentstack add skill-arbazkhan971-godmode-django

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access Used
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-arbazkhan971-godmode-django)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
5mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Django? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Django — Django & FastAPI Development

Activate When

  • User invokes /godmode:django
  • User says "Django", "Django project", "Django app"
  • User mentions "FastAPI", "Pydantic", "dependency injection"
  • User asks about "DRF", "Django REST Framework", "serializers", "viewsets"
  • User mentions "Django admin", "admin customization"
  • User asks about "ASGI", "async Django", "Uvicorn", "Daphne"
  • User says "django view", "views.py", "Django view for"
  • When /godmode:plan identifies a Python web project
  • When /godmode:review flags Django or FastAPI architecture issues

Workflow

Step 1: Project Assessment

Understand the Python web application context:

PYTHON WEB PROJECT ASSESSMENT:
Project: 
Framework: 
Type: 
Scale: 
Database: 
Auth: 
Async needs: 
Deployment: 
Existing code: 

If the user hasn't specified, ask: "Are you building with Django, FastAPI, or both? Is this an API-only service or full-stack with templates?"

Step 2: Django Project Structure

Design the Django project layout following best practices:

DJANGO PROJECT STRUCTURE:

project/
├── manage.py
├── pyproject.toml              # Dependencies, tools config (ruff, mypy)
├── config/                     # Project-level configuration
│   ├── __init__.py
│   ├── settings/
│   │   ├── __init__.py
│   │   ├── base.py             # Shared settings
│   │   ├── development.py      # Dev overrides (DEBUG=True, etc.)
│   │   ├── production.py       # Production settings (security, caching)
│   │   └── test.py             # Test settings (fast password hasher, in-memory)
│   ├── urls.py                 # Root URL configuration
│   ├── wsgi.py                 # WSGI entry point

Step 3: Django REST Framework Patterns

Design the API layer with DRF:

DRF ARCHITECTURE PATTERNS:

1. Serializers — Data validation and transformation:

  # Base serializer pattern
  class UserSerializer(serializers.ModelSerializer):
      full_name = serializers.SerializerMethodField()

      class Meta:
          model = User
          fields = ['id', 'email', 'full_name', 'created_at']
          read_only_fields = ['id', 'created_at']

      def get_full_name(self, obj):
          return f"{obj.first_name} {obj.last_name}"

Step 4: FastAPI Architecture

Design FastAPI applications with dependency injection:

FASTAPI APPLICATION ARCHITECTURE:

app/
├── main.py                 # FastAPI app instance, lifespan events
├── config.py               # Pydantic Settings for configuration
├── dependencies.py         # Shared dependencies (get_db, get_current_user)
├── database.py             # SQLAlchemy/databases async engine setup
│
├── users/
│   ├── __init__.py
│   ├── router.py           # APIRouter with endpoints
│   ├── schemas.py          # Pydantic models (request/response)
│   ├── models.py           # SQLAlchemy/SQLModel ORM models
│   ├── service.py          # Business logic
│   ├── repository.py       # Database queries

Step 5: Async Django & ASGI

ASGI setup: config/asgi.py with get_asgi_application().
For WebSockets: channels ProtocolTypeRouter + AuthMiddlewareStack.
Use httpx.AsyncClient (not requests) in async views.

Step 6: Django Admin

Admin patterns: @admin.register(Model) + ModelAdmin.
Required: list_display, list_filter, search_fields, list_select_related.
Optional: list_editable, inlines, actions, readonly_fields.

Step 7: Database Optimization

Optimize Django ORM queries:

DJANGO ORM OPTIMIZATION:

1. N+1 query prevention:
  # BAD: N+1 queries (1 query for orders + N queries for customers)
  orders = Order.objects.all()
  for order in orders:
      print(order.customer.name)  # Each access triggers a query!

  # GOOD: select_related for ForeignKey/OneToOne (SQL JOIN)
  orders = Order.objects.select_related('customer').all()

  # GOOD: prefetch_related for ManyToMany/reverse FK (separate query)
  orders = Order.objects.prefetch_related('items', 'items__product').all()

  # GOOD: Prefetch with custom queryset

Step 8: Validation

Validate the Python web project:

PYTHON WEB PROJECT AUDIT:
| Check | Status |
|--|--|
| Business logic in services (not views) | PASS | FAIL |
| Serializers validate all input | PASS | FAIL |
| No N+1 queries (select/prefetch_related) | PASS | FAIL |
| Database indexes on filtered/ordered fields | PASS | FAIL |
| Custom user model (AbstractUser) | PASS | FAIL |
| Settings split by environment | PASS | FAIL |
| Secrets from environment variables | PASS | FAIL |
| Admin performance (list_select_related) | PASS | FAIL |
| Pagination on all list endpoints | PASS | FAIL |
| Authentication and permissions configured | PASS | FAIL |
| Tests use factories (Factory Boy) | PASS | FAIL |

Step 9: Deliverables

Generate the project artifacts:

PYTHON WEB PROJECT COMPLETE:

Artifacts:
- Framework: 
- Apps/modules:  apps,  models
- API:  with  endpoints
- Admin:  ModelAdmin configs customized
- Database:  with  indexes, optimized queries
- Async: 
- Audit: 

Next steps:
-> /godmode:api — Document the API with OpenAPI spec
-> /godmode:test — Write model, view, and integration tests
-> /godmode:deploy — Deploy with Gunicorn+Nginx or Docker
-> /godmode:migrate — Handle database schema migrations

Commit: "django: — , apps, endpoints, "

# Django development and testing
python manage.py check --deploy
pytest --tb=short
python manage.py migrate --check

Key Behaviors

Never ask to continue. Loop autonomously until done.

# Django diagnostics
python manage.py check --deploy
python manage.py test --parallel --verbosity=2
python manage.py makemigrations --check --dry-run
python manage.py showmigrations | grep '\[ \]'

IF query count per list view > 5: add selectrelated/prefetchrelated. WHEN test coverage 200ms: profile with django-debug-toolbar.

  1. Services own business logic. Views dispatch, serializers validate, services contain logic.
  2. Fat models, thin views — but not too fat. Cross-model rules belong in services.
  3. DRF serializers are contracts. Never fields = '__all__'. Separate create vs read serializers.
  4. Eliminate N+1 queries. selectrelated for FK, prefetchrelated for M2M. Use django-debug-toolbar.
  5. FastAPI dependencies compose. Auth, pagination, DB sessions as composable deps.
  6. Pydantic is source of truth. Validation, serialization, documentation in one place.
  7. Admin is a power tool. Customize list_display, search, filters. Admin N+1 is the top perf issue.

Flags & Options

| Flag | Description | |--|--| | (none) | Full Django/FastAPI workflow | | --audit | Audit existing Django or FastAPI project | | --django | Django-specific guidance only |

HARD RULES

  • NEVER put business logic in views or serializers — business rules belong in service functions
  • NEVER use fields = '__all__' in DRF serializers — explicitly list every field to prevent data leakage
  • NEVER use the default User model — always create a custom user model with AbstractUser at project start
  • NEVER use synchronous HTTP calls (requests) in async views — use httpx.AsyncClient instead
  • NEVER skip database indexes on fields used in filter(), order_by(), or WHERE clauses
  • ELIMINATE ALL N+1 queries with selectrelated (ForeignKey) and prefetchrelated (ManyToMany)
  • ALL admin ModelAdmin classes MUST use listselectrelated to prevent N+1 in the admin interface
  • ALL API list endpoints MUST have pagination configured — unbounded queries are not acceptable

Auto-Detection

1. Scan for manage.py, settings.py → Django; main.py with FastAPI → FastAPI; both → hybrid
2. Check REST_FRAMEWORK config, AUTH_USER_MODEL, DATABASES engine
3. Scan for services.py/selectors.py (layering), factories.py (testing), Celery (tasks)
4. Maturity: scaffold | structured | optimized | production-ready

Output Format

End every Django skill invocation with this summary block:

DJANGO RESULT:
Action: 
Files created/modified: 
Models created/modified: 
Views created/modified: 
Migrations created: 
Tests passing: 
Build status: 
Issues fixed: 
Notes: 

TSV Logging

Log every invocation to .godmode/ as TSV. Create on first run.

timestamp	project	action	files_count	models_count	views_count	migrations_count	tests_status	notes

Success Criteria

  1. python manage.py check --deploy passes with 0 critical warnings
  2. python manage.py test passes; coverage >= 80%
  3. No business logic in views/serializers — services only
  4. No fields = '__all__' — explicit field lists
  5. All querysets use selectrelated/prefetchrelated; list views <= 5 queries, detail <= 3
  6. Filterable/sortable fields have DB indexes
  7. Custom user model (not default auth.User)
  8. Migrations consistent (makemigrations --check)

Error Recovery

| Failure | Action | |--|--| | manage.py check fails | Fix CRITICAL first (middleware, ALLOWEDHOSTS) | | Tests fail | Check test DB permissions, fixtures | | Migration conflict | makemigrations --merge | | N+1 detected | Add selectrelated/prefetch_related |

Keep/Discard Discipline

KEEP if: tests pass AND quality improved AND no regressions
DISCARD if: tests fail OR performance regressed. Revert before proceeding.

Stop Conditions

STOP when: all tasks validated OR max iterations reached.
Guard: python manage.py test && python manage.py check --deploy.
On failure: git reset --hard HEAD~1.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.