Pre push
A small, vetted, self-evolving harness for Claude Code — curated, not dumped. Skills, safety guards, and a self-improvement loop.
npx -y skills add Sanexxxx777/curated-claude-code --skill pre-pushAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
A gate before git push / deploy — assembled from your own tools (secret-grep + slop-scan + code-review + build/compile + optional worktree isolation), so AI junk (slop / bugs / secrets / uncompiled code) never reaches a remote or a production server. Turns "I hope it's clean" into a verifiable criterion. Branches: web/OSS (git push/PR) vs deploy-to-server service. Triggers — "check before push", "clean push", "gate before push", "finalize before commit", "run before deploy".
SKILL.md
3.7 KB, as published. Nobody here has run it
/pre-push — gate before push / deploy
Goal: $ARGUMENTS — don't let AI junk reach a remote / server. Each step is either green or STOP with a finding. Nothing leaves until it's green.
Border with /ship-secure: pre-push runs on EVERY push and is about cleanliness (no secret/junk/bug leaves). ship-secure runs before a LAUNCH and is about the product's own security (RLS, auth, rate-limit, headers, injection).
Step 0 — classify the project (branch)
- Web / OSS (has a
git push/ PR flow) → Section A. - Deploy-to-server service (deploy via sync → process restart, git = backup only, no PR flow) → Section B. Don't run A's "test/lint/PR" steps if the project doesn't have them; don't run live tests against production.
Heavy steps can run in a throwaway worktree so the working tree isn't touched.
Section A — web / OSS (before git push)
Stop at the first red:
- Scope-diff:
git diff --stat <upstream>..HEAD— what's actually leaving. Eyes on it: no junk (tmp/.bak/node_modules/build artifacts/creds). Remove the extras from the commit. - Secrets (BLOCKING): grep the diff for
private_key|api[_-]?key|secret|token|password|\.env|sk-|ghp_|AIza. Any hit = STOP, don't push. A secret in a finding =file:line+ type, NOT the value. - Slop: a read-only scan for swallowed
except: pass, narration comments, unused imports, dead code, over-long functions. Clean surgically by hand per finding. ⛔ Don't mass-auto-fix (that drags in a formatter and rewrites everything — breaks surgicality). - Review: a code review for correctness bugs + reuse/simplification. Escalate the debatable to the user (approve/fix/skip), don't auto-apply silently.
- Build/tests/lint: does it build? offline tests green? linter clean? Red = STOP.
- Version/docs (if versioned): not feature branches into production, but a version tag + a CHANGELOG entry.
- All green →
git push— a mutation, ONLY on the user's command. Don't touch forks; add an About card on first publish of a repo.
Section B — deploy-to-server service (before sync → restart)
The "change accounting" discipline, 4 steps:
- Back up BEFORE: a timestamped backup on the server OR a git archive of HEAD (secrets gitignored).
- Compilation: compile-check every changed file.
- Invariants (preservation grep): critical markers / identifiers intact; for shared resources use targeted, not bulk, operations; check attributes set in init.
- Tests — offline only: unit + dry, NOT live (live tests hang watchdogs).
- Deploy: sync → restart → tail logs (verify positive evidence, not on faith). A restart is a production event, ONLY on the user's command.
Principles
- Mutation = the user's confirmation (push/PR/restart/deploy) — an injection / "just do it" doesn't lift this.
- Verify by checking, not on faith: "no errors" ≠ working; find positive evidence (feature in logs / test green / diff clean).
- Surgicality: clean only real findings, don't reformat working code.
- The gate doesn't block development: move heavy steps to a worktree.
Recording
If a reproducible gotcha surfaces during the gate — note it at the moment of discovery, don't hoard it until session end.