Drive Django features with outside-in and double-loop TDD: user story, Selenium or functional test, focused Django unit/integration tests, minimal implementation, and refactor.
SkillScore95Maintained
Automatic
◆Coding pack
Last verified 8/15/2026
What it changes
Passed 21 of 22 test cases with the skill, and 16 of 22 without it.
Without skill73%
With skill95%
Checks it passed that the model alone missed
Recommends writing plain Python unit tests targeting the extracted calculation function directly
Recommends combining one integration test with focused unit tests to cover the component interaction
Recommends writing a focused Django unit/integration test specifically for the URL routing or view layer
and 2 more in the full report
5 fixed16 passed either way1 still failing0 broke
Pass-rate lift
+23 pp
Tokens
+8%
Agent turns
0%
Response time
-31%
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 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 5
Prompt
The outer functional test for an article publishing feature failed because navigating to `/articles/new/` returned a 404 HTTP status. What should be the very next test added in the development loop?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends writing a focused Django unit/integration test specifically for the URL routing or view layer
Missed
Passed
case-03 · 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.md61 lines2 files
Django Outside-In TDD
Use this skill when a Django feature should be grown from observable user behavior down into views, forms, models, and helpers. Keep the outer test broad enough to prove user value and the inner tests small enough to keep the red/green loop fast.
Source Traceability
Primary source: Harry Percival, Test-Driven Development with Python, 3rd ed. Guidance is transformed and paraphrased from chapters 1-7, chapter 24, and Appendix A, especially the user-story-to-functional-test flow, double-loop TDD, working-state-to-working-state refactoring, and outside-in development.
Workflow
Start from the user-visible behavior.
Write a short user story or acceptance note.
Choose one functional test only when the behavior crosses browser, routing, template, persistence, or integration boundaries.
Run the outer test and make the failure useful.
Confirm the failure is expected and points to the next missing behavior.
Improve failure messages before implementation if the failure is vague.
Drop into the inner loop.
Add the smallest Django test for the next missing component: URL, view, template context, form, model, or helper.
Use Django's test client, RequestFactory, form instances, or model tests at the narrowest useful boundary.
Make the inner test pass with minimal code.
Avoid speculative data models, URLs, fields, and abstractions.
Keep a scratchpad of next ideas instead of implementing them early.
Refactor only on green.
Refactor production code first, then test code.
Preserve behavior through the existing tests.
Return to the outer test to choose the next slice.
Read patterns.md for layer choices, refactoring rules, and failure-handling patterns.
Layer Choice
Signal
Next Test
User workflow not proven
Functional test
URL or redirect missing
URL/view test
Template output changed
View/template integration test or HTML parser assertion