@mrciphersmith/keryx 0.3.3 → 0.3.6

package/src/gdskills/bundled/stacks/django/governance/scout.json

@@ -0,0 +1,40 @@
+[
+  {
+    "query": "Use when a Django project fails manage.py check, makemigrations/migrate, the test suite, or lint/type-check -- resolves migration conflicts and inconsistent migration history, ImproperlyConfigured settings errors, app-loading/circular-import errors, mypy/django-stubs type errors, and ruff failures with the smallest root-cause fix. Not for adding a feature (see django-implementation) or fixing test content (see django-testing).",
+    "decision": "fork",
+    "topMatch": "python/python-build-fix",
+    "recordedAt": "2026-09-25T18:06:19.335Z",
+    "skillName": "django-build-fix",
+    "justification": "top match python/python-build-fix (0.3-0.55 range) is the same build-fix category but for generic Python tooling, not Django's own manage.py/migration/ImproperlyConfigured failure modes; a fork scoped to Django's own build/check/migration errors is warranted since the shared category is deliberate but the specific failure surface (makemigrations conflicts, app-loading, django-stubs) is not covered by python-build-fix."
+  },
+  {
+    "query": "Use when reviewing Django changes for correctness and injection-class risks -- checks N+1 queries missing select_related/prefetch_related, mark_safe/|safe applied to user-traceable data, raw()/extra() built by string interpolation, @csrf_exempt on a session-authenticated view, missing/hand-edited migrations, and settings.py misconfiguration (DEBUG, SECRET_KEY, ALLOWED_HOSTS). Read-only: reports findings, does not edit code.",
+    "decision": "create",
+    "topMatch": "fastapi/fastapi-code-review",
+    "recordedAt": "2026-09-25T18:06:19.640Z",
+    "skillName": "django-code-review",
+    "justification": "top match python/python-code-review is the same review category but for generic Python risks (mutable defaults, bare except, resource leaks), not Django's own injection-class sinks (N+1 via select_related, mark_safe/|safe XSS, raw()/extra() SQL, csrf_exempt, migration hygiene); a Django-scoped fork covers concerns python-code-review has no visibility into."
+  },
+  {
+    "query": "Use when implementing or extending a feature in a Django (5.x) project -- covers models and migrations, class-based/function-based views, forms and serializers, querysets with select_related/prefetch_related to avoid N+1, and the framework's CSRF/escaping defaults. Not for plain Python with no Django import (see python-implementation) or a Django version-major upgrade (see django-migrate).",
+    "decision": "fork",
+    "topMatch": "django/django-code-review",
+    "recordedAt": "2026-09-25T18:06:19.952Z",
+    "skillName": "django-implementation",
+    "justification": "top match django/django-testing is this same pack's test-authoring skill, sharing only generic Django-project vocabulary (models, views, pytest-django) from its own test-authoring scope, not implementation/typing/queryset-design guidance; decision is fork since both are legitimately Django-scoped but cover disjoint workflows (writing production code vs. writing tests)."
+  },
+  {
+    "query": "Use when generating, reviewing, or safely applying Django schema/data migrations -- makemigrations for a model change, RunPython data migrations with forward/reverse functions, merge migrations for divergent branches, and staged rollout for a migration that must ship alongside a multi-phase deploy (e.g. a column removal). Not for a Django-major-version framework upgrade (there is no separate django-upgrade skill in this pack; treat a version jump as django-implementation plus this skill's migration discipline) or for fixing a broken/conflicting migration that's blocking the build (see django-build-fix).",
+    "decision": "create",
+    "topMatch": "java-kotlin-spring/java-kotlin-spring-migrate",
+    "recordedAt": "2026-09-25T18:06:20.259Z",
+    "skillName": "django-migrate"
+  },
+  {
+    "query": "Use when writing Django TestCase/SimpleTestCase classes, simulating browser requests against a view with Django's own request-simulation helper, wiring pytest-django fixtures (db, django_user_model), building factory_boy model factories, or asserting on permission/form/queryset behavior in a Django app's own test suite. Django-specific: ORM assertions, migration-aware test databases, and DRF serializer/view tests, scoped to code that actually imports Django.",
+    "decision": "create",
+    "topMatch": "fastapi/fastapi-testing",
+    "recordedAt": "2026-09-25T18:06:20.569Z",
+    "skillName": "django-testing"
+  }
+]

package/src/gdskills/bundled/stacks/django/pack.json

