Menu
Use when changing the GenCC SQLite schema. Coordinates schema.sql, the ingest builder/aggregates, and the repository together, then rebuilds the database and updates tests and fixtures.
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
Use when adding, renaming, or modifying this backend's FastAPI routes, dependencies, middleware, or response behavior.
Use when CI fails on a PR or main in gencc-link. Walks through reproducing make ci-local locally and root-causing without bypassing checks.
Use when adding, renaming, or removing an MCP tool in gencc-link. Walks through the tool module, facade registration, the capabilities TOOLS tuple, tests, and the README/connection-guide tables.
Use when preparing a versioned release of gencc-link. Walks through the pre-release checklist — ci-local green, CHANGELOG, version bump, valid docker config — then tagging and watching the release workflow.
| name | data-schema-change |
| description | Use when changing the GenCC SQLite schema. Coordinates schema.sql, the ingest builder/aggregates, and the repository together, then rebuilds the database and updates tests and fixtures. |
Use this skill when changing the shape of the local SQLite store — columns,
tables, indexes, FTS5 config, or the aggregated gene_disease roll-up. These
three layers must change together or queries will break at runtime.
gencc_link/data/schema.sql — the DDL: submissions, genes,
diseases, submitters, the aggregated gene_disease table, the
genes_fts / diseases_fts FTS5 indexes, and the single-row meta table.gencc_link/ingest/ — the builder that populates the schema:
parser.py parses the 31-column TSV (header validated against the column
order in gencc_link/constants.py);aggregates.py computes per-gene / per-disease / per-submitter and
per-(gene, disease) roll-ups, including consensus and conflict;builder.py writes rows + aggregates + FTS, sets the meta row, and does
the atomic rename.gencc_link/data/repository.py (+ queries.py) — the read-only query
layer that selects from those tables. Every changed column/table must be
reflected in the SQL here.Bump the schema version. If the change is not backward compatible with an
existing built database, bump SCHEMA_VERSION in gencc_link/constants.py
so stale databases are detected.
Edit schema.sql. Add/alter the table, column, index, or FTS definition.
Keep FTS5 columns and tokenizer consistent with the search queries.
Update the ingest builder. Adjust parser.py (if the source columns
changed — also update SUBMISSION_COLUMNS in constants.py),
aggregates.py (if a derived/aggregated value changed — consensus and
conflict logic lives in gencc_link/services/consensus.py and is applied at
build time), and builder.py (the INSERT/index/FTS population).
Update the repository. Edit repository.py / queries.py so reads match
the new schema. Update the service layer (gencc_link/services/) and any
Pydantic records (gencc_link/models/records.py) consuming the new fields.
Rebuild. Run make data (gencc-link-data build) to rebuild the live
database, then make data-info to confirm provenance and counts. Regenerate
the test fixture database if the schema changed (see the tests/fixtures/
sample TSV + built SQLite).
Tests. Update unit tests that assert table shape, repository results,
aggregates, consensus/conflict, and shaping. Run make test.
Docs. Update the data-store and consensus sections of
docs/architecture.md if the change is user-visible, and add a
CHANGELOG.md entry.
CI. Run make ci-local.