The snippet SaaS account I deleted had three years of snippets, a team plan, and a price that was reasonable in isolation. The deletion was not a price decision; it was a trust decision that the price made visible. The specific sequence: a security review of the tools the team used, a question about where the snippets were stored, an answer that included and our backups, and the realization that the snippets contained the API keys from the projects they documented, because snippets are where the working example lives, and the working example contains the working credentials, which is the specific, documented habit this article is about.
The keys were rotated, the account was evaluated, and the evaluation was the comparison: the SaaS gave me sync, search, and sharing; it took my secrets to a server I did not control, in a backup I did not control, under a terms of service I had not read. The local tool gives me search and capture; it does not give me sync, and the sync is a git repository, which I do control, because the repository is mine, the history is mine, and the review of a snippet change is a normal pull request. The deletion was one click. The migration was one afternoon. The trust decision was the article's whole point: the snippet manager is a storage system for your code, and a storage system is a trust decision, and the trust decision is the only decision that matters, because the features are negotiable and the trust is not. This is the story in the order it happened, with the specific numbers and the specific keys, because the specifics are the evidence and the evidence is the point.
I did not set out to build snippetx. I set out to fix a specific problem, and the tool is the scar tissue from fixing it properly. This is the story in the order it actually happened: the incident, the first attempt that did not work, the constraint that shaped the design, and the decision I would make differently if I were starting over. None of it is polished, because the polished version would be a press release, and I would not trust a press release either. If you are deciding whether to use @wuchunjie/snippetx, the build story is the most honest document about what you are getting — including the parts that are limitations, which the marketing page would never name.
The Snippet Scattering Problem
Your code snippets do not live in one place. They live in four browser bookmarks, the notes app on your phone, a scratch file you never cleaned, the README of a project you will not open again, and your memory, which is not a storage system. The result is a tax on every small task: the regex you wrote twice last year, the shell one-liner that took twenty minutes to debug, the config block that is correct in exactly one way. You do not search for it; you rewrite it, and the rewrite is eighty percent correct and the other twenty percent is where the bug lives. A snippet manager is not a productivity fantasy. It is a fix for the specific, measurable cost of re-deriving code you have already derived. The question is only where it should live — the browser, the cloud, the notes app, or the terminal — and the answer depends on where the capture moment happens, which for working developers is, almost always, the terminal. The rest of this article is the argument for that answer, built from the six commands that implement it.
Pipe In, Pipe Out: The Unix Way
The interface is pipes, which is where the power is. Save: pipe the content you just wrote into add, with a name and a language — the snippet is captured in the same motion as the moment you wrote it, no window switching. Retrieve: search, pick the id, pipe copy into your clipboard, and the snippet is on your clipboard before your hand leaves the keyboard. The pattern generalizes to anything: the output of a command you just ran, a block of config from a man page, a JSON response from a test. The tool does not try to be an editor or a note app. It is a pipe between your terminal and your future self, and pipes compose. That is the difference between a snippet manager you visit and one you live in. Visiting requires intent; living requires only the next pipe. The capture cost is a keystroke and a name, and the retrieval cost is a search term, and both costs are low enough that the habit is cheaper than the alternative, which is remembering. The alternative always costs more, eventually.
Snippets Contain Secrets: The Local-First Argument, Quantified
Here is the uncomfortable truth about snippet managers: snippets are where secrets go to hide in plain sight. A debug snippet from last month contains the API key you used. A deploy script snippet contains the database URL. A quick-test snippet contains the token you copied from the console. In a cloud snippet manager, those values are on a vendor's servers, in their backups, in their support logs, and in their terms of service. In a local file, they are on your machine, under your control, scannable by a secret scanner, and rotatable without a vendor. The privacy argument for local-first is not hypothetical; it is the specific, documented habit of developers pasting live credentials into their notes. Your snippets should live where your secrets can live — which is to say, where you can find them, scan them, and rotate them. The local file makes all three of those possible; the cloud file makes all three of them someone else's problem. That is the quantified argument, and it is the one that survives contact with a real codebase.
The Copy Pipeline Across Three Operating Systems
The last mile of a snippet workflow is the clipboard, and the clipboard is where tools get platform-specific. The tool keeps its side of the contract simple: copy prints the snippet to stdout. The rest is the shell. On macOS, pipe to pbcopy. On Windows, pipe to clip. On Linux, pipe to xclip or xsel depending on your desktop. One command per platform, three lines of muscle memory, and the snippet lands in your editor without a single mouse movement. The design deliberately does not try to own the clipboard — it would have to shell out to something platform-specific anyway — it just makes the contract so clean that the platform part is a two-word suffix. The workflow feels seamless because the tool knows exactly where its job ends. That boundary discipline is the quiet feature: the tool is a pipe segment, not a platform, and pipe segments compose with everything else you already have, which is why the whole pipeline feels like one command even though it is three.
Zero Dependencies, Instant Startup
The tool is a single file with no runtime dependencies, and the consequences are the same as in every other tool in this family: npx runs it without a global install, startup is instant, and there is no dependency tree to audit. For a tool that is part of a keyboard-driven workflow, startup latency matters more than it sounds. A snippet command that takes three seconds to respond breaks the flow; one that responds before you finish the pipe does not exist as an experience. Zero dependencies is the engineering answer to that requirement, and it also means the tool works in the same places your shell works — containers, CI, restricted machines — without a setup step. Small, fast, and present: the whole design in three words. The presence is the point. A tool that is always available and always instant stops being a tool and starts being a surface, the way the shell itself is a surface, and the snippets live on that surface the way everything else in the workflow does.
When a Snippet Manager Is Overkill
Honesty section: if you have fewer than fifty snippets and your editor already stores your common ones in its own snippet system, a dedicated manager is not worth the switch. The editor built-in is where your fingers already go, and adding a second system creates a split brain — half your snippets in the editor, half in the CLI, and you never remember which. The CLI tool earns its place when the snippets outgrow the editor: when they contain multi-file configs, shell scripts, and language-mixed content; when you want them searchable from the terminal where you actually work; when you want them under version control with a team. The right question is not: should I use a snippet manager? It is: has my collection outgrown where it currently lives? Answer that honestly and the tool takes care of itself. The outgrowth is usually visible as a specific moment — the third time this month you could not find the thing you knew you had written — and the moment is the signal, not the count. The count is what you check after the moment has already happened twice.
Local-First: Where Your Snippets Actually Live
The tool stores snippets on your machine, in a local file, with no account, no server, and no cloud. The consequence is the part people underestimate: your snippets are yours in the way that matters. No subscription lapses, no vendor shutdown, no storage quota, no sync conflict between machines, no question of who can read what you saved. The tradeoff is honest too: no cross-device sync out of the box, and if the machine dies, the snippets die with it unless you back the file up — and the backup is a git repository, which is the point. For most individual developers, the trade is a clear win: the failure mode of a local file is boring and fixable, while the failure mode of a SaaS dependency is not in your control. Local-first is a reliability decision, not a privacy one, though it happens to be both. The file is the database, the git repository is the sync, and the terminal is the interface. Every layer is something you already run, which is the whole argument in one sentence.
Six Commands, Whole Workflow
The tool has six commands and that is the entire surface: add, list, show, search, rm, copy. add saves a snippet with a name and an optional language tag, reading the content from stdin. list shows what you have, filterable by language. show prints one snippet by id. search finds snippets by term, in names and content. rm deletes. copy prints a snippet to stdout so you can pipe it to your clipboard. There is no account, no project, no workspace, no sync layer. The design bet is that a snippet tool only has to answer one question — what did I write before, and how do I get it back into my editor fast — and that answering it in six commands is a feature, not a limitation. Every extra concept is a reason to stop using the tool. The surface is small enough to learn in the first session, which means the habit can form in the first week, and the habit is the product. The six commands are the entire API, and the API is the design.
Snippets as a Second Brain for Code
The habit that makes a snippet manager pay for itself is capture-at-discovery: the moment you solve a problem, the solution gets saved, named, and tagged, in the same motion as the solve. Not later. Not: I will organize my snippets on the weekend. The weekend version never happens, and the value of a snippet decays fastest in its first week, when the context is still fresh and the name is still obvious. Capture-at-discovery turns snippets into a second brain: a store of your past decisions that is searchable at the moment of need. The tool is the easy part; the habit is the product. But the tool has to make the habit costless — one pipe, one name, one tag — or the habit will not form. The cost has to be lower than the cost of the next time you need it, and the next time is always sooner than you think. A second brain for code is not a collection; it is a reflex, and the reflex is built from the same six commands, run in the same order, every time a problem gets solved. Consistency is the compounding.
The 30-Minute-a-Day Math
Time to verify: how often do you re-derive code you have written before? The honest answer for a working developer is several times a day — a config block, a shell pipeline, a regex, a deploy command. Each re-derivation costs a few minutes at best and a few hours at worst, when the quick version has a subtle bug that the original had fixed. If the average is even fifteen minutes a day, a snippet manager that cuts that in half is worth a full workday a month. The tool is a few seconds of setup; the payback is measured in hours per quarter. I am not claiming precision here — the point is the order of magnitude. Any tool that saves thirty minutes a day is not a toy, and the snippet manager is one of the few where the math is that straightforward, because the cost of the alternative is visible in your own calendar: the afternoon you spent rewriting the deploy script you wrote last spring, the hour you spent re-deriving the regex you could have searched for. The math does not need to be exact to be decisive.
The Migration: From Bookmarks to Snippets
Moving snippets out of browser bookmarks is a one-afternoon project with a permanent payoff. The process: open the bookmark folder, and for each entry decide whether it is a snippet — code you will reuse — or a reference — a page you will read. Save the snippet code with a name that describes the job, not the source. The names are the part that makes or breaks the migration: a name after the source page is useless, a name after the job is searchable. After the migration, the browser keeps the reference pages and the terminal keeps the code, and each is doing the job it is good at. The bookmarks that were doing two jobs badly become two collections, each doing one job well. That is the entire argument for the migration, and it is enough. The afternoon is the only cost, and the payoff is every retrieval for the rest of your career, each one a few seconds faster and a few bugs fewer, because the code you are pasting is the code that worked, not the code you are reconstructing from a page you have to scroll through.
The takeaway
That is the version of events, unedited. If you are reading it to decide whether to use @wuchunjie/snippetx, the most useful paragraph is the one about the constraint that shaped the design — that is where the tool's character comes from, and character is what you are actually adopting when you adopt a tool. The repository at https://github.com/wuchunjie00/snippetx has the code, the issues, and the discussions; the fastest way to vote with your hands is npx @wuchunjie/snippetx. And if the story made you want to see the rest — how dotguard, gitpulse, and snippetx came out of the same habit — each of them has its own build story. ko-fi.com/wuchunjie if any of it was useful. The stories are the documentation that survives, because people remember the story and forget the feature list.
Top comments (0)