@@ -0,0 +1,43 @@
+{
+  "id": "django",
+  "family": "framework",
+  "extends": "python",
+  "modules": ["django-rules", "django-skills"],
+  "detectionMarkers": ["django"],
+  "provenance": {
+    "origin": "authored",
+    "sourceRef": "flow 335, Wave 4 batch 3"
+  },
+  "stability": "experimental",
+  "skills": {
+    "implement": ["django-implementation"],
+    "test": ["django-testing"],
+    "review": ["django-code-review"],
+    "build-fix": ["django-build-fix"],
+    "migrate": ["django-migrate"]
+  },
+  "agentProfile": {
+    "displayName": "Django",
+    "auditFocus": [
+      "a loop that issues one query per row where `select_related`/`prefetch_related` would collapse it (N+1)",
+      "`mark_safe`/the `|safe` template filter applied to anything that traces back to user input",
+      "`.raw()`/`.extra()` built with f-strings/`%`/`.format()` instead of the `params` argument",
+      "`@csrf_exempt` or `CsrfViewMiddleware` disabled on a view that actually needs CSRF protection",
+      "a model field or migration change with no corresponding migration file, or a hand-edited migration that drifts from `makemigrations` output",
+      "`SECRET_KEY`/`DEBUG=True`/permissive `ALLOWED_HOSTS` reaching a production settings module"
+    ],
+    "buildCommands": [
+      "python manage.py check",
+      "python manage.py makemigrations --check --dry-run",
+      "ruff check . / ruff format --check .",
+      "mypy . (with django-stubs) or the project's configured type checker",
+      "python manage.py test  # or: pytest (pytest-django) if the project uses it"
+    ],
+    "fixGuardrails": [
+      "never add `mark_safe`/`|safe` to route around an escaping error instead of fixing the underlying markup",
+      "never disable CSRF (`@csrf_exempt`, removing `CsrfViewMiddleware`) to make a failing request succeed",
+      "never hand-edit a generated migration file to dodge a `makemigrations` conflict without resolving the actual model drift",
+      "never widen a narrowed queryset/model field type or drop a validator just to make a check pass"
+    ]
+  }
+}

package/src/gdskills/bundled/stacks/django/rules/coding-style.mdc

@@ -0,0 +1,80 @@
+---
+extends: common
+paths: ["**/models.py", "**/models/**/*.py", "**/views.py", "**/views/**/*.py", "**/forms.py", "**/serializers.py", "**/urls.py", "**/admin.py", "**/*.py"]
+metadata:
+  origin: authored
+---
+
+# Django coding style
+
+Narrows `python`'s coding style to Django-project conventions. Applies to
+`*.py` files inside a Django project; non-Django Python in the same
+repository (a standalone script, a shared library package with no Django
+import) still comes from `python`'s own coding-style rule, not this file.
+
+## App and project layout
+
+- One Django "app" per cohesive domain concern (`billing/`, `accounts/`),
+  each with its own `models.py`/`views.py`/`urls.py`/`migrations/` — do not
+  grow a single app into an unrelated dumping ground once it outgrows one
+  clear responsibility.
+- Name an app's `urls.py` route names with the app as a namespace prefix
+  (`billing:invoice-detail`) and reverse them with `reverse()`/`{% url %}`,
+  never a hand-built path string, so a route can move without breaking every
+  caller.
+- Keep `settings.py` split by environment (`settings/base.py` +
+  `dev.py`/`prod.py`, or `django-environ`/`django-configurations`) when the
+  project already uses that layout; match the existing convention rather
+  than introducing a second settings-splitting scheme.
+
+## Models
+
+- Give every model field an explicit `verbose_name`/`help_text` when the
+  field name alone would not be self-explanatory to someone using the admin
+  or a generated form.
+- Use `related_name` on a `ForeignKey`/`ManyToManyField`/`OneToOneField`
+  whenever the default (`<model>_set`) would collide or read unclearly at
+  the call site; pick a name that reads naturally from the related side
+  (`author.books`, not `author.book_set`).
+- Put field-level defaults and choices near the field (`choices=Status.choices`
+  with a `TextChoices`/`IntegerChoices` enum), not a bare tuple of literal
+  strings repeated at each call site.
+- Override `save()`/add a `clean()` only for invariants that must hold for
+  every write path (including the admin and shell); a validation rule that
+  only applies to one form belongs on that `Form`, not the model.
+
+## Views and URLs
+
+- Prefer a class-based view (`ListView`, `DetailView`, `CreateView`, or a
+  DRF `APIView`/`ViewSet` when the project uses Django REST Framework) for
+  the framework's standard CRUD shapes; reach for a function-based view when
+  the logic does not map cleanly onto a generic view's hooks — current
+  Django guidance treats CBVs and FBVs as equally supported, not one as
+  deprecated.
+- Keep business logic out of the view body: a view coordinates
+  request/response and delegates the actual work to a model method, a form's
+  `clean`/`save`, or a service function — a view that inlines several
+  unrelated queries and branches is a sign the logic belongs elsewhere.
+- Name URL patterns and match the project's existing `path()`/`re_path()`
+  convention; prefer `path()` with converters (`<int:pk>`) over `re_path()`
+  unless the match genuinely needs a regex.
+
+## Forms and serializers
+
+- Validate with a `Form`/`ModelForm` (or DRF `Serializer`/`ModelSerializer`)
+  `clean_<field>`/`clean()`/`validate_<field>`/`validate()` method, not
+  ad-hoc validation scattered in the view after the fact.
+- Use `ModelForm`/`ModelSerializer` with an explicit `fields = [...]` list
+  (never `fields = "__all__"` on a form or serializer that accepts
+  user-submitted data) so a new model field is not silently exposed for
+  mass-assignment until it is deliberately added.
+
+## Imports and structure
+
+- Follow `python`'s stdlib/third-party/local import grouping; within
+  "third-party", Django's own imports (`django.db`, `django.http`, ...)
+  commonly sort before other third-party packages alphabetically — match
+  what the project's `ruff`/`isort` config already produces rather than
+  hand-ordering.
+- Import from `django.conf.settings`, never re-read environment variables
+  directly in application code that already has a settings value for it.

