varlens-verify-before-done

Stars5

Forks1

UpdatedJuly 6, 2026 at 15:05

Use when about to claim a VarLens change is done, working, fixed, or ready to commit/PR — to pick and run the right make target for what you changed and report its actual output. Symptoms of about to skip this: "the diff looks clean", "types should pass", "this is a trivial change", "I'll let CI catch it", or claiming a UI change works without opening the app.

Installation

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.

Source

berntpopp

berntpopp/VarLens

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

More from this repository

same repository

varlens-cohort-parity

berntpopp/VarLens

Use when changing filtering, sorting, searching, column definitions, column metadata, or filter-related UI on the VarLens single-case variant view — or the cohort view — before deciding scope, writing the plan/spec, or opening the PR. Symptoms of about to violate: editing useFilterState.ts / FilterToolbar.vue / VariantTable.vue / variant-table/columns.ts and thinking "I'll add the cohort side later", "cohort is out of scope for this PR", or "the cohort view can catch up separately".

2026-07-065

varlens-native-rebuild

berntpopp/VarLens

Use when a VarLens test or app run fails to load the native SQLite module — errors like NODE_MODULE_VERSION mismatch, "compiled against a different Node.js version", ERR_MODULE_NOT_FOUND on out/main/db-worker.js, or "was compiled against a different Node.js ABI" — or BEFORE running vitest, the Electron app, or packaging, to rebuild the module for the correct ABI first.

2026-07-065

varlens-security-and-bug-scan

berntpopp/VarLens

Use when reviewing a VarLens change for security issues or bugs before commit/PR/merge — auditing IPC, Electron window/fuses, database-key, external-URL, or import code — or running a pre-merge scan. Symptoms: adding an IPC channel that takes untrusted input, changing webPreferences/fuses, handling SQLcipher keys, calling shell.openExternal, adding a dependency, or hunting a suspected bug in a diff.

2026-07-065

varlens-ipc-channel

berntpopp/VarLens

Use when adding, renaming, or changing an IPC channel between the VarLens renderer and main process — exposing new data or actions on window.api, wiring a new domain, or touching preload/contract/handler code. Symptoms include "how do I call main from the renderer", editing src/preload or src/main/ipc, a failing tests/shared/types/preload-contract.test.ts, or a renderer call that returns a SerializableError instead of data.

2026-07-065

varlens-ui-patterns

berntpopp/VarLens

Use when building or changing VarLens renderer UI — Vue 3 + Vuetify 4 components, dialogs, side panels, data tables, colors, backgrounds, hover states, or theme work. Symptoms of about to get it wrong: reaching for surface-variant or a hardcoded hex for a background, a v-data-table-server whose row expansion silently does nothing, adding console.log in a component, or styling that looks fine in light theme but breaks in dark.

2026-07-065

varlens-vcf-import

berntpopp/VarLens

Use when extending or debugging VarLens VCF import — mapping a new INFO field to a DB column, changing annotation parsing (VEP CSQ or SnpEff ANN), touching multi-allelic splitting, genotype/sample handling, SV/CNV/STR extension fields, or anything under src/main/import/vcf/. Also use before assuming which column holds the impact level vs the Sequence Ontology term.

2026-07-065

name	varlens-verify-before-done
description	Use when about to claim a VarLens change is done, working, fixed, or ready to commit/PR — to pick and run the right make target for what you changed and report its actual output. Symptoms of about to skip this: "the diff looks clean", "types should pass", "this is a trivial change", "I'll let CI catch it", or claiming a UI change works without opening the app.

VarLens: verify before claiming done

The rule

Run the relevant make target and report its actual outcome. Never infer success from a clean diff or from "it should work". Evidence before assertions. If you can't run verification in this environment, say so explicitly — don't imply it passed.

This is the repo's own top gate (make ci is the local minimum; make ci-full is the canonical go/no-go). For the general discipline see superpowers:verification-before-completion; this skill adds the VarLens command matrix.

Which target for which change

Your change touches	Run (minimum)
Any code at all	`make typecheck`
Anything you'll commit	`make ci` (lint-check + format-check + typecheck + rebuild-node + test)
Renderer, IPC, database, or workers	`make rebuild-node && make test` (then `make ci`)
Electron lifecycle, packaging, worker bootstrap, native module	`make ci-full` (includes startup smoke + packaged smoke)
A UI component	Build/run the app and look at it — `make dev` or `/run`. A diff that typechecks is not a working UI.

make ci deliberately serializes the heavy gates to bound peak memory. On this machine, wrap heavy runs in a memory cap: systemd-run --user --scope -p MemoryMax=16G make ci-full.

Order of operations (the native-ABI trap)

Tests run on the Node ABI; the app runs on the Electron ABI. make ci / make test need make rebuild-node first, or the SQLite module ABI-fails and the run is invalid — not a pass, not a real fail. If tests won't load out/main/db-worker.js or you see NODE_MODULE_VERSION errors, that's ABI, not your code — see varlens-native-rebuild.

Reporting

State what you ran and what it printed:

✅ "Ran make ci — lint, format, typecheck, and the full test suite passed (report the count make test prints)."
✅ "make test fails: useFilters.test.ts expects the new field. Fixing the test."
✅ "Typecheck passes. Could not run make ci-full here (no Electron display); startup smoke unverified."
❌ "Done — the change looks correct." (no command run)
❌ "This should pass CI." (prediction, not evidence)

Never

Never lower a coverage / lint / typecheck threshold to make a red suite green. Add tests or fix the code. Lowering the bar is a cover-up, not a fix. (Baselines like scripts/agent-health-baseline.json are not to be relaxed to fit new code either.)
Never claim a UI change works without opening the app. Screenshot or drive it.
Never report "tests pass" when they were skipped, or when the ABI was wrong. A skipped or ABI-failed run is not a pass — say which happened.