Zen pre-push

Explain delivery in the owner's preferred language: a commit is a local checkpoint; a push sends it to a remote; a pull request asks for review. Check the actual local repository and remote configuration before recommending a next step. Remote hosting and sign-in are optional for local operation. Run or honestly report the applicable scripted tests, typecheck, lint/format, security checks and build before presenting a reviewable PR; never imply that a prepared packet authorizes committing or pushing.

Make the proposed Git action concrete and reviewable. The skill prepares delivery; invoking it does not authorize the delivery itself. For the branch, commit, pull request and staging-first rules that the packet should follow, use zen-delivery.

1. Inspect repository instructions, intended branch/remote, base/head, staged/unstaged/untracked files and linked task/spec. Preserve user work and existing unrelated commits. Identify whether a push triggers deployment or publication.
2. Run pre-checks appropriate to the actual final change and required project gates. Read the review findings and unresolved acceptance criteria. A prior passing result on a different diff is stale evidence.
3. Inspect the complete proposed content, including new assets, generated files, environment files, private profiles/records and build outputs. Use an explicit public allowlist when exporting skills; a generic ignore pattern is not proof private material is excluded.
4. Explain the exact operation and target: commit content/message, push branch/remote and any publication/deployment consequence. Commit, push and merge are separate decisions. An approval for one or an earlier revision does not silently cover another operation or a changed diff.
5. Show a concise diff summary and actual check results/waivers before requesting missing authorization. Do all reversible preparation first. If authorization already covers this exact action, the host's delivery workflow may execute it; this mode itself never automatically performs Git delivery.
6. Keep milestones honest: branch activity is pending delivery; merge requires verified ancestry or merge evidence; deployment requires its own observation. Do not mark failed/absent checks Passed or a branch commit Deployed.
7. Record the readiness report and outstanding decision using the delivery packet, linked to the task/milestone. Use the actual MCP contract or initialized standalone capture. The current MCP cannot commit, push or merge; do not invent that tool.

Boundaries

If the owner says keep local, stop at the review packet and leave repositories/packages unpublished. Do not amend, reset, rebase, force-push or move existing work to make a cleaner packet without applicable authority. A fresh Git authorization after a declined publication must be explicit.

Example: “Ready to push” must name what will leave the machine and where. “All tests passed” does not identify a remote, protect a private profile or authorize production deployment.