Zen pre-checks

Produce a truthful verification result tied to the actual change. Do not treat a command list as proof it ran.

Make a repeatable scripted check the default for feature behavior and regressions. Reuse the project's actual harness or add a behavior-focused test when useful; for manual-only or non-behavioral work, record the reason and inspection evidence. Run the applicable project's typecheck, formatter/linter (for example Biome when actually configured), security checks, test suite, build and integration sweeps before proposing a PR. Missing tools, missing scripts, failures and explicit waivers are separate states, never guessed passes. A green CI run is evidence for its measured scope, not a substitute for inspecting the real behavior.

1. Read repository gate definitions, package scripts, task/spec acceptance and the actual diff, including new files. Identify affected behavior and the highest-risk boundary. Record the base/head and dirty state examined.
2. Select proportionate checks: existing type/lint/format/tests/build, a regression reproduction, route smoke checks, data/privacy boundaries or native/provider behavior as relevant. Respect explicitly waived gates, recording who waived what. Do not add ceremonial tests for a reversible edit or repeat implementation logic in a test.
3. Run independent checks in parallel only when they do not share generated outputs, services or state. Keep migrations, builds using the same output directory and dependent steps sequential. Capture command, working directory, timestamp, exit/result and output location.
4. Inspect rendered states for UI changes: desktop/mobile, loading/empty/error, keyboard focus, contrast, both themes and reduced motion as applicable. Compare to the brief/reference; a source review or screenshot file existing is not visual inspection.
5. Exercise the real boundary for native/provider/integration claims when authorized. Preserve credential state and label isolated fixtures. If unavailable, report Unknown with the missing prerequisite; do not substitute a mock or health check without stating its limits.
6. Investigate a failure before retrying unchanged. If a correction changes behavior, rerun the affected reproduction/checks. Stop broadening once required checks pass unless a new change or unresolved concern justifies more.
7. Save a LOG/DOC evidence report with per-criterion results using the check ledger. Link the task/run/diff; use actual record writes or standalone capture. Propose stale DOC corrections and retain the old evidence.

Report

Use Passed, Failed, Unknown and Waived accurately. Skipped/unavailable checks are Unknown unless an authorized waiver exists. An exit 0 with a refused model response is not a passed acceptance scenario. State exactly which requested behavior remains unverified.

This mode prepares Review. It does not commit, push, merge, deploy, mark Done, run an unselected model or expand execution permissions. See shared authority.

Skill settings

The owner's settings for this skill arrive in a "Skill settings" block. Honour them.

• checkDepth (quick or full; default full):
  • Quick: the type checks and the main test suite the project defines.
  • Full: everything the project defines for checking, including the build and any format or lint scripts.

Whichever depth runs, list each check with its result (passed, failed or not run) and say why any check was not run. Use full before work is shared.