publish-gate.
A leaked key in a public repo is forever. This gate is built so that a dirty commit never leaves your machine.
#What it is
A pre-publish pipeline for AI agent workflows: ten gates that run, in order, before anything goes public. It ships as a single skill file that Claude Code loads natively; any other agent can take the same file as a system-prompt section, and with no agent at all it works as a plain checklist. Beyond git, the method needs gitleaks and a second model instance for the two audit gates.
#The itch
I let agents prepare repos for publishing, and the scary part is that a secrets leak is one push away and permanent. GitHub's own documentation says that after a history rewrite, commits with sensitive data may still be reachable through their SHA-1 hashes, and that commits can stay reachable in a repository network even after a fork is deleted. Truffle Security documented that this behavior is known to GitHub and intentional. Cleanup after a leak means a support ticket and credential rotation. Prevention means the dirty commit never exists in anything you push. That is what the gate enforces.
#How it works
Clean room, no history rewrite
Private git history traveling along with the files
Dedicated mirror folder
Cloud-sync corruption, nested repos, pushes nobody inspected
Sanitize sweep
Secrets, IPs, private paths, real names in example data
gitleaks, twice
A clean working tree hiding a dirty intermediate commit
Adversarial audit
The author's blind spots: leaks, overstated claims, slop
Legal review
Missing license, vendored third-party code, ToS gray areas
End-to-end test
Documentation that lies
Pre-push verification
Foreign refs, stale reflog entries, a real email as commit author
Summary in chat
A go decision based on assertion instead of evidence
The human pushes
Agents publishing on their own authority
The order matters: cheap mechanical checks first, expensive judgment calls later, the human last. Gates 5 and 6 go to a second model instance that had no hand in writing the content, so the session that wrote the repo does not grade its own work. And gate 10 is a person: every publish path ends with a push command for you to run, never with a push by the agent.
#Walk the gates
The skill ships with a worked example, EXAMPLE-RUN.md: retry-fetch, a fictional one-file Python helper whose private workspace holds a GitHub token in a .env file. Here that repo walks the gates twice, the way the example tells it. Both runs are scripted replays; this page runs no commands and makes no network requests.
#In real use
The repo went through its own gate before it went public. Gates 1 through 9 ran against it, with the adversarial audit and the legal review done by separate model instances, and the full run, including real command outputs and the findings that had to be fixed, is documented in gates/self-run.md.
The limits, straight from the README: the gate reduces risk and guarantees nothing, because a gate is a process and processes get skipped on bad days. That is why gate 9 forces the evidence into the chat where the human sees it. gitleaks matches known secret patterns, so a home-grown token format can walk through gate 4 unnoticed; gates 3 and 5 exist for exactly that case. And nothing here un-pushes a commit: if a real secret ever left the machine, revoke and rotate it first.
#Install
$ git clone https://github.com/belschak/publish-gate ~/.claude/skills/publish-gateThe skill triggers on publish intent ("make it public", "push the repo", "launch", "release") and ends every publish path with a push command for you instead of a push by the agent. A skill is an instruction, not enforcement; the README is honest about what that means.