Assumes Claude's competence — no generic 'what is a migration' preamble — and every section covers non-obvious PostHog-specific hazards (hot-table locks, cross-language NOT NULL, CI guards) that Claude does not already know, so each token earns its place; not level 2 because it is not padded with general knowledge, though a few narrative asides could be trimmed.

Gives copy-paste-ready commands and named helpers — 'DEBUG=1 ./manage.py makemigrations', 'python manage.py rebase_migration <app>', 'SafeAddIndexConcurrently', 'AddForeignKeyNotValid' — and complete executable code for db_default= and RunSQL, matching the level-3 fully-executable anchor.

An explicit Classify → Generate → Apply safety rules → Validate workflow with validation checkpoints ('./manage.py sqlmigrate', run tests, confirm linear sequence), a sequenced retire-model procedure with deploy-cycle waits, and verify/feedback loops ('sqlmigrate', 'makemigrations --dry-run') for destructive DB operations, matching the level-3 anchor.

Opens with 'Read these files first' pointing to four well-signaled one-level-deep doc paths, then keeps the overview inline with content appropriately split; references are clearly navigable rather than monolithic or nested, matching the level-3 anchor.

Lists multiple concrete actions — 'creating, adjusting, or reviewing Django/Postgres migrations, including non-blocking index/constraint changes, multi-phase schema changes, data backfills, migration conflict rebasing, and product model moves' — plus deletions; matches the level-3 anchor of multiple specific concrete actions.

Explicitly answers both 'what' ('Django migration patterns and safety workflow for PostHog') and 'when' via an explicit 'Use when...' clause plus 'Also use for any deletion or removal...', matching the level-3 anchor for both what AND when.

Natural user-facing terms abound — 'Django/Postgres migrations', 'deletion or removal of a model, table, column, product, or app', 'deleting migration files', 'retiring a feature'; good coverage of phrasings users would say, matching the level-3 anchor.

Clear narrow niche (PostHog Django/Postgres migrations) with distinct triggers and an explicit hand-off ('If the task is a ClickHouse migration, use clickhouse-migrations instead'), making conflict unlikely; matches the level-3 anchor.