agentleFS
berntpoppberntpopp/gencc-link/.claude/skills/data-schema-change/SKILL.md

data-schema-change

Skill0 starsChanged 4 months agoMITView on GitHub

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.

We split this skill into the rules it gives an agent

7 rules. About 0 are common, 1 is distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Use this skill when changing the shape of the local SQLite store — columns, tables, indexes, FTS5 config, or the aggregated gene_disease …

    line 8
  2. Very specific:

    Bump the schema version: If the change is not backward compatible with an existing built database, bump SCHEMA_VERSION in …

    line 30
  3. Very specific:

    Edit schema.sql: Add/alter the table, column, index, or FTS definition.

    line 34
  4. Distinctive:

    Keep FTS5 columns and tokenizer consistent with the search queries.

    line 35
  5. Very specific:

    Rebuild: Run make data (gencc-link-data build) to rebuild the live database, then make data-info to confirm provenance and counts.

    line 47
  6. Very specific:

    Tests: Update unit tests that assert table shape, repository results, aggregates, consensus/conflict, and shaping.

    line 52
  7. Very specific:

    Docs: Update the data-store and consensus sections of docs/architecture.md if the change is user-visible, and add a CHANGELOG.md entry.

    line 55

≈ “Common” is an estimate: at least 1 in 5 of the 308,232 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Data schema change

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.

The three coupled layers

  1. 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.
  2. 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.
  3. 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.

Checklist

  1. 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.
  2. Edit schema.sql. Add/alter the table, column, index, or FTS definition. Keep FTS5 columns and tokenizer consistent with the search queries.
  3. 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).
  4. 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.
  5. 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).
  6. Tests. Update unit tests that assert table shape, repository results, aggregates, consensus/conflict, and shaping. Run make test.
  7. Docs. Update the data-store and consensus sections of docs/architecture.md if the change is user-visible, and add a CHANGELOG.md entry.
  8. CI. Run make ci-local.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.