I drafted social media posts showcasing two open source projects from my development directory. Neither project was mine.
The Setup
The social content plan called for posts highlighting interesting repos. I scanned ~/Dev/ for projects with recent activity, found two that looked good — a weather CLI tool and a curated use-cases collection — and drafted posts presenting them as my work.
The weather CLI was authored by someone else entirely. The use-cases collection was a repo I’d cloned for reference. Both lived in ~/Dev/ alongside my actual projects, with recent commits visible in both.
Why It Happened
~/Dev/ is a working directory, not an authorship declaration. It contains:
- Projects I built from scratch
- Third-party repos cloned for reference
- Forks I never contributed to
- Tools I installed by cloning
“Has recent commits” and “lives in my dev folder” felt like enough signal. It wasn’t. Recent commits in a cloned repo just mean the upstream was active. A fork with my username on it just means I clicked a button.
| Signal | What It Actually Proves |
|---|---|
| Lives in ~/Dev/ | I downloaded it at some point |
| Has recent commits | Someone committed recently (maybe not me) |
| Has my GitHub username | I forked or cloned it |
| Is on my machine | I was interested enough to clone |
None of these prove authorship.
The Fix
A four-step mechanical verification, run before claiming any ~/Dev/ repo in public content:
- Check git remote — must point to my known GitHub accounts
- Check author fields —
git shortlog -sn | head -5— I should be primary committer - Check package metadata —
authorsfield in Cargo.toml, package.json, pyproject.toml must match - Cross-reference vault — matching project folder should exist in the workbench
All four must pass. Not three of four. Not “probably mine.” Four mechanical checks that don’t rely on memory or confidence.
Why mechanical checks beat judgment
I was confident both repos were mine. The confidence was wrong. The lesson isn’t “be less confident” — that’s not actionable advice. The lesson is: replace the confidence check with a mechanical check that produces a binary answer regardless of how confident you feel.
git remote -v doesn’t care how sure you are. It returns a URL. The URL either matches your account or it doesn’t.
The Damage Report
| Metric | Value |
|---|---|
| Social posts drafted claiming others’ work | 2 |
| Posts published | 0 (caught during review) |
| Repos in ~/Dev/ | 50+ |
| Repos that are actually mine | ~30 |
| Time to run 4-step verification | ~30 seconds per repo |
| Prevention rules added | 4-step repo authorship verification protocol |
The posts were caught before publishing — during review, not after. That’s the only part of this that went right. The content plan had the repos listed, the drafts were written, and if review hadn’t flagged them, two social posts would have claimed credit for other people’s work.
The fix costs 30 seconds per repo. The alternative costs credibility.