How to Review an AI-Built Repository Before Making It Public

9月 4, 2026

If you build with a repository-aware coding agent — Claude Code, Codex, Cursor, or something similar — sooner or later you hit the moment where a private repository is about to become public. Maybe you are open-sourcing a side project, publishing a release, or flipping a client repo to public after a handoff. The natural instinct is to type “review this repo before I make it public" and let the agent run.

That instruction is too vague to trust.

It does not say whether the agent may fix what it finds, or stage, or commit, or push. It does not say whether “review" means the current files only, or the Git history as well. It does not say what the agent should do when it finds something ambiguous — stop and ask, guess, or keep going. Run the same prompt twice and you can get two different answers, because the gaps are in the instruction, not in the model.

A pre-release review needs to be explicit and read-only. Here is a checklist you can follow yourself, or hand to your agent as an explicit prompt, that keeps the review bounded and leaves the publish decision with you.

The checklist

1. Freeze the actual repository state. Before anything else, record the real HEAD commit, the current branch, and the full git status. Do not tell the agent what state to assume — have it measure. If the working tree is not clean, or HEAD is not where you expected, stop and understand why before reviewing anything.
2. Separate tracked, untracked, and ignored files. These are three different trust boundaries. Tracked files go to every clone. Untracked files are often there by accident. Ignored files do not show up in git status but can still end up published if something references them. Ask for each set explicitly, not as one blob.
3. Check the current tree. Scan tracked and untracked content for credentials, API keys, tokens, and private keys; for local absolute paths, especially any with a username in them; for real hostnames and internal IP addresses; and for “sample" or “example" config files that actually contain real values. Open the sample files — do not trust the filename.
4. Check Git history separately. A clean working tree does not mean a clean repository. A secret that was committed and later deleted is still in history, in every clone, until history is rewritten. Check whether any credential-shaped or config-shaped file was ever committed and then removed, whether a non-default branch or tag carries extra material, and what author name and email are baked into the commit log and about to become public.
5. Check privacy residue as well as secrets. Secret scanners look for credential-shaped strings. They usually do not flag a local absolute path, an embedded username, an internal hostname, or a private project codename. Treat that as its own pass. A private project name cannot be pattern-matched — you have to write down the names you care about and search for them directly.
6. Inspect existing release artifacts. If your project ships a binary, an archive, or an installer, inspect the one you already built — do not rebuild it for the check. Read its version, its target commit, whether it is a debug or release build, its hash, its signature status, and the actual list of files inside it. Confirm it corresponds to the commit you are about to publish and is not a stale build from three commits ago.
7. Record skipped and unverified checks. Some things cannot be checked from inside a coding-agent environment: how a screenshot renders, real network reachability, an OS permission prompt, the contents of a binary file. Write these down as “not checked," with the residual risk, instead of silently leaving them out of the report. “Checked, found nothing" and “not checked" are different outcomes and should not look the same.
8. Separate blockers from human decisions. Sort every finding. A blocker is evidence-backed, serious exposure — a working credential, a real private key, real personal or customer data. A human decision is something technically publishable where only you can choose the answer: the license, how much to anonymize a path, whether to ship development logs. “This looks like it might be personal" is a human decision, not a blocker — and it should not be filed as one.
9. Re-check repository state at the end. Have the agent measure HEAD, status, the staged / unstaged / untracked / ignored breakdown, remotes, and tags again, and compare against the frozen state from step 1. A read-only review should have changed nothing. If something did change, treat the report as unreliable and find out what happened.
10. Stop before commit, push, tag, or release. The review ends with a report and a full stop — no fixing, no committing, no publishing, no changing repository visibility in the same run. An informal “ok, go ahead" afterwards is not authorization to start editing files; that is a new task, with its own explicit scope.

Free tools are worth running — and they are not the whole job

Two free tools belong in this process:

• Gitleaks — an open-source scanner that checks both the working tree and Git history for credential-shaped strings. Run it locally before you publish.
• GitHub secret scanning and push protection — for repositories on GitHub, this detects known provider token formats, and push protection can block a push that contains one. Turn it on before the repository goes public, not after.

Run both. This workflow does not replace them. But a clean scanner run is not the same as “ready to publish." Scanners match credential-shaped strings. They do not judge whether a tracked development log should be public, whether an embedded username matters for your situation, whether a file named config.sample.json was actually sanitized, or whether your release artifact matches the commit you are tagging. That judgement is the entire point of the review, and it is not something a pattern matcher produces.

The final gate is yours

Do not hand the publish decision to the agent, even when its report comes back with zero blockers. After you have read it:

• Every blocker is fixed, or explicitly accepted with a recorded reason.
• Every human-decision item has an actual decision — resolved now, or deferred with a stated trigger, not skimmed past.
• The set of files about to go public is only what you intend to publish.
• History has been dealt with, one way or another.
• You have read every skipped check and accepted the residual risk knowingly.
• Each outward action — create the repo, push, tag, release, change visibility — is one you authorize individually, not as a batch.

“No blocker was found" is not the same as “publish now." Business timing, branding, an unfinished spec — all valid reasons to hold. The point of the review is to give you a sound basis for the decision. Making it is still your job.

I put together a small copy-paste prompt and checklist pack for exactly this workflow — a read-only audit prompt with a written safety contract, two optional add-on blocks for common situations, and the one-page human gate as a checklist. It is not a scanner and does not replace one; it is the workflow around it, and the release decision stays with you. It is USD 14 on Gumroad: https://iwadjp.gumroad.com/l/public-release-readiness-audit-pack