$ man how-to/constraints-and-context-engines

CODE

Set up your .gitignore before your first commit. Not after. Before. The essentials: *.env and .env.* — API keys, tokens, passwords. One leaked key can cost thousands. clients/ and partners/ — real names, deals, conversations. data/ — CSVs and JSONs with real email addresses, company names, lead lists. scripts/ — automation scripts often embed API keys or reference internal systems. screenshots/ — may capture sensitive dashboards or client names in browser tabs. .cursor/mcp.json — contains your API keys for every connected tool. node_modules/ — thousands of dependency files that do not belong in version control. Test your .gitignore with git status. If a file you expect to be ignored shows up in the status, the ignore rule is not working. Fix it before you commit.

PATTERN

Never hardcode API keys in files. Use environment variables. Create a .env file in your project root. Add your keys: INSTANTLY_API_KEY=your-key-here. Reference them in code with process.env.INSTANTLY_API_KEY. The .env file is gitignored, so it stays local. Create a .env.example file (without real values) that you DO commit. This documents which environment variables your system needs without exposing actual keys. When a collaborator clones the repo, they see .env.example and know which keys to add. For Vercel deployments: add environment variables in the Vercel dashboard. The deployed app reads from Vercel's environment. Your local app reads from .env. The keys never touch version control.

PATTERN

Structure your repo so sensitive data has a clear home that is always gitignored. Skills, content, and workflows are safe to share. Clients, partners, data exports, and scripts with credentials are not. The pattern: shareable content (frameworks, templates, published posts) lives in tracked folders. Sensitive content (client data, API configurations, internal scripts) lives in gitignored folders. The boundary is clear and enforced by .gitignore, not by memory. My repo has both a private working repo (contains everything) and a public GitHub repo (contains only shareable content). The /update-github skill runs a pre-push scan that checks for sensitive partner names using a local blocklist before pushing to the public repo.

PRO TIP

A .gitignore prevents accidental commits of entire folders. But what about a partner name that slips into a commit message or a blog post? Pre-push scanning catches those. The /update-github skill scans tracked files for sensitive content using a blocklist of partner and client names. It audits the .gitignore to confirm all sensitive folders are excluded. It checks commit messages for leaked names. Only after all scans pass does it push. You can build a simpler version with a git pre-push hook. The hook runs a script that greps for patterns you define (company names, email domains, key prefixes). If it finds a match, the push is rejected with a warning. This is a safety net, not a replacement for good .gitignore configuration.

FORMULA

Keep two repos or use branch-based separation. Option A (two repos): Your private repo contains everything — skills, content, partner data, scripts. Your public repo is a cleaned subset. A pre-push script ensures nothing sensitive crosses over. Option B (branch-based): Your main branch is public. Sensitive work happens in private branches that never merge to main. This is simpler but riskier because one wrong merge exposes everything. I use Option A. The private repo is the full operating system. The public GitHub repo is the showcase version with frameworks, published content, and skill examples. The /update-github skill automates the sync with safety scanning. The key: the public repo is NEVER the primary working copy. It is a curated export of the private repo.