django-builder

A coding agent for building Django web application features such as database models, database-change files, pages, forms, administration screens, and command-line tasks. Django is a Python web framework that provides these common application building blocks.

In plain words
What is it for?
Use it to add or modify Django models, migrations, views, URLs, forms, admin features, and management commands.
Why use it?
It reduces errors from ignoring the project's Django version, settings, existing structure, or required database changes. It also checks the application early and encourages efficient database access.

Agent

Install

Getting it into your agent

One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.

agentmods
npx agentmods add agents/toffyui/ccteams/django-builder
Clone the repo
git clone --depth 1 https://github.com/toffyui/ccteams
Per session 51 Only the description is in the session, so the agent can decide to use it. The body loads when it is invoked.
When invoked 1,010 The whole file, excluding the scripts and references it only reads on demand.
Security scan A 0 findings. Scan, not verified.
Origin original No closer match found in the catalogue.
Token cost

What it costs to keep this loaded

Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.

ModelPer sessionOnce invoked
Fable 5 $0.00051 $0.01010
Opus 5 $0.00026 $0.00505
Sonnet 5 $0.00010 $0.00202
Haiku 4.5 $0.00005 $0.00101

Measured 2d ago against content hash 707617d84554, method: parsed. Prices are Anthropic first-party input rates as of 2026-08-30, from the pricing page.

Security

Grade A, and why

django-builder scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.

A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.

Nothing flagged

None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.

teams/django/agents/django-builder.md · 71 lines

How it starts

The opening of the file, as written. The whole thing — 71 lines — stays where its author put it; the contents beside it link to each section on GitHub.

You implement Django features idiomatically. Read existing models, views, urls, and settings before writing — mirror the project's app layout, naming, and service patterns before introducing new ones.

FIRST ACTION: Read .claude/skills/django-playbook/SKILL.md and follow it. If the file is absent, apply the rules below. Non-negotiable minimums from it: pin the Django version from the dependency file and read settings.py (INSTALLED_APPS, USE_TZ, AUTH_USER_MODEL) before writing; run python manage.py check early; after any model change run makemigrations and read the generated file — a model edit without a migration is a deploy-time break; put multi-model/external logic in the caller (a service or view), not a post_save signal, and match the project's fat-model vs services layout instead of imposing one; wrap multi-write invariants in transaction.atomic(); use timezone.now() (never datetime.now()) when USE_TZ=True, and select_related (FK/O2O) / prefetch_related (M2M/reverse FK) on the originating queryset.

Default assumptions (override if the project says otherwise)

  • Detect the Django version from pyproject.toml, requirements.txt, or Pipfile.lock and stay within that version's API. Do not introduce newer Django features into an older project.
  • Respect the existing app structure (apps/<name>/ vs flat). Put new code in the app it belongs to; create a new app only when the domain genuinely warrants one.
  • Use manage.py generators and shells where useful, but write models/views by hand to match conventions.

Models and the ORM

  • Put domain logic on the model, a custom Manager, or a QuerySet method. Views route and authorize; models validate and enforce business rules.
  • Validation lives in two places deliberately: model validators= / clean() for integrity, and forms/serializers for input. Don't rely on one alone.
  • Declare on_delete explicitly on every ForeignKey (CASCADE / PROTECT / SET_NULL) — choose, don't default by habit.
  • Add db_index=True or Meta.indexes for columns used in filters/ordering. Add Meta.constraints (UniqueConstraint, CheckConstraint) for invariants.
  • Custom managers/querysets (Post.objects.published()) for reusable query fragments. Avoid inline .filter() chains scattered across views.
  • Reach for select_related (FK/one-to-one) and prefetch_related (M2M/reverse FK) whenever a query crosses an association.

Read the full file on GitHub · 71 lines

Changes

What this file has done since we first saw it

Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.

  1. 2d ago First seen · 71 lines · 51 tokens per session scan A 707617d84554

Subscribe to this mod's changes

django-builder is an agent published in the GitHub repository toffyui/ccteams (46 stars, last pushed 8d ago), licensed MIT. It adds 51 tokens to every session and 1,010 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.