Menu
Add a new SQLite schema migration to storage.py
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | new-migration |
| description | Add a new SQLite schema migration to storage.py |
| disable-model-invocation | true |
The general flow (worktree, TDD, lint) is in CLAUDE.md and /tdd. The
schema-migration mechanics are visible in storage.py — the
_CURRENT_VERSION constant and _MIGRATIONS dict show every prior
migration as a worked example. This skill captures only the
migration-specific gotchas:
Bump _CURRENT_VERSION in storage.py by exactly 1 — never skip
numbers, never reuse one. Version collisions across concurrent
agent worktrees are the main reason CLAUDE.md mandates worktree
isolation; check the diff at PR time to confirm no other agent
shipped the same number while you were branched.
Migrations must be idempotent. Use CREATE TABLE IF NOT EXISTS
and CREATE INDEX IF NOT EXISTS. SQLite's ALTER TABLE is
add-column-only — no drops, no renames. Plan accordingly.
One migration per logical schema change. Don't bundle unrelated
table creations into one version — it makes rollback reasoning and
the RELEASES.md entry harder.
Update CLAUDE.md's Stack table with the new schema version when
the migration ships (per /pr-checklist).
Use the storage fixture for tests — it runs all migrations
on an in-memory database, so a TDD red-step will fail with
"no such table" until the migration lands. That's the intended
signal.
Reference for deploying to the Raspberry Pi
Review code changes against the HelmLog-specific data licensing policy (docs/data-licensing.md) — embargoes, protest firewall, biometrics consent, gambling exclusion, fleet-benchmark thresholds, coach access expiry. The model recovers general PII / cross-tenant / audit-logging concerns by default; this skill encodes only the HelmLog-specific items that are not recoverable from general engineering judgment. TRIGGER when modifying code that handles user data, PII, co-op/federation data sharing, export endpoints, deletion/anonymization, or audit logging. Key files — storage.py, export.py, peer_api.py, peer_client.py, federation.py, transcribe.py, audio.py, web.py (data endpoints). DO NOT trigger for UI-only changes, instrument decoding, polar analysis, config, docs, or CSS/JS/templates.
Run pre-PR verification checks before creating a pull request. TRIGGER when implementation is complete and the user is ready to create or push a PR — e.g., "create a PR", "ready for review", "push this up", or running /pr-checklist. DO NOT trigger mid-implementation, during TDD cycles, when exploring code, or when the user is still writing features.
HelmLog-specific test patterns and the pre-existing-error allowlist for ruff/mypy. The Red-Green-Refactor cycle and lint commands are already mandated in CLAUDE.md — this skill encodes only the patterns and known-pre-existing-errors list that aren't recoverable from existing tests at a glance. TRIGGER when writing or modifying Python source code in src/helmlog/. DO NOT trigger for documentation, config, templates, CSS/JS, skill definitions, or changes that don't affect runtime behavior.
Run a focused per-race debrief and attach the summary as a moment on the session. TRIGGER when the user says "debrief race N", "debrief that race", "/debrief", "post-race analysis", or asks for analysis of a single specific race. DO NOT trigger for season-wide reviews (that's a manual run of scripts/analysis/full_analysis.py), broad questions about boat performance, or non-race sessions.
Detect OCS (over-the-line at gun, returned to clear) races against the live DB and apply the 'ocs' tag to any newly identified ones. TRIGGER when the user asks "check for OCS", "did we OCS", "tag OCS races", "/ocs-check", or after a race day to find any starts that should be marked OCS. Auto-trigger when running /debrief on a race that hasn't been OCS-checked yet.
