check

name	check
description	Run local quality checks (typecheck, lint, build, tests). Quick check during development.

Local Quality Check

Run all local quality checks. Use during development to verify the current state quickly.

Steps

Run these sequentially and report results:

0. Worktree pre-flight: confirm root node_modules/ exists in the cwd:

   [ -d node_modules ] || pnpm install --frozen-lockfile
   

   git worktree add does NOT copy node_modules, and in a fresh worktree vp check fails with an UNNAMED typescript(tsconfig-error): Invalid tsconfig — Cannot find type definition file for 'node' (no file path in the message), which reads like a broken fixture tsconfig and sends you hunting in the wrong place. /verify-pr step 0 has the same pre-flight; this copy exists because /check is usually the FIRST skill run in a fresh worktree.

1. vp check --fix — typecheck + lint + Prettier formatting, with auto-fix. Then vp run check — the EXACT command CI's check-build-test job runs. The two are NOT equivalent: vp check --fix has passed 0-errors while vp run check failed with a TS7053 error on the same tree (observed 2026-08-09 on PR #1372 — an implicit-any union index the --fix invocation never surfaced, plus a no-base-to-string that --fix reported as a warning but CI failed as an error). Run both; CI parity comes from the second. Use this, not vp run lint:fix: the CI workflow runs vp check (which includes Prettier), and lint:fix does NOT touch Prettier formatting — so a lint:fix-only run passes locally but CI fails with Formatting issues found on the same branch. See memory rule feedback_vp_check_vs_lint_fix.md for the underlying gotcha and PR #363 for a concrete trap.

2. vp run typecheck:test — type-checks tsconfig.test.json (the tests/** project). vp check above only type-checks tsconfig.json (src/ + types/), which excludes **/*.test.ts — so a wrong import type or a stale mock shape in a test file would pass vp check AND vp test (whose "Type Errors" line only covers *.test-d.ts). This step is what makes test-file type errors fail locally the same way CI now fails them (issue #1133).

3. vp run build

4. vp test run — the whole unit suite. Prefer this over vp run test, even though that is the spelling CI uses and the test task delegates to exactly this command: nothing sits between the caller and the verdict. Measured on this repo 2026-08-31, both spellings on the same 17,497 tests: vp test run prints 15 lines / 617 bytes, vp run test 17 lines / 651 bytes. The gap used to be 260x, and closing it is what the cache: false change bought. While the test task still cached, vp run test gave the child a TTY, so vitest switched to its per-file reporter with console interception on: 1,981 lines / 171 KB for a green run. It could also exit 0 having run NOTHING, when the cache encoder overflowed while serialising the task's inputs (Cache lookup failed: Encoded sequence length exceeded preallocation limit, no Test Files line, rc=0). Both are gone with the cache; vp test run never had either. Read the summary line, not just the exit code: a run that reports no Test Files count did not run.

Output

Report as a table:

Check	Result
typecheck + lint + format (vp check --fix)	pass/fail
test-project typecheck (vp run typecheck:test)	pass/fail
build	pass/fail
tests (N files, M tests) (vp test run)	pass/fail

If all pass, confirm "All checks passed." If any fail, show the error output and STOP — do not write the commit-gate marker.

Commit-gate marker (on success only)

After all four checks pass, record a marker so the PreToolUse check-gate hook (see .claude/hooks/check-gate.sh) allows the next git commit. The marker is managed by markgate and captures the current working tree state; any subsequent edits invalidate it and require re-running /check.

Merely CREATING a file inside a gate's scope stales that gate — no edit to an existing file, and no commit. An untracked file counts: the digest covers the scope's file SET, so a new path appearing in it changes the digest the moment the file exists. Measured 2026-08-20 in a feature worktree, markers otherwise fresh: creating an untracked tests/_probe.ts flipped markgate verify check from rc=0 to rc=1, and deleting it flipped it back to rc=0. git commit is not the trigger — the staleness is already there before you commit.

It is scope-dependent, which is what makes it confusing rather than merely surprising: in the same measurement docs stayed rc=0 throughout, because tests/** is not in its scope. So the same action stales one gate, both, or neither depending only on where the file landed — a new file under tests/** stales check alone, one under .github/workflows/release.yml or CONTRIBUTING.md stales neither. The measurement's third case is now stale rather than wrong: it recorded three untracked files under .claude/hooks/ leaving BOTH gates at rc=0, and .claude/hooks/** joined the check scope in issue #2381, so that path now stales check. (Derived from the include list, not re-measured.)

This is correct behaviour, not a defect — a new test file genuinely means the recorded run no longer covers the tree. But the symptom is a check-gate refusal that reads as "my markers randomly expired", so it gets debugged instead of re-run. Re-run the skill; do not investigate. /verify-pr re-sets both markers in one shot.

Run this from the repo root (cdkd pins markgate via mise, so use mise exec to avoid PATH issues when shims aren't active):

mise exec -- markgate set check

Skip this step if any check failed — a stale or missing marker correctly forces the user (or Claude) to re-run /check after fixing the failure.