메뉴
Enforces Alembic migration conventions when creating or editing migrations, models, or running alembic commands. Trigger when touching migrations/versions/, db/models.py, or adding/removing columns.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Browser automation, UX review, frontend debugging, E2E test writing, mock endpoint catalog. Trigger when asked to review UX, debug the dashboard, write E2E tests, take screenshots, or inspect pages. Also trigger when `stank-frontend-patterns` fires and introduces new components/pages/test-ids.
Enforces stank-bot scoring invariants when editing scoring_service.py, chain_service.py, or scoring-related settings. Trigger when modifying SP/PP formulas, position bonuses, finish bonus, Team Player, or ScoringConfig.
Conventions for stank-bot's per-guild embed templates (board, record, session-start/end, points, cooldown). Trigger when editing src/stankbot/services/template_engine.py, board_renderer.py, template_store.py, embed_builders.py, default template strings, or dashboard routes that author templates.
Enforces stank-bot's SvelteKit frontend conventions — component hierarchy, store barrel, shared utilities, testing patterns. Trigger when editing any file under src/stankbot/web/frontend/src/ or creating new Svelte/TS modules there.
WebSocket message type constants (frontend MsgType enum vs backend MSG_TYPE_* in ws.py) must stay in sync. Trigger when editing src/stankbot/web/ws.py, src/stankbot/web/frontend/src/lib/ws.ts, or src/stankbot/web/frontend/src/lib/ws.test.ts.
Enforces stank-bot's event-sourcing invariants when writing code that mutates domain state. Trigger when adding/editing any code path that changes player totals, chain state, sessions, records, or achievements — i.e. anything in src/stankbot/services/* or repositories that writes to the DB. Also trigger when writing rebuild/backfill scripts that touch totals.
| name | stank-db-migrations |
| description | Enforces Alembic migration conventions when creating or editing migrations, models, or running alembic commands. Trigger when touching migrations/versions/, db/models.py, or adding/removing columns. |
down_revision must match the current head. Run alembic history to confirm the latest revision ID before writing a new migration. The chain has broken twice from incorrect down_revision — this is non-negotiable.
Every migration must have both upgrade() and downgrade(). Even if downgrade is destructive (drops a column with data), it must exist for rollback capability.
Naming convention: YYYYMMDD_HHMM_short_description.py. Revision IDs are 12-char alphanumeric strings (e.g. a1b2c3d4e5f6).
Never modify a deployed migration. Once a migration has been pushed to main and deployed, it is immutable. Create a new migration to fix issues. The only exception is fixing a typo in a comment before the next deploy.
Partial indexes need both postgresql_where and sqlite_where. The project runs SQLite in dev and PostgreSQL in production. Any conditional index must specify the WHERE clause for both dialects.
Test reversibility locally: After creating a migration, run alembic upgrade head then alembic downgrade -1 to verify the round-trip works on the dev SQLite DB.
Column additions on large tables should be nullable or have server defaults. Adding a NOT NULL column without a default requires a backfill — do that in a separate migration step or use server_default and remove it in a follow-up.
Import models inside the migration function, not at module top level. This avoids model-import-order issues when Alembic runs migrations in sequence.
