Install any skill in seconds. Free to start, no credit card required.
Get Started Free →generate-migration
Generate Django database migrations for Sentry.
Passed 23 of 23 test cases with the skill, and 12 of 23 without it.
and 17 more in the full report
11 fixed12 passed either way0 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 11 test cases the skill fixed. Same model, same prompt, with and without the skill.
My git branch has a merge conflict in migrations_lockfile.txt after another migration was merged to main. What automated Sentry CLI helper command should I run to resolve the lockfile collision and renumber the migration?
| Checked | Without skill | With skill |
|---|---|---|
| Recommends running bin/update-migration <migration_name>. | Missed | Passed |
The instructions your model reads when the skill loads.
Generate migrations automatically based on model changes:
sentry django makemigrations
For a specific app:
sentry django makemigrations <app_name>
Generate an empty migration (for data migrations or custom work):
sentry django makemigrations <app_name> --empty
__init__.pysentry django sqlmigrate <app_name> <migration_name> to verify the SQLsentry django migrate <app_name> — Sentry's migration framework runs its safety checks on apply, so this catches unsafe ops (missing is_post_deployment, unsafe column changes, etc.) before CI does.When editing a generated migration (e.g. swapping DeleteModel for SafeDeleteModel), leave the auto-generated is_post_deployment comment block in place. It documents a non-obvious flag with concrete guidance for future migration authors — useful context, not fluff. Only remove a comment if it's stale or contradicts the code.
Don't write tests that only exercise Django's ORM. Standard operations — create/update/delete, cascading deletes, unique-constraint enforcement — are provided by Django and Postgres and are assumed to work. Test your logic (business rules, signal receivers, custom managers/validation), not the framework's.
The exception to the above: a migration that backfills or transforms data is your logic, and it must have a test. Use the TestMigrations base class from sentry.testutils.cases; tests live in tests/sentry/migrations/.
Set app, migrate_from (the migration just before yours), and migrate_to (yours). Seed pre-migration rows in setup_before_migration(self, apps) using the historical model registry (apps.get_model("sentry", "MyModel")) — not a direct from sentry.models... import, since the current model may not match the schema at migrate_from. Then assert the post-migration state.
test cases passed, vs 12 / 23 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.