django-smoke-alarm
- Repo stars 0
- Author updated Live
- Author repo skills-registry
- Domain
- Security
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @tomevault-io · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Required · Vendor-specific
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- Python
- Permissions
-
- Read-only
- Write / modify
- Env read
- Network behavior
- External requests
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: django-smoke-alarm
description: Run and triage Django/DRF security smoke checks for settings hardening, throttling, safe HTML, O…
category: security
runtime: Python
---
# django-smoke-alarm output preview
## PART A: Task fit
- Use case: Run and triage Django/DRF security smoke checks for settings hardening, throttling, safe HTML, ORM race/idempotency patterns, and model integrity; especially useful before shipping or when evaluating djangoSecurityHunter-style findings. Use when this capability is needed..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “When to Use / Core Rule / Phase 1: Prepare a Clean Scan” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “Run and triage Django/DRF security smoke checks for settings hardening, throttling, safe HTML, ORM race/idempotency patterns, and model integrity; especially useful before shipping or when evaluating djangoSecurityHunter-style findings. Use when this capability is needed.”.
- **02** When the source has headings, the agent prioritizes “When to Use / Core Rule / Phase 1: Prepare a Clean Scan” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files, read environment variables; may access external network resources; requires Vendor-specific API keys.
## Running Rules
- read files, write/modify files, read environment variables; may access external network resources; requires Vendor-specific API keys.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source mentions slash commands such as `/tmp`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files, read environment variables.
Start with a small task and check whether the result follows “When to Use / Core Rule / Phase 1: Prepare a Clean Scan”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: django-smoke-alarm
description: Run and triage Django/DRF security smoke checks for settings hardening, throttling, safe HTML, O…
category: security
source: tomevault-io/skills-registry
---
# django-smoke-alarm
## When to use
- Run and triage Django/DRF security smoke checks for settings hardening, throttling, safe HTML, ORM race/idempotency pa…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “When to Use / Core Rule / Phase 1: Prepare a Clean Scan” and keep inference separate from source facts.
- read files, write/modify files, read environment variables; may access external network resources; requires Vendor-specific API keys.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "django-smoke-alarm" {
input -> user goal + target files + boundaries + acceptance criteria
context -> When to Use / Core Rule / Phase 1: Prepare a Clean Scan
rules -> SKILL.md triggers / order / output contract
runtime -> Python | read files, write/modify files, read environment variables | may access external network resources
guardrails -> requires Vendor-specific API keys + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Django Smoke Alarm
Use this when a Django or DRF project needs a fast security/reliability sweep, especially after a tool such as djangoSecurityHunter, Bandit, Semgrep, or a custom grep pass reports many findings.
Third-order stance: the goal is not “make the scanner green.” The goal is to find the few boring Django foot-guns that become production incidents, while teaching the project a repeatable preflight. Smoke alarms should be loud, cheap, and easy to silence only with evidence.
When to Use
- The project is Django/DRF and you need obvious security or reliability issues.
- A scanner reports many findings and you need a grounded triage.
- Before launch, deploy, CI hardening, or exposing new auth/API/upload/HTML surfaces.
- When adding or reviewing settings, DRF auth, OAuth/API keys, XML/Markdown/HTML rendering, import jobs, or admin previews.
Core Rule
Always classify scanner output before fixing:
- REAL — plausible exploit/data-loss/abuse path or broken production posture.
- HYGIENE — low-risk but worth making safer/clearer, often to reduce future mistakes.
- FALSE POSITIVE — scanner pattern is misleading; document why with code evidence.
Do not create a giant undifferentiated fix list. The dragon is usually three lizards in a trench coat.
Phase 1: Prepare a Clean Scan
Never judge raw scanner counts from a working repo if it contains worktrees or generated/vendor folders.
Exclude at minimum:
.git .hg .svn .venv venv node_modules dist build .tox .eggs
.mypy_cache .pytest_cache htmlcov coverage
.worktrees .claude/worktrees
.env .env.*If using djangoSecurityHunter, prefer a clean temp copy and scan-only env values:
python3 skills/django-smoke-alarm/scripts/django_smoke_alarm.py \
--project . \
--settings myproject.settings \
--project-python .venv/bin/python \
--scanner-source /tmp/djangoSecurityHunter/src \
--env SECRET_KEY=dummy-scan-only-not-production-40-plus-chars \
--env DEBUG=False \
--env ALLOWED_HOSTS=localhost,127.0.0.1 \
--env DATABASE_URL=sqlite:////tmp/django-smoke.sqlite3If the scanner cannot import settings, keep static findings but explicitly say which settings-backed checks were skipped.
Phase 2: Read the Rule Buckets, Not Just Counts
Group findings by risk surface:
- Production settings —
DEBUG,SECRET_KEY,ALLOWED_HOSTS, HTTPS redirect, HSTS, secure cookies, CSRF trusted origins, CORS. - DRF/API abuse — default authentication, permissions, throttles, pagination, auth-like routes, upload limits.
- Unsafe HTML —
mark_safe,|safe, XML/Markdown renderers, admin previews, template tags, rich text blocks. - Persistence races —
exists/get + create, multi-save workflows,save()in loops, arithmetic updates withoutF(), missing uniqueness/idempotency. - Model integrity — natural-key slugs, nullable unique-ish fields, risky cascade deletes, missing constraints.
- Secrets/logging — token-looking defaults, exception logs near OAuth/API keys, local
.env*accidentally tracked. - Dependencies and external scanners — pip-audit, Bandit, Semgrep, only after the clean project scan is understood.
Phase 3: Sample Before Fixing
For each noisy rule, inspect representative code before deciding.
Unsafe HTML triage
Classify as REAL if untrusted or external content is inserted into safe HTML without escaping:
- XML or Markdown source from outside the team
- user profile/team/org/bill/client fields
- uploaded file metadata
- admin preview fields backed by user content
Classify as HYGIENE if the string is constant or all interpolated variables are escaped, but the code would be safer with format_html() / format_html_join().
Classify as FALSE POSITIVE only when the full data path is safe and future edits are unlikely to reintroduce unsafe interpolation.
Transaction/race triage
Do not blindly wrap long-running workflows in transaction.atomic(). Multi-save progress markers around external API calls, Celery jobs, or imports may be intentional.
Prefer:
- DB uniqueness constraints for idempotency.
get_or_create()/update_or_create()where appropriate.select_for_update()for concurrent mutation of existing rows.F()expressions for arithmetic updates.- Small atomic sections around related DB writes, not around network calls or long LLM/image work.
Phase 4: Produce a Triage Table
Report a compact table:
| Finding | Classification | Evidence | Recommended move |
|---|---|---|---|
| Missing HSTS | REAL | settings.py has no SECURE_HSTS_SECONDS under DEBUG=False |
Add production security block or env-controlled settings |
Admin mark_safe preview |
HYGIENE | URL is escaped, constant HTML otherwise | Convert to format_html |
| AI pipeline multiple saves | FALSE POSITIVE/HYGIENE | Saves status before/after long external calls | Do not wrap whole function; maybe add comment/tests |
Then list only the top 3-7 REAL fixes. Put hygiene work behind those.
Phase 5: Turn Findings into Project Policy
If the same issue could recur, add a project-local guardrail:
settings.pyproduction security block and test.- DRF throttle defaults and per-route throttles for auth/OAuth/API-key endpoints.
- HTML renderer helper that escapes text by default and marks only known tags safe.
- Code-review note: “no
mark_safewith interpolation; useformat_html.” - Import/idempotency tests with duplicate input and repeated runs.
- CI smoke-alarm job that runs on a clean copy and stores JSON/SARIF artifacts.
scripts/django_smoke_alarm.py creates a clean temp copy, runs djangoSecurityHunter if available, writes JSON, and prints a grouped summary. It is intentionally a wrapper, not the source of truth: the agent still must read code and classify findings.
Useful flags:
--project— Django repo root.--settings— Django settings module.--project-python— project venv Python, recommended for settings import.--scanner-source— localdjangoSecurityHunter/srccheckout to add toPYTHONPATH.--env KEY=VALUE— scan-only env overrides.--output-dir— report destination.
- Use
trust-auditfor user-facing permission, privacy, billing, and unsafe-feeling AI/data flows found during the scan. - Use
kindness-checkafter fixes to catch developer/support burden from noisy scanner-driven changes. - Use
release-operatorif this creates a CI/release gate. - Use
decision-logif choosing to accept a scanner false positive or defer a real risk.
Source: carlkibler/agent-skills — distributed by TomeVault.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review