test-readiness-preflight

Test Readiness Preflight

Purpose

Use this skill to turn obvious future test failures into implementation tasks before starting the full test gate. The full gate confirms readiness; it must never be the discovery mechanism.

The output is a readiness verdict with an explicit status: READY (checklist clean, exact full-gate command named), CONDITIONAL (validation can start, with named residual risks), or BLOCKED (specific blockers listed as implementation tasks). Do not claim the development task is done until code, schema, migrations, generated clients, fixtures, and release-order proof are all handled.

Operating Rules

• Treat this as a mandatory gate before expensive full-suite, container, Playwright, release, or push-readiness validation.
• Start from repo truth: parent and repo-local AGENTS.md, package scripts, test configs, Docker files, seed/migration scripts, and workflow docs.
• Prefer repo-provided wrappers and container lanes. Do not invent a parallel validation path when the repo already defines one.
• Develop tests alongside code. Do not wait for the expensive full gate to discover missing unit coverage, missing integration coverage, or untested user actions.
• Fix missing tests, data setup, migrations, fixtures, browser setup, env gaps, and stale local state before running the full gate.
• For changed logic, services, hooks, helpers, API routes, components, or workflows, add focused tests in the same implementation pass and run the cheapest relevant targeted test or coverage command before the full gate.
• Treat schema-affecting changes as release-sequencing work, not just test setup. Code must not be pushed, merged, deployed, or promoted when it depends on a database schema that is not already present in the target environment or safely introduced through the repo's migration release process.
• Prefer expand -> deploy -> contract for production databases: add backward-compatible schema first, deploy compatible code second, and remove old schema only in a later release after compatibility is proven.
• Secret scans must be repo-scoped and containerized when no repo wrapper already provides that isolation. Resolve the git repo root first and mount only that repo read-only into the gitleaks container.
• Never run gitleaks against /, $HOME, the OS user-folder root, your workspace root (e.g. ~/workspace), or any parent workspace. Never use an unqualified --source . unless the command is already running inside the repo-scoped container or a verified repo wrapper.
• Do not lower thresholds, skip required suites, delete failing assertions, or rely on remote CI/CD to find issues.
• A coverage failure is not a stop condition. Classify it per references/coverage-failure-response.md — the single source for the classification — fix changed-scope gaps, correct proven coverage misconfiguration, or report the task explicitly incomplete.
• In container-gated repos, aim for coverage margin above the threshold before the expensive container gate. A host result of exactly 90.00% is too fragile when the container can account branches differently.
• Use cheap inspection and setup commands freely. Avoid launching the full expensive gate until the checklist is clean.
• Ask before destructive resets that could erase user data, local dev databases, non-test Docker volumes, or uncommitted work.