메뉴
Run all pending FS-side state migrations. Use after pulling changes that may have rewritten on-disk shapes (transcripts, work.json, agent.json). Called by /update and runnable directly. Does NOT run DB schema migrations — those auto-apply on backend boot.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | migrate |
| description | Run all pending FS-side state migrations. Use after pulling changes that may have rewritten on-disk shapes (transcripts, work.json, agent.json). Called by /update and runnable directly. Does NOT run DB schema migrations — those auto-apply on backend boot. |
Atelier has two migration surfaces:
| Surface | Where | When applied |
|---|---|---|
| SQLite schema | backend/src/infrastructure/database/migrations.py | Auto, on backend boot (initialize_database) |
| FS state (transcripts, JSON files) | scripts/migrate-*.py | Manual — this skill |
This skill runs everything in the second column. It exists so a contributor can pull a change to logged event shape (or any on-disk schema) and get their existing works migrated without hunting for the right script.
ls scripts/migrate-*.py 2>/dev/null
If nothing matches, say "no FS-side migrations registered" and stop. There's nothing to do.
For each scripts/migrate-*.py:
cd backend && uv run python ../scripts/<name>.py
The cd backend step is intentional — every migration script does sys.path.insert(0, "<repo>/backend") so it can import src.*, but it still runs better inside the backend venv that owns the dependency tree. uv run activates the venv on the fly.
Migrations must be idempotent — re-running them on already-migrated data is a no-op. That's the contract; don't try to track "have I run this already" state. If a contributor adds a non-idempotent script, that's a bug in the script.
Each script prints its own summary (e.g. "rewrote 3 transcripts; 12 already canonical"). Pass that through verbatim — don't summarise. The user wants the actual counts.
If any script exits non-zero, don't run the rest. Surface the error and ask the user how to proceed. A failed migration usually means either the input is in an unexpected state or the script has a bug — both warrant inspection before piling on more changes.
uv run python scripts/<name>.py directly. This skill is the "run everything pending" entry point./new-migration.Use /new-migration fs <slug> to scaffold a new scripts/migrate-<slug>.py from the canonical template. The naming convention (migrate-*.py) is what makes this skill auto-discover it.
Pull latest main, install dependencies, run any pending FS-side migrations, and remind the user to restart dev. Use when the user says "update", "pull latest", or "sync with main".
Start the Atelier dev servers (backend on 8001, frontend on 4173). Wraps scripts/dev.sh, scripts/dev-backend.sh, scripts/dev-frontend.sh. Use when the user wants to start, restart, or boot the local dev environment.
Scaffold a new migration. Two flavours — db (a step in backend/src/infrastructure/database/migrations.py) or fs (a new scripts/migrate-<slug>.py). Use when changing a SQL schema, transcript shape, or any on-disk JSON shape. Invoke as /new-migration db <slug> or /new-migration fs <slug>.
Run backend pytest with the right venv automatically. Optionally pass a path or test name to filter. Use when the user says "run tests", "test X", or after making changes that need verification.
Destructive cleanup of Atelier state — wraps scripts/wipe.sh. Use only when the user explicitly asks to wipe, reset, or start fresh. Requires the backend to be stopped first.