August 31, 2025
ThreadKeeper is a memory engine — a place to log the “why” behind your build. But it didn’t start as a polished idea. It started with fog.
I was bouncing between VS Code, a dozen AI chats, and a custom GPT I built named Dr. Kahlo. Somewhere in that swirl, I realized I couldn’t remember what I had just done. Not just code-wise — logic-wise. Intent. Reason. The good stuff that gets lost when you switch tabs too many times.
So I did what I’ve done dozens of times since starting this project: I prompted the problem into code.
This is the original prompt that started it all — unedited, unfiltered, and a little frantic. The tool I was asking for is the one I was already building:
🧵 Prompt to Build Core Logging for ThreadKeeper MVP
I'm building a CLI tool called ThreadKeeper, a lightweight project memory engine for solo builders who work fast, use AI, code, or iterate often — and need to remember why they did what they did.
I want to start building the Core Logging module:
- ✅ snapshot — saves code/text snippets with reason, tags, and optional file
- ✅ insight — logs "why" moments, bugs, GPT advice, etc.
Key design principles:
- Snapshots & Insights = cargo (stuff you picked up on the journey)
- Mini-Scope = compass (goals, stretch, risks, tools — already handled separately)
- Timeline = readable history, and Rewind = cassette metaphor for browsing past Snapshots
I’m using TypeScript + Node with Commander.js as the CLI base.
Storage = local JSON files (one per entry) inside /tk_entries/
Each entry includes:
- type: snapshot or insight
- timestamp: ISO format
- tags: array
- reason: required
- content: string or attached file content
- filePath: optional — only for snapshot
Let’s scaffold:
- Types/interfaces
- CLI command structure (Commander.js)
- JSON writer (with file-safe naming and deduping)
- Error handling if reason is missing or tag array is empty
What followed was a chaotic, productive back-and-forth. I’d write some, break some, forget what I broke, switch over to Dr. Kahlo, realize I’d already fixed it once, and then add a new field to solve the thing I’d already forgotten.
Eventually, the metaphors became architecture: snapshots and insights were cargo, the scope became a compass, and “rewind” became a cassette mechanism for version recall. The language I used to ask for help became the scaffolding of the system.
I chose TypeScript because I knew I’d scale it. Commander.js gave me just enough friction to make the UX clean. And once I layered in input validation, test scaffolding with Vitest, and a file-safe slug system, the core logging engine started to feel... real.
Every time I lost context, I made that pain point a feature. ThreadKeeper didn’t just log my work — it started suggesting what I should log. Like it had read my own frustration and decided to help.
There’s something deeply satisfying about that moment when a tool stops being theoretical. ThreadKeeper hit that moment when it stopped being a prompt and became a loop: prompt, log, recall, rebuild.
If you're building with AI and moving fast, I recommend you do one thing before your next big commit: log the why. Not just the what. That’s where the memory lives.
I officially launched ThreadKeeper with working snapshots, insights, and a functional TypeScript CLI. Hell yes.
Based on the entries I logged and the roadmap I've been building against, here’s where I’m at — and what comes next.
pnpm build and confirmed the CLI is functionalThe base engine is alive and saving entries as expected. It’s clunky and minimal — and exactly what I needed.
{
"id": "702d66f1-46cd-41e6-96b6-b94ea1b4006d",
"type": "insight",
"timestamp": "2025-09-01T02:08:37.373Z",
"tags": ["notes"],
"reason": "first run",
"content": "hello, threadkeeper"
}