yq-pre-push-checks

Pre-Push Checks

Establish relevant evidence once before a push or readiness claim. This skill does not authorize committing, pushing, changing PR state, bypassing hooks, or rewriting history; those actions require the user's request or existing task scope.

The normal order is inspect scope, validate, commit if authorized, push if authorized, then verify the remote and CI. A stack-management tool that rebases and publishes several branches as one indivisible operation is the exception: record the pre-state, run it only when authorized, validate every rewritten layer immediately afterward, and block merge until the evidence passes.

Inspect the outgoing change

1. Confirm the repository, branch, worktree, and dirty state.

git rev-parse --show-toplevel
git status --short --branch
git branch --show-current

1. Read applicable repository instructions and discover what hooks, package scripts, task runners, CI jobs, generated artifacts, and test frameworks actually exist.
2. Verify the live PR base, upstream, or stack parent from current remote state. Fetch the exact ref when needed; do not guess main, master, or an old local tracking ref.
3. Inspect the complete outgoing scope: committed changes from the resolved merge base plus staged, unstaged, and relevant untracked files. Use the repository's change-scope tool when it has one; otherwise combine git merge-base, git diff --name-status, git diff --cached, and git ls-files --others --exclude-standard.

After a base merge or rebase, recompute the scope. Reuse only evidence whose covered behavior and inputs were not invalidated.

Map risk to evidence

Every behavior change needs the narrowest available check that would fail for its regression. Add broader checks only for surfaces the diff can credibly affect.

• Local implementation: run the owning unit or integration tests and the repository's type, compile, lint, or static checks that cover the changed language and package.
• Shared contract or public API: add adjacent consumer tests, schema/API compatibility checks, and a built-entry or package smoke when callers consume compiled output.
• Persistence, migrations, queues, or durable formats: test forward behavior, failure/rollback, compatibility, and recovery against the real migration or serialization path.
• Asynchronous, worker, subprocess, or resource-owning lifecycle: test success plus cancellation/failure, restoration after a failed transition, a negative control for leaked or duplicate work, concurrent-owner isolation where relevant, and teardown to quiescence. Exercise the real worker/process entry path when in-process fakes cannot prove ownership or cleanup.
• Build, manifests, exports, bins, workers, packaging, or deployment configuration: run the build plus the artifact, install, startup, or deployment-config smoke that proves the produced surface.
• Documentation, examples, generated catalogs, or linked comments: run the repository's generator/sync, link, example, localization, and documentation checks as applicable.
• CLI-, UI-, model-, or protocol-visible output: exercise the real entry path and run the focused snapshot or behavioral assertion that owns the output.
• External provider or environment behavior: run the smallest real integration/e2e scenario when credentials and authority are available; redact secrets and distinguish simulated evidence from real service evidence.
• Security or permission boundaries: run the relevant policy, negative, and abuse-path checks rather than relying on a happy-path test.