메뉴
Organize Django settings.py into clearly sectioned blocks with banner-style headers. Use proactively whenever modifying src/project/settings.py — adding new settings, removing settings, or restructuring sections.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Structure Django models with proper Meta classes, verbose names, and optimized indexes. Use when creating or reviewing Django models to ensure consistent ordering, correct verbose_name/verbose_name_plural, and database indexes aligned to actual query patterns. Also registers every model in the admin with a clean, fast-loading configuration.
Implement a Django feature following the opinionated architecture — prefixed ULID IDs, repository pattern, Pydantic DTOs, svcs service locator, project-scoped django-ninja API, Celery reliable signals, and layered tests. Use when the user asks to add a new entity, endpoint, app, or business logic in a Django project that follows these conventions.
Run linting, formatting, and static type checks on a Django project using ruff and pyrefly, and fix any issues found. Use after making code changes, before committing, or whenever the user asks to lint, format, or type-check the codebase.
Use Stripe-style prefixed ULID primary keys (e.g. `prd_01jq3v...`) for every Django model instead of integers or UUIDs. Use when setting up a new model, reviewing a schema that still uses auto-increment or UUID primary keys, or when the user mentions IDs, slugs, public identifiers, or referential debugging. Produces short readable prefixes, time-sortable values, and IDs that are safe to expose in URLs and logs.
Set up and write pytest tests for an op-django project — pytest-django configuration, Celery eager mode for reliable-signal tests, freezegun for time-sensitive logic, shared conftest fixtures for DTOs and svcs overrides, and the three-layer test convention (repository against a real DB, service against mocked repos, API through HTTP). Use when adding tests to a new project, writing tests for a new feature, setting up test infrastructure, or explaining how tests should be organized.
Set up a Django project into the op-django layout so the architecture, signals, and settings skills have a foundation to build on. Use when starting a new project from scratch, or when converting an existing Django project to follow this opinionated structure. Creates the src/project/ shell (ids, services registry, api, reliable signals), installs dependencies with uv, and establishes the per-app directory conventions.
| name | dj-settings |
| description | Organize Django settings.py into clearly sectioned blocks with banner-style headers. Use proactively whenever modifying src/project/settings.py — adding new settings, removing settings, or restructuring sections. |
| allowed-tools | Read, Edit |
When modifying src/project/settings.py, enforce this structure.
Every logical group of settings gets a banner header:
# =============================================================================
# SECTION NAME
# =============================================================================
# + 75 = characters)Settings must appear in this order. Omit sections that have no settings.
BASE_DIR (no banner — these are preamble)SECRET_KEY, DEBUG, ALLOWED_HOSTS, CORS, CSRF, cookie settingsINSTALLED_APPS, MIDDLEWAREROOT_URLCONF, WSGI_APPLICATIONAUTH_USER_MODEL, AUTH_PASSWORD_VALIDATORS, LOGIN_URLLANGUAGE_CODE, TIME_ZONE, USE_I18N, USE_TZSTATIC_URL, STATIC_ROOT, DEFAULT_AUTO_FIELDCELERY_* settingsINSTALLED_APPS Sub-groupingWithin INSTALLED_APPS, group entries with inline comments:
INSTALLED_APPS = [
# Django core
"django.contrib.admin",
...
# Third-party
"corsheaders",
...
# Project apps
"products.apps.ProductsConfig",
"orders.apps.OrdersConfig",
]
Project apps must use the dotted path to their AppConfig subclass (e.g., "myapp.apps.MyAppConfig"), not the short app name.
# https://docs.djangoproject.com/...)AUTH_PASSWORD_VALIDATORS compact — one dict per line when the only key is "NAME"