Django Code One Task

This documentation was generated with the assistance of AI. Please report any inaccuracies.

Carry out one task from a Django implementation_plan.md — the implementation, its tests, the migration a model change needs, and the checkbox update — against the real codebase, and nothing else. It is the narrowest execution unit for Django projects in the iru-code pipeline and runs on a medium model, since the plan already carries the hard reasoning and the code agreements live in the skill’s reference/ directory.

Purpose

Django forgives some mistakes silently: a ModelSerializer with fields = "all", an unscoped get_queryset(), a side effect fired inside a transaction that later rolls back, an N+1 loop, a model change without its migration. iru-django-code-one-task first detects the project’s shape from files rather than assuming the catalog scaffold: the runner prefix (uv run, poetry run, pdm run, pipenv run, .venv/bin/, bare python -m), the manage.py root and Django version, the settings and test-settings modules, the app layout, the API style (DRF, Django Ninja or plain views), the test runner (pytest-django or manage.py test), factories, type checker, docstring convention, and the fast-versus-integration split. It then reads reference/README.md and only the reference files the task needs: code-style.md and testing.md always, plus topic files such as models-and-orm.md, drf.md, security.md or auth.md. For a task that adds or changes a screen, component or list (a page template, a partial or inclusion tag, a paginated list, an htmx fragment) it also reads ui-contract.md and ui-implementation.md and applies the catalog’s UI contract (see Building user interfaces): it decomposes the UI into a Screen › Region › Component tree first, builds leaves first as inclusion tags or partials, paginates every list with one item partial per row instead of looping over an unbounded queryset, and writes pytest-playwright UI tests with an LTR/RTL × light/dark screenshot matrix and axe accessibility checks. Step 1 additionally detects the UI test wiring (pytest-playwright, axe-playwright-python, a ui marker, tests/ui/ui_screenshots.py, .ui-quality.yml, LocaleMiddleware with an RTL language, HTMX/Stimulus/Alpine/django-components).

The migration is part of the task. When a model changes, the skill generates it with manage.py makemigrations (never by hand, except data migrations), verifies makemigrations --check reports no changes, and reads the generated file for rename and non-null pitfalls. Applied migrations are never edited or deleted. Non-negotiables enforced while implementing: thin views over services, every input through an explicit-field form/serializer/schema, user-scoped querysets, no N+1 with a query-count assertion, type annotations and docstrings on new code, no new dependency or settings restructure unless asked, and no debugging leftovers. A task that would require insecure or data-losing code is reported with a safe alternative rather than implemented.

Purpose group

Python Development Tooling

Plugin

Shipped by the iru-python plugin of the ai-catalog marketplace (install with /plugin install iru-python@ai-catalog; see Plugins).

Invocation

/iru-django-code-one-task <task description>

Inputs

Argument Required Description Default

task description

Yes

The task’s own text from the plan, including its exact implementation_plan.md checkbox line(s), so the right box can be checked off.

None.

Outputs

  • Source and test changes for the single task, following the detected project’s conventions and the neighbouring code’s style (security and data-integrity rules always win over an insecure neighbour).

  • Any migration the task’s model change needs, generated by makemigrations and reviewed, plus the app’s own INSTALLED_APPS or root URLconf entry when the task creates the app or route.

  • New or updated tests in the right tier: fast tests (SQLite in memory, no service) run and green; integration tests (PostgreSQL, Redis, Celery, live server, browser) written but never run. No test scaffolding is created for projects with no test setup.

  • The task’s own checkbox (and covered sub-tasks) flipped to [x] in implementation_plan.md with a note naming the files touched and "group validation pending".

  • For UI work: browser UI tests under tests/ui/ (ui marker, live_server) covering every visual state with minimal/typical/many-items data, capturing each state × .ui-quality.yml direction × theme through tests/ui/ui_screenshots.py (capture_ui_state, created from ui-implementation.md when absent) into .ui-screenshots/ and calling check_accessibility(page) — written but never run by this skill. When pytest-playwright or axe-playwright-python is not a dependency, only template-rendering unit tests are written and the missing wiring is reported.

  • A short report: detected shape and reference files read, files touched, every migration generated, tests added or run, for UI work the Screen › Region › Component tree and the UI tests written with their <kind>/<Id> entries, any blocker, any deliberate deviation from reference/, and any insecure or N+1 neighbouring code left alone.

  • It never captures a baseline, adds license headers, audits docstrings, runs coverage, mypy, the Django system checks, the full suite, or any integration or UI test.

Execution flow

flowchart TD A["Start /iru-django-code-one-task\n(task text + checkbox line)"] --> B["Step 1: detect runner, Django version,\nsettings, app layout, API style, test runner"] B --> C["Read reference README, code-style,\ntesting and topic files the task needs"] C --> D["Step 2: re-check current code\nand neighbouring conventions"] D --> E["Step 3: implement exactly what the task\nspecifies, generate migration if a model changed;\nUI: decompose Screen > Region > Component first"] E --> F{"Blocker or insecure\nrequirement?"} F -- yes --> G["Step 4: ask the user or\nreport blocked, leave checkbox"] F -- no --> H["Step 5: write or update tests\nfast, integration and (UI work) browser UI tests"] H --> I["Step 6: run only the fast\ntest files touched"] I --> J{"Fast tests green?"} J -- no --> K["Fix code or test,\nre-run"] K --> I J -- yes --> L["Step 7: check off this task's\ncheckbox, group validation pending"] L --> M["Step 8: report outcome\nto the caller"] G --> M

Dependencies

Invokes

None — iru-django-code-one-task does not call other skills; it reads its own reference/ files and runs manage.py makemigrations, formatter and fast test commands directly.

Invoked by

Related agents

None — it spawns no agents itself. Its caller may run several instances in parallel agents, except for tasks that change models in the same app or share a file.

Source

SKILL.md on GitHub — the file this page was generated from.