check

name	check
description	Run the DARE backend's local check suite — Black, isort, and the Django test suite — before opening a pull request. Use when the user is about to commit, push, or open a PR, or asks whether their change passes CI.

Check the DARE backend before a PR

Run these from an activated venv at the repo root. All three must pass before a PR is opened — they are the same checks CI runs.

black --check .
isort -c .
python manage.py test

If formatting fails, apply it rather than hand-editing:

black .
isort .

If the change touches models

Generate and commit the migration in the same PR as the model change:

python manage.py makemigrations

Review the generated file before committing. An unreviewed makemigrations can pick up drift from someone else's unmerged model change, or emit a destructive operation you did not intend.

Check that the migration graph still has a single leaf per app:

python manage.py showmigrations

If the change touches the API

Regenerate the OpenAPI schema so docs/api/dare-backend.md and the served schema stay in sync with the code.

Branch and PR conventions

Feature branches are cut from dev, not main:

git checkout dev
git pull --ff-only origin dev
git checkout -b your-name/feature/short-description

Naming is <author>/<feature|fix|refactor|docs|chore>/<short-description>.

The PR description should cover what, why, how, and how it was tested, plus screenshots for any user-facing or API-shape change and migration notes if the change is backwards-incompatible.

Related

• CONTRIBUTING.md — the full contribution guide this skill summarizes.
• rules.md — the repo's coding standards, in detail.