package/src/gdskills/bundled/stacks/django/rules/patterns.mdc

@@ -0,0 +1,92 @@
+---
+extends: common
+paths: ["**/models.py", "**/models/**/*.py", "**/views.py", "**/views/**/*.py", "**/managers.py", "**/migrations/**/*.py", "**/*.py"]
+metadata:
+  origin: authored
+---
+
+# Django patterns
+
+Narrows `python`'s design guidance to idiomatic Django (5.x) ORM, view, and
+migration patterns and the anti-patterns they replace. Applies to Django
+project files; a non-Django module in the same repo still follows `python`'s
+own `rules/patterns.mdc`.
+
+## Query optimization (the N+1 problem)
+
+- When a view or serializer will access a related object for every row in a
+  queryset (`obj.author.name` in a loop, or a DRF nested serializer field),
+  add `select_related("author")` for a `ForeignKey`/`OneToOneField` and
+  `prefetch_related("tags")` for a `ManyToManyField`/reverse `ForeignKey` —
+  `select_related` joins in one query; `prefetch_related` issues one extra
+  query per relation and joins in Python. Combine both when a
+  `prefetch_related` path itself needs a `select_related` (`Prefetch("best_pizza__toppings")`
+  after `select_related("best_pizza")`).
+- Use `only()`/`defer()` to trim columns from a wide model only when a
+  profiled query shows the extra columns matter; reaching for it by default
+  makes the queryset fragile to a later field access that silently triggers
+  a new query.
+- Prefer `QuerySet.exists()` over `bool(qs)`/`len(qs) > 0` for an
+  existence check, and `.count()` over `len(list(qs))`, so the database does
+  the work instead of materializing every row into Python.
+- Use `bulk_create`/`bulk_update`/`update()` for a batch write instead of a
+  Python loop calling `.save()` per instance — a per-instance loop is an N+1
+  on the write side, and skips `bulk_create`'s single round trip (note it
+  bypasses `save()`/signals unless explicitly configured to call them).
+
+## Migrations
+
+- Run `python manage.py makemigrations` to generate a migration from a model
+  change; never hand-write a migration's `operations` list to match a model
+  edit by guesswork — let Django diff the models, then review the generated
+  file.
+- Give a migration that needs to transform existing row data a `RunPython`
+  operation with both a forward and a reverse function (or
+  `migrations.RunPython.noop` when reversal is genuinely not meaningful),
+  not a schema-only migration that silently leaves old data inconsistent
+  with a new constraint.
+- Keep a destructive migration (dropping a column/table another release
+  still reads) behind a deploy sequence that ships the code change first,
+  then the schema change, when the project deploys code and migrations
+  separately — a same-release drop-and-read is a two-phase problem, not a
+  one-step migration.
+- Never edit a migration file that has already been applied in another
+  environment (shared branch, staging, production) to "fix" it in place;
+  add a new migration instead — editing history desyncs any environment
+  that already recorded the old migration as applied.
+
+## Models as the single source of truth
+
+- Put a field-level invariant (a `CheckConstraint`, a `unique_together`/
+  `UniqueConstraint`, a `validators=[...]` list) on the model field or
+  `Meta.constraints`, not only in a form's `clean()` — validation the
+  database itself does not enforce can still be violated by a direct
+  `.save()`, the admin, a shell, or another service writing to the same
+  table.
+- Use a model `Manager`/`QuerySet` subclass to name a repeated filter
+  (`Order.objects.pending()`) instead of repeating the same `.filter(...)`
+  chain at every call site.
+
+## Views
+
+- A view that only reads and renders/serializes belongs on a generic
+  class-based view (`ListView`/`DetailView`/DRF `ReadOnlyModelViewSet`); a
+  view with custom branching logic per HTTP method is a legitimate reason to
+  drop to a function-based view or override a specific CBV method
+  (`get_queryset`, `form_valid`) rather than reimplementing the whole
+  request/response cycle.
+- Return the framework's own response helpers (`HttpResponseRedirect`/
+  `redirect()`, `JsonResponse`, DRF's `Response`) instead of building a raw
+  `HttpResponse` with a hand-set `Content-Type` and manually serialized body.
+
+## Anti-patterns to flag, not introduce
+
+- A `for` loop over a queryset that touches a related object per iteration
+  with no `select_related`/`prefetch_related` upstream — this is Django's
+  most common performance bug and is invisible in a small dev dataset.
+- `fields = "__all__"` on a `ModelForm`/`ModelSerializer` that accepts
+  user input, silently exposing every future field for mass-assignment.
+- A signal handler (`post_save`, etc.) that performs a slow or
+  externally-visible side effect (sending an email, calling a third-party
+  API) synchronously inside the request/response cycle instead of queuing it
+  through the project's async task runner (Celery or equivalent).

