agentleFS
Sign inStart free
edjchapmanedjchapman/claude-code-config/skills/django-patterns/SKILL.md

django-patterns

Skill8 starsChanged 19 days agoMITView on GitHub

Django app-layer and ORM conventions. Use when editing models, views, serializers, admin, managers, signals, migrations, or querysets.

29 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use django-tdd, springboot-tdd and 6 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • FaisalAlqarniSkill

    django-tdd

    Django testing strategies with pytest-django, TDD methodology, factory_boy, mocking, coverage, and testing Django REST Framework APIs.

    Also in 6 projects that use this

  • AshfaqbsSkill

    springboot-tdd

    Test-driven development for Spring Boot using JUnit 5, Mockito, MockMvc, Testcontainers, and JaCoCo. Use when adding features, fixing bugs, or refactoring.

    Also in 4 projects that use this

  • seikaikyoSkill

    fastapi-patterns

    FastAPI + SQLModel + Neon PostgreSQL 後端開發最佳實踐。適用於 Render 部署的 API 服務。涵蓋路由設計、資料庫操作、錯誤處理、認證授權。

    Also in 3 projects that use this

  • royaluniondesign-sysSkill

    deployment-patterns

    Deployment workflows, CI/CD pipeline patterns, Docker containerization, health checks, rollback strategies, and production readiness checklists for web applications.

    Also in 3 projects that use this

  • lodetomasiSkill

    tdd-workflow

    Test-Driven Development workflow with red-green-refactor pattern and best practices

    Also in 5 projects that use this

  • OpenAISkill

    security-scan

    Use for a standard, single-pass security audit of an entire repository or a scoped path, package, folder, or submodule with no diff to review. This is the default repository scan. Do not use for PR, commit, branch, or working-tree diffs, or for deep, multi-pass scans.

    Also in 4 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

20 rules. 0 are common, 6 are distinctive, and 14 are very specific to this project.

  • 0

    Common

    Most of the 4 edited versions we read keep these.

  • 6

    Distinctive

    This author's own choices. Worth a look.

  • 14

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Put business logic in model methods, not views

    line 10
  2. Distinctive:

    Use model methods for validation, state transitions, and computed properties

    line 12
  3. Very specific:

    Use @property for derived attributes that don't need arguments

    line 13
  4. Very specific:

    Use custom managers for reusable query logic (objects = MyManager())

    line 17
  5. Distinctive:

    Never put raw SQL in views -- encapsulate in manager methods

    line 20
  6. Very specific:

    Always use select_related() for ForeignKey/OneToOne joins

    line 24
  7. Very specific:

    Always use prefetch_related() for ManyToMany/reverse FK

    line 25
  8. Very specific:

    Use only() / defer() to limit fetched columns when appropriate

    line 26
  9. Very specific:

    Use values() / values_list() for read-only aggregation queries

    line 27
  10. Very specific:

    Use django-debug-toolbar or EXPLAIN to verify query plans

    line 29
  11. Distinctive:

    Avoid signals for business logic -- prefer explicit method calls

    line 33
  12. Very specific:

    Always use dispatch_uid to prevent duplicate registration

    line 35
  13. Distinctive:

    Keep signal handlers small and fast -- offload heavy work to tasks

    line 36
  14. Distinctive:

    Document which signals exist and what they do

    line 37
  15. Very specific:

    Use RunPython with both forward and reverse functions

    line 42
  16. Very specific:

    Always test migrations with --plan before applying

    line 44
  17. Very specific:

    Use AddIndex / RemoveIndex separately from schema changes for zero-downtime

    line 45
  18. Very specific:

    Use list_select_related to avoid N+1 in admin list views

    line 51
  19. Very specific:

    Use raw_id_fields for ForeignKey fields with many options

    line 52
  20. Very specific:

    Add readonly_fields for computed or audit fields

    line 53

“Common” is measured: kept by at least 6 in 10 of the 4 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Django Patterns

Fat Models, Thin Views

  • Put business logic in model methods, not views
  • Views should handle HTTP concerns only: parse request, call model/service, return response
  • Use model methods for validation, state transitions, and computed properties
  • Use @property for derived attributes that don't need arguments

Custom Managers and QuerySets

  • Use custom managers for reusable query logic (objects = MyManager())
  • Define custom QuerySet classes and use as_manager() for chainable filters
  • Common patterns: active(), for_user(user), with_related()
  • Never put raw SQL in views -- encapsulate in manager methods

Query Optimization

  • Always use select_related() for ForeignKey/OneToOne joins
  • Always use prefetch_related() for ManyToMany/reverse FK
  • Use only() / defer() to limit fetched columns when appropriate
  • Use values() / values_list() for read-only aggregation queries
  • Watch for N+1 queries in serializers and templates
  • Use django-debug-toolbar or EXPLAIN to verify query plans

Signals

  • Avoid signals for business logic -- prefer explicit method calls
  • Acceptable uses: audit logging, cache invalidation, denormalization
  • Always use dispatch_uid to prevent duplicate registration
  • Keep signal handlers small and fast -- offload heavy work to tasks
  • Document which signals exist and what they do

Migration Patterns

  • One migration per logical change -- don't combine unrelated changes
  • Use RunPython with both forward and reverse functions
  • For large tables, consider batched data migrations
  • Always test migrations with --plan before applying
  • Use AddIndex / RemoveIndex separately from schema changes for zero-downtime
  • Name migrations descriptively: 0042_add_user_email_verified_field

Admin Configuration

  • Register all models with at least list_display and search_fields
  • Use list_select_related to avoid N+1 in admin list views
  • Use raw_id_fields for ForeignKey fields with many options
  • Add readonly_fields for computed or audit fields

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free