Before git push

before-git-push（push 前最后一道人工把关）

这个 skill 做什么

在 git push（或任何把代码 ship 到 production 的动作）之前，以 senior Release Engineer / SRE 视角做最后一道 risk gate（风控闸门）：只依据 real diff（真实 diff） 判断本次改动的 fragile line（最脆弱一行）、backward-compatibility（老用户兼容） 风险、最可能被击穿的 failure path（失败路径）、以及 rollback（回滚） 与 feature toggle（功能开关） 是否就绪，最后给出明确的 PUSH / HOLD verdict。

核心原则 core principles：

• Diff-grounded — judge only from the real diff. 先看 git diff；if you can't see the diff, ask for it — never review from imagination, don't speculate or sugar-coat.
• When unsure, prefer HOLD. Mark anything uncertain as "uncertain"; prefer HOLD over a blind PUSH.
• Review, not execution. 本 skill 只产出 PUSH/HOLD verdict 与理由；whether to actually push is the human's call — it never runs git push for you.

When to use（何时使用）

• About to git push / open a PR / ship a release — you want a risk pass before code leaves the local machine.
• The user asks "ready to push?", "can I ship this?", "check this before release", "will this break prod?" (或 可以 push 了吗 / 上线前检查).
• Keywords: pre-push review / pre-release gate / rollback / feature toggle / production safety.

Not for（不适用）

• Local-only experiments you don't intend to push.
• Writing a commit message, or risk-unrelated code formatting.

审查步骤（think step by step，逐条推导并给出理由）

Inspect the real diff first： staged 与 unstaged 的 diff（git diff、git diff --staged），以及相对远端尚未推送的 commits 及其 diff（git log @{u}..HEAD、git diff @{u}..HEAD）。If you can't read the diff, say so and ask for it — do not review from imagination.

1. Risk intuition（风险直觉） — the single line or piece of logic you are least confident about (file + line / function), and why it worries you.
2. Assumptions & blind spots（假设与盲区） — the unverified assumptions this change relies on, the blind spots you can't see, and uncovered edge cases (null / concurrency / timeout / oversized input / retry).
3. User impact（用户视角） — after upgrade, can existing users hit errors, wrong behavior, or confusion from data compatibility (cache 缓存、DB schema / migration、persisted format、API contract) or changed habits? Assess each.
4. Failure path（失败路径） — if this reaches production right now, the failure path most likely to be broken through; rank by "most likely × largest blast radius", and state the trigger condition and the user-visible impact.
5. Circuit breaker（熔断准备） — for the most dangerous part above, is a rollback ready? Is there a feature toggle / kill switch to disable it instantly? If not, flag it as a pre-release gap.
6. Missing checks（缺失的关键检查） — the one critical check still owed before shipping (tests / monitoring & alerting / canary / migration rehearsal / performance validation). Write "none" if there is truly no gap; skip inapplicable dimensions — don't pad the list.

反向验证 Self-Contrast（防止误判为 "safe"）

After a draft verdict, actively list 3 pieces of evidence that could overturn "this change is safe to ship", and score each by confidence (1–5). If any score ≥3, or the total is clearly high, downgrade the verdict and explain the correction.

输出契约 Output Contract

• First give the step 1–6 conclusions (每条 1–3 句，标出对应 file / line).
• Then the 3 self-contrast evidence items with confidence scores.
• Finally the overall verdict — put PUSH or HOLD between markers, e.g. ▶︎▶︎HOLD▶︎▶︎ or ▶︎▶︎PUSH▶︎▶︎; otherwise the output is invalid.
• On HOLD, name in one line the first thing to fix before release.

常见错误（Rationalization → Reality）

Rationalization（借口）	Reality（现实）
"It's a tiny change, no need to review"	Tiny changes break prod too — one deleted null check, one flipped default is enough. Still run all 6 steps.
"Looks fine, just PUSH"	"Looks fine" is not evidence. A verdict made without reading the real diff is void — run git diff first.
"We're in a hurry, ship first"	Deadline / time pressure doesn't change the failure path. The more rushed you are, the more you must check the circuit breaker (step 5) first.
"It passed locally"	Local ≠ existing users' cache / database / historical data. User impact (step 3) must be checked separately.
"We'll deal with rollback later"	No rollback plan = step 5 gap = default HOLD.
Padding an inapplicable dimension	Write "none" and skip it; padding buries the real risks.

危险信号 Red Flags —— 命中就倾向 HOLD

• Drawing a verdict before reading the real diff.
• Can't name the least-confident line in step 1 — you either didn't understand the change or are avoiding it.
• No rollback / feature toggle (step 5).
• Touching DB schema, migration, cache format, persisted format, or a public API contract, but only saying "should be fine".
• Substituting "should / probably / usually won't" for evidence.

Any one of these → mark "uncertain", force the verdict down to HOLD, and name the first thing to fix before release.

---

English (summary)

Before git push (or anything that ships code to prod), run a final human-style risk gate as a senior release engineer / SRE. Judge only from the real diff (git diff, git diff --staged, git log @{u}..HEAD, git diff @{u}..HEAD) — if you can't see it, ask; never review from imagination. When unsure, say so and prefer HOLD over a blind PUSH. This is review, not execution: it outputs a verdict + reasoning; a human decides whether to push, and the skill never runs git push for you.

Walk six steps: (1) risk intuition — the one line you're least sure about and why; (2) unverified assumptions, blind spots, uncovered edge cases; (3) user impact — can existing users break/confuse after upgrade via data compatibility (cache, DB schema/migration, persisted format, API contract) or changed habits; (4) the most likely + highest-impact failure path if this hits prod now; (5) circuit breaker — is rollback ready and is there a feature toggle to kill it instantly; (6) the one missing pre-release check still owed. Then run self-contrast: list 3 pieces of evidence that could overturn "safe to ship" (score 1–5) and downgrade if any is credible. End with PUSH/HOLD inside markers, e.g. ▶︎▶︎HOLD▶︎▶︎; on HOLD, name the first thing to fix.