package/src/gdskills/bundled/stacks/django/rules/security.mdc

@@ -0,0 +1,92 @@
+---
+extends: common
+paths: ["**/views.py", "**/views/**/*.py", "**/forms.py", "**/serializers.py", "**/templatetags/**/*.py", "**/settings*.py", "**/settings/**/*.py"]
+metadata:
+  origin: authored
+---
+
+# Django security
+
+Narrows `python`'s security guidance to Django's own injection-class sinks:
+views, forms/serializers, template-tag modules, and settings — the Python
+files where Django's built-in CSRF/XSS/SQL-injection protections are either
+relied on or bypassed (template-rendered `.html` files are not `.py`, so
+they are out of this rule's `paths:` scope by construction, even though the
+XSS guidance below still applies to what those views/templatetags render
+into them). Applies only to the listed `.py` files; a non-request-facing
+module (a standalone script, a batch job with no HTTP surface) still
+follows `python`'s own `rules/security.mdc`.
+
+## CSRF
+
+- Leave `django.middleware.csrf.CsrfViewMiddleware` enabled and let
+  `{% csrf_token %}`/the framework's CSRF cookie handling do its job for
+  every state-changing view (`POST`/`PUT`/`PATCH`/`DELETE`).
+- Never add `@csrf_exempt` to make a failing request succeed without first
+  establishing that the endpoint has another, equivalent protection (a
+  signed webhook signature, a non-browser API authenticated by token, never
+  session/cookie auth) — CSRF exemption on a session-authenticated endpoint
+  reopens the exact attack the middleware exists to block.
+- A DRF `APIView`/`ViewSet` using `SessionAuthentication` still needs CSRF
+  protection on unsafe methods (DRF enforces this by default for session
+  auth); do not disable it to work around a client that isn't sending the
+  token — fix the client to send it.
+
+## Cross-site scripting (XSS)
+
+- Rely on Django's automatic template auto-escaping for any value that
+  reaches an HTML template — do not disable it project-wide.
+- Never apply `mark_safe()`/the `|safe` template filter/`format_html()`'s
+  raw-string argument to a value that traces back to user input (a form
+  field, a query parameter, an uploaded file's name, anything stored from a
+  prior user submission) — `mark_safe`/`|safe` tell Django to skip escaping
+  entirely, and reintroduce stored or reflected XSS on exactly the value the
+  auto-escaper was protecting. `mark_safe`/`|safe` are for markup the
+  application itself constructs and fully controls (a trusted CMS field
+  rendered through a sanitizer, static admin-authored HTML) — never for
+  data supplied by a request.
+- Build dynamically-assembled HTML with `format_html()`/`format_html_join()`
+  (which escape each interpolated argument) instead of string
+  concatenation or an f-string passed to `mark_safe()`.
+
+## SQL injection
+
+- Django's ORM parameterizes query values automatically
+  (`.filter(name=user_input)`); this protection does not extend to
+  `.raw()` or `.extra()` — pass user-derived values through the `params`
+  argument (`Model.objects.raw("... WHERE id = %s", [id])`), never by
+  interpolating them into the SQL string with an f-string/`%`/`.format()`.
+- Treat `.extra()` as legacy; prefer expressing the same query with the ORM
+  (`annotate`, `F()`, `Q()`, `Func`) or a parameterized `.raw()` call — the
+  Django security team explicitly does not treat unsanitized input reaching
+  `.extra()`'s `select`/`where` clauses as a framework bug, because
+  `.extra()` was never given the ORM's own escaping.
+
+## Settings and secrets
+
+- `SECRET_KEY` must be at least 50 characters, unique per environment, never
+  the `django-insecure-` placeholder `startproject` generates, and never
+  committed to source — read it from the environment/secret store.
+- `DEBUG` must be `False` in any settings module used in production;
+  `DEBUG = True` leaks stack traces, local variable values, and settings
+  contents to any visitor who triggers an unhandled exception.
+- `ALLOWED_HOSTS` must be a real, non-empty list of the application's actual
+  hostnames in production, never `["*"]` — an empty or wildcard value
+  defeats the Host-header validation Django's deploy checks exist to
+  enforce.
+- Run `python manage.py check --deploy` before a production release; it
+  flags exactly these three (and related HSTS/secure-cookie) settings
+  automatically — don't hand-audit `settings.py` for them instead.
+
+## Red flags
+
+- "I'll add `|safe` here, this content only ever comes from an admin form" —
+  if that admin form field can ever hold end-user-influenced text (a
+  support agent pasting a customer's message, a bio field editable by the
+  account owner), the trust boundary already includes untrusted input.
+- "`.extra()` with an f-string is fine, this value is just an internal ID"
+  — an "internal" ID that ever originates from a URL param, form field, or
+  header is user-controlled regardless of how it's described; use `params`.
+- "`@csrf_exempt` unblocks this POST and the tests pass now" — passing
+  tests after exempting CSRF proves the exemption works, not that it's
+  safe; verify the endpoint has an equivalent protection first.

