Recommends recording the risk tested, commands executed, evidence collected, HTTP test results, and cleanup or rollback status.
and 1 more in the full report
4 fixed18 passed either way0 still failing0 broke
Pass-rate lift
+18 pp
Tokens
+1%
Agent turns
0%
Response time
-30%
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 4 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 4
Prompt
A developer wants to run various ad-hoc integration scripts against a staging Django application to see if anything breaks. What structured step should precede running deployment verification checks?
What was checked, without and with the skill
Checked
Without skill
With skill
Recommends explicitly identifying and naming the specific deployment risk being tested before running checks.
Missed
Passed
case-16 · 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.md56 lines2 files
Django Deployment Test Loop
Use this skill when deployment work should be proven by running the app in an environment closer to production. The goal is not to test Docker or Ansible for their own sake; it is to catch integration failures that ordinary dev-server tests miss.
Source Traceability
Primary source: Harry Percival, Test-Driven Development with Python, 3rd ed. Guidance is transformed and paraphrased from chapters 9-12, 18, 23, and Appendix A, especially Docker checks, production settings, static files, environment variables, Ansible deployment, staging functional tests, and server debugging.
Workflow
Name the deployment risk.
Static files, production settings, database path, permissions, secrets, migrations, logging, email, hostnames, or container networking.
Choose the smallest production-like check.
Docker build/run smoke test.
Functional test against the container.
Staging functional test after deploy.
Server log or management-command check when browser tests are not the right proof.
Make configuration explicit.
Use environment variables for production differences.
Keep secrets out of images and source.
Fail fast for missing required settings.
Verify the deployed surface.
Run migrations in the deployed environment.
Check static collection/serving when DEBUG=False.
Check host allow-list and database write location.
Inspect logs for errors rather than relying only on HTTP status.
Read deployment-patterns.md for container, staging, and debugging patterns.
Decision Rules
If a failure only appears with DEBUG=False, reproduce with production-like settings locally first.
If the problem involves filesystem permissions or mounted volumes, verify inside the running container.
If the problem involves server config, run a staging smoke test before production.
If a test needs real server data setup, use a safe management command or explicit fixture path, never ad hoc production mutations.
If the deployment step is manual twice, consider codifying it in Ansible or the existing deployment tool.