Move Django performance-sensitive Python loops into database-side computation with annotations, aggregates, filtered aggregates, F expressions, functions, Subquery, OuterRef, Exists, Window expressions, db_default, and GeneratedField.
SkillScore95Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 21 of 22 test cases with the skill, and 18 of 22 without it.
Without skill82%
With skill95%
Checks it passed that the model alone missed
Recommends using Exists() in combination with Subquery or filter
Recommends performing password hashing in Python using Django password hashers before saving
Warns against moving cryptographic password hashing into database SQL triggers or DB expressions
and 1 more in the full report
3 fixed18 passed either way1 still failing0 broke
Pass-rate lift
+14 pp
Tokens
-3%
Agent turns
0%
Response time
-26%
Model gemini-3.6-flashMeasured 8/15/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 3 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 3
Prompt
In a Django application managing an e-commerce platform, you need to filter `Customer` queryset to find customers who have at least one completed order. The current code evaluates `[c for c in Customer.objects.all() if c.orders.filter(status='completed').exists()]` in memory. Provide the optimized Django ORM QuerySet code to perform this check efficiently at the database level.
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends using Exists() in combination with Subquery or filter
Missed
Passed
Avoids pulling all Customer instances into Python memory before filtering
Passed
Passed
case-01 · gemini-3.6-flash · 8/15/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md40 lines2 files
Django DB-Side Computation
Use this skill when Django fetches rows into Python to compute values the database can compute more efficiently or more consistently.
Workflow
Identify the Python computation.
Counts, sums, min/max, booleans, latest related rows, rankings, denormalized totals, or per-row derived fields.
Confirm whether the computed value must be exact, current, and transactionally consistent.
Pick the SQL expression level.
filter(), exclude(), and F() for simple comparisons and updates.
annotate() and aggregates for per-object counts and totals.
Filtered aggregates for conditional counts and sums.
Exists() for yes/no related-row checks.
Subquery() with OuterRef() for latest or scalar related values.
Window() for ranks and running calculations.
GeneratedField for deterministic same-row computed columns when the database supports it.
Validate query shape.
Inspect generated SQL or QuerySet.explain().
Clear unintended ordering before grouping when needed.
Confirm indexes support joins, filters, and ordering.
Decide whether the result should be stored.
Use annotations for request-time values.
Use generated fields for same-row deterministic values.
Use materialized views or denormalized tables when cross-row aggregate queries are too expensive and can be stale.
See aggregation-patterns.md for Django expression examples.
Safety Notes
Database computation is not always faster; complex queries can overload the database or block OLTP work.
Generated fields have database-specific restrictions and PostgreSQL supports only persisted generated columns.
Subqueries and annotations can duplicate work if composed carelessly. Read the plan.
Verification
Compare correctness against the old Python calculation on representative data, then measure SQL time and total response time.