The first commit of an AI-built prototype should contain a .gitignore that excludes secrets and build output, an example environment file with no real values, a committed lockfile, a short README with owner and expiry, and a note on what the prototype must never touch. Set these before the first prompt, not after the first leak.
Why the first commit matters
Everything committed stays in history. If an assistant creates a local environment file with a real key and your first git add . includes it, that key is now in the repository for good. Setting guardrails before the code arrives is cheaper than cleaning up afterwards.
The checklist
1. A .gitignore written first. Include local environment files, key and certificate files, dependency folders, build output, editor settings and logs. The git documentation describes the pattern format, and a pattern only affects files not already tracked, which is why timing matters.
2. An example environment file. Commit a file that lists variable names with placeholder values and a note on whether each is public or secret. Real values stay out of the repository. The Twelve-Factor App states a useful test: you should be able to open source the codebase at any moment without compromising credentials.
3. The lockfile. Generate and commit it. It records exact versions so that every install gets the same packages. In CI, use the clean install command, which in npm exits with an error if the lockfile and manifest disagree.
4. A README header. Four lines: what this is, who owns it, when it expires, and the sentence "Prototype. No real data. Not for production."
5. A rules file for your assistant. Many tools read an instruction file from the repository. Put short rules in it: do not add dependencies without saying why, do not put secrets in code or in browser-exposed variables, do not disable checks to make tests pass.
6. Basic CI. Even a small workflow that installs from the lockfile, runs tests and builds catches broken states early.
What to leave out
- Real data, even a single sample file.
- Personal tokens used for convenience.
- Scratch notes with internal hostnames or credentials.
A quick way to start every time
Create a template repository with all six items and start new prototypes from it. People will follow the safe path if it is also the fast one.
If you already made the mistake
If a secret was committed, revoke or rotate it first. GitHub's guidance notes that once a secret is revoked, rewriting history may not be warranted, and that rewriting carries side effects such as a risk of recontamination.
Where Safeguard fits
Safeguard can scan the dependencies in the lockfile you committed, generate an SBOM and apply policies on pull requests. Try a free scan at gold.safeguard.sh/scan.
Quick check
Does adding a file to gitignore remove it from history?
No. Ignore rules apply to untracked files. A file that was already committed stays in history until removed, and any secret in it should be rotated.
Should the lockfile be committed for a throwaway prototype?
Yes. It costs nothing and means a teammate installs the same versions you tested.
Sources
- git documentation, gitignore
- The Twelve-Factor App, Config
- npm docs, npm ci
- GitHub Docs, Removing sensitive data from a repository
Last reviewed: 19 October 2026.