package/src/gdskills/bundled/stacks/django/rules/testing.mdc

@@ -0,0 +1,89 @@
+---
+extends: common
+paths: ["**/tests.py", "**/tests/**/*.py", "**/test_*.py", "**/*_test.py", "**/conftest.py"]
+metadata:
+  origin: authored
+---
+
+# Django testing
+
+Narrows `python`'s `pytest` testing guidance (`python/rules/testing.mdc`) to
+Django's own test tooling: the Django `TestCase`/test `Client`, fixtures and
+factories for model data, and `pytest-django` where a project has adopted
+it. Applies to Django test files; a non-Django test module in the same repo
+still follows `python`'s own testing rule.
+
+## Choosing the test base
+
+- Use `django.test.TestCase` for anything that touches the ORM — it wraps
+  each test in a transaction that rolls back afterward, so tests stay
+  isolated without manually cleaning up rows.
+- Use `django.test.SimpleTestCase` (or mark it `databases = []`
+  under `pytest-django`) for a test that touches no database at all — it
+  skips the per-test transaction wrapper and is faster for pure logic.
+- Where the project has adopted `pytest-django`, use its `@pytest.mark.django_db`
+  fixture-based style (plain `def test_x(db, client): ...` functions,
+  `django_user_model`, `rf` for `RequestFactory`) rather than mixing it with
+  `unittest`-style `TestCase` subclasses in the same suite — match whichever
+  the project already uses; do not introduce the other style alongside it.
+
+## The test client
+
+- Drive request/response behavior through `self.client`
+  (`TestCase`)/the `client` fixture (`pytest-django`), not by calling a view
+  function directly with a hand-built request object — the client exercises
+  URL resolution, middleware, and template rendering the same way a real
+  request does.
+- Assert on `response.status_code`, `response.context`, and
+  `response.templates` (or the parsed JSON body for an API) rather than
+  inspecting internal view state that the client's response object doesn't
+  expose.
+- Log a test user in through `self.client.force_login(user)` (fast, skips
+  the auth backend) or `self.client.login(...)` (exercises the real auth
+  backend) — pick `force_login` for tests where the auth mechanism itself
+  isn't what's under test.
+
+## Model data: fixtures and factories
+
+- Prefer a factory (`factory_boy`'s `DjangoModelFactory`, if the project
+  already depends on it) over a JSON/YAML fixture file for test data —
+  factories build valid model instances from code, so a new required field
+  doesn't silently break every fixture file that predates it.
+- Keep a `conftest.py`/factory module for related test data in the
+  narrowest app-level location that covers the tests needing it, matching
+  `python`'s own "narrowest `conftest.py`" guidance.
+- Build only the fields a test actually asserts on or that a model
+  constraint requires; a factory that sets every field to a fixed literal
+  makes tests brittle to unrelated schema changes.
+
+## Forms, views, and permissions
+
+- Test a `Form`/DRF `Serializer` by constructing it directly with test data
+  and asserting `is_valid()`/`.errors`, separately from a full
+  client-driven view test — this isolates a validation bug from a
+  view-wiring bug.
+- For a permission-gated view, assert both the authorized case (200/302 to
+  the expected page) and the unauthorized case (302 to login, or 403) —
+  a view test that only exercises the happy path never proves the
+  permission check actually runs.
+
+## Migrations in tests
+
+- Do not disable migrations for the whole suite (`MIGRATION_MODULES` set to
+  a no-op) purely for speed unless the project has already made that
+  tradeoff deliberately — a suite that skips migrations can pass while a
+  real deploy's migration path is broken.
+- A test asserting data-migration behavior (a `RunPython` step) belongs in
+  its own test using `django.test.migrations`' testing utilities or the
+  project's configured migration-test helper, not folded into an unrelated
+  model test.
+
+## Determinism
+
+- Freeze time (`freezegun`, or `pytest-django`'s equivalent) instead of
+  asserting against `timezone.now()` computed twice in the test and the
+  code under test — a real few-millisecond drift between the two calls is a
+  known source of flaky Django tests.
+- Never depend on a specific queryset row order unless the code under test
+  applies an explicit `order_by()` — Django does not guarantee row order
+  without one, even for a small SQLite test database.

package/src/gdskills/bundled/stacks/django/skills/django-build-fix/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: django-build-fix
+description: "Use when a Django project fails manage.py check, makemigrations/migrate, the test suite, or lint/type-check -- resolves migration conflicts and inconsistent migration history, ImproperlyConfigured settings errors, app-loading/circular-import errors, mypy/django-stubs type errors, and ruff failures with the smallest root-cause fix. Not for adding a feature (see django-implementation) or fixing test content (see django-testing)."
+triggers:
+  - "manage.py check is failing"
+  - "fix this django migration conflict"
+  - "django ImproperlyConfigured error"
+  - "django app isn't loading, circular import"
+  - "mypy is failing on this django model"
+  - "makemigrations wants to make a conflicting migration"
+  - "django test suite won't even start"
+metadata:
+  origin: authored
+  category: build-fix
+  version: "1.0.0"
+  compatible_harnesses: "claude,codex,cursor,zed,opencode"
+license: "MIT"
+---
+
+# Django build-fix
+
+Resolve a broken Django `check`/migration/settings/import/type-check/lint
+failure with the smallest change that fixes the actual cause. Scoped to
+making the Django toolchain green again — for adding a feature use
+`django-implementation`, for writing/fixing test *content* (not a collection
+or startup error) use `django-testing`, for reviewing without fixing use
+`django-code-review`.
+
+## Workflow
+
+### Step 1: Reproduce and classify the failure
+
+Run the project's own configured commands (discover the run prefix from
+`pyproject.toml`/lockfile presence):
+
+```bash
+python manage.py check
+python manage.py makemigrations --check --dry-run
+ruff check .
+ruff format --check .
+mypy .   # with django-stubs, if configured
+python manage.py test   # or: pytest, if pytest-django is configured
+```
+
+Read the *first* error in each tool's output. Classify:
+
+- **`ImproperlyConfigured`** — a required setting missing/misconfigured
+  (`SECRET_KEY`, `DATABASES`, `AUTH_USER_MODEL` pointing at a model that
+  doesn't exist), or an app used before `AppConfig.ready()`/app registry is
+  populated.
+- **Migration conflict** — two migrations in the same app both claim the
+  same `dependencies` leaf (usually from two branches adding migrations in
+  parallel), or `makemigrations --check` reports an unmigrated model change.
+- **App-loading / circular import** — a model or app imports another app's
+  model at module import time before Django's app registry is ready, or two
+  apps import each other's models directly instead of via a string reference
+  (`"otherapp.Model"`) in a `ForeignKey`.
+- **Type errors** — `mypy`/`django-stubs` reports a real mismatch, often
+  around manager/queryset generics or a model field's inferred type.
+- **Lint failures** — `ruff check` reports a rule violation.
+- **Test suite won't start** — an import error in a test file, `conftest.py`,
+  or a fixture referencing a model/setting that doesn't exist.
+
+### Step 2: Find the root cause
+
+- **`ImproperlyConfigured`**: read the exact message — it names the missing/
+  bad setting. Check the correct settings module is active
+  (`DJANGO_SETTINGS_MODULE`) before assuming the setting itself is wrong.
+- **Migration conflict**: run `python manage.py makemigrations --merge` to
+  generate a merge migration when two branches added divergent migrations
+  from the same parent — review the generated merge, don't hand-edit
+  `dependencies` to force a resolution. For an unmigrated model change,
+  run `makemigrations` for the actual diff instead of skipping the check.
+- **App-loading/circular import**: use a string reference
+  (`models.ForeignKey("otherapp.Model", ...)`) for a cross-app relation
+  instead of importing the model class directly; move an import that only
+  needs to run inside a function body (e.g. inside a signal handler) out of
+  module level if it's the actual cycle.
+- **Type errors**: read the exact mismatch; check `django-stubs` is
+  installed and configured (`mypy_django_plugin` in `mypy.ini`/
+  `pyproject.toml`) before assuming the type itself is wrong — a missing
+  plugin config produces spurious errors on manager/queryset types.
+- **Lint failures**: apply `ruff check --fix .` for mechanical fixes; fix
+  the code for a substantive rule, don't suppress it.
+- **Test suite won't start**: apply the same import-error diagnosis above to
+  the failing test/`conftest.py`'s own imports.
+
+### Step 3: Apply the smallest fix
+
+- Fix the actual cause identified in Step 2 — the missing setting, the
+  merge migration, the string-reference relation, the real type mismatch.
+- Touch only what the failure requires; do not refactor unrelated code
+  while fixing a build failure.
+- When a migration conflict needs a merge, generate it with
+  `makemigrations --merge` and review the result; never hand-edit
+  `dependencies`/`operations` to force a resolution.
+
+### Step 4: Verify
+
+Re-run every command from Step 1 in order; all must exit 0. Also run
+`python manage.py test`/`pytest` even when the original failure was only a
+lint/type error — a fix can introduce a runtime regression static tooling
+won't see.
+
+### Step 5: Report
+
+```
+Fixed: ImproperlyConfigured: AUTH_USER_MODEL refers to model 'accounts.Member'
+  that has not been installed
+  Root cause: settings.py set AUTH_USER_MODEL = "accounts.Member" but
+    "accounts" was missing from INSTALLED_APPS.
+  Fix: added "accounts" to INSTALLED_APPS
+  Verified: manage.py check, makemigrations --check, ruff, mypy, test all green
+```
+
+## Rules
+
+- NEVER hand-edit a migration's `dependencies`/`operations` to force past a
+  conflict — generate a merge migration with `makemigrations --merge` and
+  review it.
+- NEVER add `# type: ignore`/`# noqa` as a blanket suppression to make a
+  real error disappear without fixing or explicitly justifying it inline.
+- NEVER wrap a real settings/import error in a broad `try/except` to hide
+  it — fix the actual misconfiguration or import cycle.
+- Fix the root cause with the smallest change; do not refactor beyond what
+  the failure requires.
+
+## Red Flags
+
+| Rationalization | Why it is wrong |
+|---|---|
+| "I'll hand-edit the migration's `dependencies` to skip the conflict" | Desyncs the migration graph from what actually ran in other environments; generate a proper merge migration instead |
+| "I'll import the model directly instead of using a string reference to dodge the circular import" | Papers over the app-loading order problem instead of fixing it; use `\"otherapp.Model\"` string references for cross-app relations |
+| "mypy is noisy on Django models, I'll just add `# type: ignore` everywhere" | Usually means `django-stubs`'s mypy plugin isn't configured; fix the plugin config instead of suppressing every resulting error |
+| "`makemigrations --check` fails, I'll just skip the check in CI" | Hides real model/migration drift instead of fixing it; generate the missing migration |
+
+## Verification
+
+Do not report the fix done until all of the following hold:
+
+- The originally failing command now exits 0.
+- `python manage.py check`, `makemigrations --check --dry-run`, `ruff
+  check .`, `ruff format --check .`, `mypy .`, and the test suite (the
+  project's own configured equivalents) all exit 0.
+- No new `# type: ignore`/`# noqa` was added without an inline reason.
+- No migration file's `dependencies`/`operations` was hand-edited; a
+  conflict was resolved with a generated merge migration.
+- `git status` shows only the files whose actual cause was diagnosed in
+  Step 2 — no unrelated refactor.

package/src/gdskills/bundled/stacks/django/skills/django-build-fix/evals.json

@@ -0,0 +1,49 @@
+{
+  "triggers": {
+    "positive": [
+      "manage.py check is failing with ImproperlyConfigured, can you fix it",
+      "After merging release/2.1 into main, `makemigrations` reports two leaf nodes in the payments app's migration history for our Django project -- what's the right way to reconcile that before I merge?",
+      "Django app won't load, there's a circular import between two apps",
+      "Type-checking chokes on `Invoice.objects` with an incompatible-type error even though django-stubs is installed -- any idea why?",
+      "makemigrations wants to create a migration that conflicts with an existing one",
+      "Pytest blows up before collecting a single test in our Django app -- traceback points to a bad import inside conftest.py. What's going on?",
+      "ruff check is failing on this Django project"
+    ],
+    "negative": [
+      "Add a new feature to this Django view, the build is currently green",
+      "Write more pytest-django tests for this already-passing view",
+      "Review this Django migration for correctness, don't fix anything",
+      "Fix this ModuleNotFoundError in our plain Python script with no Django",
+      "Fix this FastAPI app that fails to start with a dependency resolution error",
+      "Fix this failing Jest test in our React frontend",
+      "npm run build is failing in our Node.js service"
+    ]
+  },
+  "scenarios": [
+    {
+      "id": "migration-conflict-merge-not-hand-edit",
+      "prompt": "Running `python manage.py makemigrations` fails with: 'Conflicting migrations detected; multiple leaf nodes in the migration graph: (0004_add_phone, 0004_add_address in accounts).' Fix it.",
+      "strictness": "high",
+      "expected_behavior": [
+        {
+          "grader": "judge",
+          "rubric": "A correct answer resolves a migration conflict with two leaf migrations by generating a merge migration (`python manage.py makemigrations --merge`) and reviewing the result, rather than hand-editing either migration's `dependencies` to force one order.",
+          "pass_criteria": [
+            "runs (or explicitly instructs running) `python manage.py makemigrations --merge` to generate a merge migration resolving the two leaf nodes",
+            "states that the generated merge migration should be reviewed before applying/committing it"
+          ],
+          "fail_criteria": [
+            "resolves the conflict by hand-editing one migration's `dependencies` list to point at the other, instead of generating a merge migration. Mentioning that hand-editing dependencies is unsafe only as a warning, while still recommending --merge, is not this failure."
+          ]
+        }
+      ],
+      "calibration": {
+        "known_right": "Run:\n```bash\npython manage.py makemigrations --merge\n```\nThis detects the two leaf migrations (`0004_add_phone` and `0004_add_address`, both children of the same parent) and generates a new migration, e.g. `0005_merge_20260925_1200.py`, whose `dependencies` list both leaves so the graph has a single path again. Review the generated file before committing -- confirm it doesn't silently drop any operation -- since `--merge` only needs a real conflict to resolve when both branches' changes are independent (as here, phone vs. address fields); if they touched the same field, the review step is where that would surface.",
+        "known_wrong": "Open `accounts/migrations/0004_add_address.py` and change its `dependencies` from `[(\"accounts\", \"0003_initial\")]` to `[(\"accounts\", \"0004_add_phone\")]` so it comes after `0004_add_phone` instead of being a sibling leaf. That resolves the 'multiple leaf nodes' error directly by hand-editing the dependency graph.",
+        "vague": "You need to merge the two migration branches together so there's only one path through the migration graph again.",
+        "subtle_wrong": "The cleanest fix here is to delete `0004_add_address.py` and regenerate it after `0004_add_phone` has been applied, so its `dependencies` naturally point at `0004_add_phone` instead of the shared parent -- that avoids needing a separate merge migration file at all and keeps the migration history linear."
+      },
+      "anti_patterns": ["hand-edit"]
+    }
+  ]
+}