Inspiration
I finish a day of work and can't remember what I actually did. Standup is in five minutes and I'm reconstructing it from memory. Every existing option is friction — a notes app means opening an editor, finding the file, deciding where to type. Shell history only records commands, not what I was working on or why.
I wanted something that takes one command from the terminal I'm already in, appends instantly with a timestamp, and zero decisions. Then I wanted the read side — one command that answers "what did I actually do today?"
What it does
SnapLog is a terminal work logger with exactly three commands:
snap "fixed the login redirect bug" → log an entry snap today → show today's entries snap week → show the last 7 days
Entries are stored in a plain text file at ~/.snaplog.txt, one per line: an ISO timestamp, a tab, then your text. No database, no account, no sync, no dependencies. It runs in the terminal you're already in, so logging takes under two seconds and never requires a context switch.
How we built it
Built with Node.js, zero npm dependencies — only the built-in fs, path, and os modules. Single file: snap.js. Packaged with a bin entry so it runs as the snap command.
I built it using a spec-driven, plan-first workflow with a coding agent. Before writing any code, I generated three planning documents:
- scope.md — what's in and what's explicitly out
- prd.md — the problem, the user, and exact command behavior
- spec.md — the technical shape: file format, filtering logic, error handling
The plan-first step was what made the difference. Every time the agent suggested expanding scope — a web UI, a config file, tags, search — I pointed back at scope.md and said no.
Challenges we ran into
Resisting scope creep. The natural instinct is to add features. Every one would have made the tool slower to use, which defeats the entire purpose. Keeping it to three commands took more discipline than writing the code did.
The demo environment. SnapLog writes to the user's home folder, so recording a demo meant my real work log would end up on camera. I solved it by pointing PowerShell's USERPROFILE at a temporary directory for the recording session — SnapLog doesn't care where home is, it just writes a file there.
Accomplishments that we're proud of
The tool works, it's small, and I'll actually keep using it. All three commands are verified end to end — logging, reading today's entries, and reading the last seven days, including graceful handling of an empty or missing log file.
It's also the first project I've built using a plan-first workflow with a coding agent, and the first time that workflow actually produced something I finished instead of abandoning halfway.
What we learned
Planning before building is the habit that keeps AI-assisted projects from turning into a mess. The agent was genuinely useful once the scope was locked — before that, it wanted to build too much.
The other lesson: a tool has to be faster than not using it, or you won't use it. Every feature I said no to was a feature that would have added friction to the one thing SnapLog needs to do instantly.
What's next for SnapLog
Nothing, probably — and that's the point. The tool does what it set out to do.
If I did extend it, the only change that wouldn't break the core promise is a snap month command for longer lookbacks. Everything else — tags, search, editing, a web UI — would slow down the write path, which is the whole reason the tool exists.
Log in or sign up for Devpost to join the conversation.