Run this repository's gates on the work about to be committed — the backtest suite, and the quality score for every staged `.qmd`, `.tex` or `.R` file — and stop the commit if one fails. Claude Code tells Claude to run a project skill named `verify` right before committing (not for docs-only or tests-only commits); also use it when the user says "verify", "run the gates", "check before I commit", or "is this ready to commit?". It checks and reports; it never commits, pushes or fixes anything itself.
A source-grounded starter task has not been verified for this skill yet.
SKILL.md
name: verifydescription: Run this repository's gates on the work about to be committed — the backtest suite, and the quality score for every staged `.qmd`, `.tex` or `.R` file — and stop the commit if one fails. Claude Code tells Claude to run a project skill named `verify` right before committing (not for docs-only or tests-only commits); also use it when the user says "verify", "run the gates", "check before I commit", or "is this ready to commit?". It checks and reports; it never commits, pushes or fixes anything itself.allowed-tools: ["Bash", "Read"]effort: low
/verify — the gates, before a commit
Since Claude Code 2.1.286, Claude is told to run a project skill named verify right before it commits, except for docs-only and tests-only commits. This one runs the same gates /commit runs. It is a reminder, not enforcement: Claude can skip it, and an exempt commit never triggers it, even one that changes a .qmd or .tex file. The enforcing gates are the git pre-commit hook (./scripts/install-hooks.sh) and /commit. It does not commit, push, stage, or edit anything.
Steps
Is the git hook already doing this? Run git config --get core.hooksPath. If it prints .githooks, the pre-commit hook will run the backtest and the quality gate on this commit anyway. Say so in one line and stop, because running everything twice wastes a minute and adds nothing.
Run the backtest:./scripts/backtest.sh. Capture the exit code and the last lines. A non-zero exit fails /verify; report the failing gate's own message, not a summary of it.
Score staged prose and code: for each staged file ending in .qmd, .tex or .R (git diff --cached --name-only --diff-filter=ACMR), run python3 scripts/quality_score.py <file>. A score below 80 fails /verify.
Report. One line per check (PASS / FAIL, with the score or the gate's message), then the verdict.
FAIL: do not commit. Say what failed and what fixes it.
PASS: say the commit can go ahead.
If the user has explicitly said "commit anyway" or "skip quality gate", pass that on: /commit records such an override as SKIP_QUALITY_GATE=1, which skips only the quality score. Never suggest git commit --no-verify.
Not this skill's job
Fixing what failed (do that, then run /verify again), writing the commit message (/commit), and deciding whether a change is wanted (the user). A gate that cannot run, such as a missing interpreter or a script error, is a FAIL, not a pass.