Design safe Django and PostgreSQL indexes from measured query plans, including B-tree, composite, covering, partial, expression, GIN/JSONB, BRIN, and concurrent migration patterns.
SkillScore100Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 22 of 22 test cases with the skill, and 20 of 22 without it.
Without skill91%
With skill100%
Checks it passed that the model alone missed
Expect an operational risk assessment covering migration rollback procedures.
Expect verification steps to include execution plan comparison before and after index creation.
2 fixed20 passed either way0 still failing0 broke
Pass-rate lift
+9 pp
Tokens
-1%
Agent turns
0%
Response time
-28%
Model gemini-3.6-flashMeasured 8/15/2026v122 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 2 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 2
Prompt
Our dashboard runs a heavy query against `Invoice` objects where `status = 'UNPAID'`, searching across `due_date` ranges. Since unpaid invoices are only 5% of the table, we want to index just those records. Can you create the Django model index configuration, provide the live migration implementation, and specify the verification steps needed before and after applying it?
What was checked, without and with the skill
Checked
Without skill
With skill
Expect a partial index using condition with a Q object for status = 'UNPAID'.
Passed
Passed
Expect atomic = False to be set on the migration class.
Passed
Passed
Expect verification steps to include execution plan comparison before and after index creation.
Passed
Passed
Expect an operational risk assessment covering migration rollback procedures.
Missed
Passed
case-02 · 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.md39 lines2 files
Django Index Design
Use this skill to add or change indexes only after profiling shows a specific query can benefit. Indexes speed selected reads and constraints, but they add write cost, migration risk, and maintenance overhead.
Workflow
Start from a query plan.
Capture the SQL, filters, joins, ordering, selected columns, table sizes, and current indexes.
Confirm that the query is important enough to optimize.
Choose the index shape.
Equality filters first, then range/order fields when useful.
Match ORDER BY for LIMIT queries when possible.
Use partial indexes for highly queried subsets.
Use covering indexes only when selected columns are stable and index-only scans are plausible.
Use GIN for JSONB containment, arrays, and full-text patterns; do not expect a B-tree to solve those.
Express the index in Django models or migrations.
Prefer Meta.indexes for normal model-owned indexes.
Prefer AddIndexConcurrently and RemoveIndexConcurrently for live PostgreSQL tables.
Use raw SQL only when Django cannot express the index.
Validate on production-like data.
Re-run QuerySet.explain() or EXPLAIN ANALYZE.
Verify the planner uses the index for the target query.
Check write-path impact when the indexed table is hot.
See index-patterns.md for index examples and migration templates.
Production Rules
For PostgreSQL live tables, use concurrent index operations and set the migration atomic = False.
Keep names short, stable, and explicit.
Do not add duplicate indexes that are already covered by a unique constraint or a left-prefix composite index.
Remove unused indexes only after checking production usage and deployment rollback needs.
Verification
Finish with before/after plan evidence, the exact migration operation, and the operational risk assessment for locks, writes, and rollback.