I had 14 git repositories across personal projects, client work, and products. All on GitHub. All public or pushed to remote. And across those 14 repos, I found internal process documents, skill configurations, planning artifacts, and tool settings that had no business being visible to anyone but me.
Not secrets. Not API keys. But something arguably worse for a professional operation: my entire internal workflow, exposed. The tools I use, the methodology I follow, the planning documents I write before building. My workshop was on display. Only the products should be.
Building Fast, Forgetting Fundamentals
When you're a solo developer shipping across multiple projects simultaneously, the pressure is to build. Get the feature done. Push the commit. Move to the next thing. Git hygiene falls to the bottom of the priority list because it doesn't ship features. Nobody notices a clean .gitignore. Everyone notices a broken checkout flow.
I was using Claude Code across every project. I had skill configurations for different roles — I'd step into a product manager mindset to write PRDs, an architect mindset to design systems, a QA mindset to review my own work. These configurations, along with planning documents, architecture decisions, and internal notes, were all sitting in directories that git was happily tracking and pushing to GitHub.
The Audit
I didn't discover this through a security alert or a client complaint. I discovered it through my own checklist. Part of my process is a periodic review of what's public vs what should be private. I ran a scan across every repository: what's tracked in git that shouldn't be? What's visible on GitHub that's meant to be local?
The command is simple: git ls-files --cached piped through a grep for known internal directories and filenames. Run it across every repo. Count the results. The number I got back: 740+ tracked files across the worst offender alone, and scattered internal documents across 8 other repositories.
What I Found
One repository had 741 files of internal tooling tracked and pushed to GitHub. Skill configurations, planning artifacts, agent role definitions, customisation files. Another had internal product documents (design briefs, product specs) committed alongside the source code. Two client-facing repositories had my project management documents tracked — files that contain internal notes about scope, pricing strategy, and client communication.
None of this is catastrophic. But all of it is unprofessional. A client browsing the repository of the system I built for them shouldn't find my internal planning notes. A potential employer reviewing my GitHub shouldn't see my skill configurations and process documents. The code is the deliverable. The process behind it is mine.
Working with Multiple Roles
Part of how I work as a solo developer is wearing multiple hats deliberately. Not just switching between coding and designing — actually stepping into distinct roles with distinct thinking modes.
When I'm scoping a project, I think like a product manager. I write the requirements document. I define what's in scope, what's out, what the success criteria are. Then I challenge my own document — is this actually what the client needs, or what I think would be fun to build? I debate with myself. I justify decisions. I cut features that don't serve the core goal.
When I'm designing the system, I think like an architect. What are the data flows? Where are the boundaries? What happens at scale? What's the failure mode? I use Claude Code as a sounding board here — I present my architecture and ask it to challenge my assumptions. Sometimes it finds things I missed. Sometimes I disagree and explain why my approach is better for this specific context. It's a back-and-forth, not a one-way instruction.
When I'm reviewing code, I think like QA. Not just 'does it work' but 'what happens when the input is unexpected, the network is slow, the user does something I didn't anticipate.' I run through edge cases systematically. I check security implications. I verify that error states are handled gracefully, not just logged and ignored.
I also use Claude's design capabilities to think through visual problems — layout decisions, component hierarchy, information architecture. It's another thinking partner in a different domain. The combination of code-level assistance and design-level thinking means I'm not just building faster, I'm making better decisions across more dimensions than a single perspective allows.
All of these roles generate artifacts. Documents, configurations, decision logs, review notes. These artifacts are invaluable for my process. They're also completely irrelevant to anyone cloning my repository. They needed to be gitignored from day one. They weren't.
The Cleanup
I used Claude Code to execute the cleanup because the task was well-defined and repetitive: for each of 14 repositories, check what's tracked that shouldn't be, untrack it with git rm --cached, update the .gitignore, commit, push. The audit and execution took one session. 741 files purged from the worst repository alone. Internal documents removed from 5 others. Gitignore rules applied to all 14.
I also set up a global gitignore at ~/.config/git/ignore for OS and IDE files — .DS_Store, Thumbs.db, .vscode settings, .idea directories. Following GitHub's official recommendation: machine-specific junk belongs in the global config, not repeated in every project.
The Gold Standard
Every repository now has the same internal tooling block in its .gitignore. The comment says 'Internal tooling' — not 'AI tooling' or 'Claude settings.' The language is neutral because the principle is universal: your process is yours. Your deliverable is the client's. The gitignore is the boundary between workshop and showroom.
I also built a sanitisation checklist that runs before every push: verify gitignore entries exist, verify nothing internal is tracked (git ls-files --cached piped through known patterns), verify no process references in code comments, verify git history is clean. It takes 30 seconds and prevents the kind of slow leak that accumulates over months.
The Principle
If you're a developer using AI tools — any AI tools — your .gitignore is a professional boundary. The code you push should be indistinguishable from code written without AI assistance. Not because there's anything wrong with using AI. But because the client paid for a solution, not a behind-the-scenes documentary of how it was built.
Build fast. Ship often. But check what's public. Your process is your competitive advantage. Don't give it away for free in a git commit.
“The code is the deliverable. The process behind it is yours. The gitignore is the boundary.”