The month was a trial, and the trial was every snippet application that could be installed. The applications were good, and that is what made the month a test of the category instead of a search for the best one. The applications had sync, and sync was the feature, and sync was what cost the subscription, and the subscription was what cost the trust. The sync puts the snippets on the server. The snippets contain the credentials. The month kept coming back to that one chain.
The winner was not an application. The winner was the terminal, which the month started with and finished with, because the terminal's snippet store is a file on the machine, and the file does not sync, and the not-syncing is the feature. The applications' business model is the sync; the terminal's business model is the file. The section below is the month in detail: the applications, the features, the costs, the trust questions, and the six commands that won, because the six commands are the thing the applications do not compete with. They are add, list, show, search, rm, and copy, and the six commands are the whole workflow, and the whole workflow is the one that does not need a server.
Every tool has a before and an after, and the story is the after, told from the inside, which means the story includes the part that did not work and the part that was not the tool's fault, because the not-fault is the part the ad leaves out and the story keeps. The tool is snippetx: Terminal code snippet manager: save, search, and copy snippets with six commands. Local-first, zero dependencies.. The install line is npx @wuchunjie/snippetx, and the line is in the story at the moment the story's character ran it, because the moment is where the line belongs, and the belongs is what the feature list does not give. The sections below are the story in the order it went, and the order is the part that makes the ending the ending instead of the claim.
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.
Search That Finds the Right Snippet
A snippet collection is only as good as its search, because the failure mode of a bad search is: I will just rewrite it. The tool searches by term across snippet names and content, and the list command filters by language, so the two together cover the two ways you actually recall a snippet: by what it is — a route, a regex, a deploy script — and by what it is made of — the framework, the command, the config key. The search is exact and fast because the corpus is small and local: hundreds of snippets, not millions, and no network round trip. The practical test is the ten-second rule: if finding the snippet takes longer than rewriting it, the tool has failed. On a well-named local collection, finding beats rewriting in most cases, and that gap is the entire value. The naming is the skill, and the skill is cheap: name the snippet for the job it does, not the project it came from, and the job outlives the project. The search finds jobs; that is what makes the collection compound instead of rot.
Pipe In, Pipe Out: The Native Workflow
The terminal's native data flow is the pipe, and the snippet manager speaks the pipe natively, which is the property the app does not have. The pipe in is the capture: the command's output goes into the add command, and the capture is the motion that happens at the solve, because the solve is the output, and the output is what the pipe carries. The pipe out is the handoff: the copy command's output goes to the clipboard, and the handoff is the motion that happens at the use, because the use is the paste, and the paste is what the clipboard feeds. The two pipes are the whole workflow, and the whole workflow is the thing that never leaves the terminal, because the terminal is where the developer is, and the not-leaving is the part that the app's window-switch costs, and the window-switch is the second that adds up to the minute, and the minute is what the habit dies in.
Pruning: The Monthly Session
The collection that only grows becomes the second mess, and the second mess is the failure mode the remove command exists to prevent. The prune is the monthly session, and the session is the read of the list with the question: is this the thing I still do? The snippet that the job changed is the snippet that goes, because the job is what the snippet is for, and the changed job is the changed for. The snippet that the better version replaced is the snippet that goes, because the better is what the search returns now, and the search-returns is the part the old one loses. The prune is five minutes, and the five minutes is the cost of the collection staying small enough to list in one screen, and the one-screen is the part that the list is useful in, because the list that pages is the list that is not read, and the not-read is the collection that is not used. The remove is the unglamorous command, and the unglamorous is the one that keeps the tool a tool instead of an archive.
Where the Snippets Live, and Why That Is the Point
The snippets live on the machine, and the on-the-machine is the security property, because the machine is what the developer controls and the developer's control is what the credential in the snippet needs. The snippet that holds the deploy command holds the host, and the host is the infrastructure, and the infrastructure is the thing that the vendor's server would be a copy of, and the copy is the part that the breach reaches. The local store's breach surface is the machine's breach surface, and the machine's surface is the laptop's lock, the disk encryption, the user account, and the three are the controls the developer already has. The cloud store adds the vendor's surface to the developer's surface, and the added surface is the vendor's retention, the vendor's access, the vendor's incident history, and the three are the controls the developer does not have. The on-the-machine is the smaller surface, and the smaller surface is the point, because the point is the credential, and the credential is the snippet that matters most, and the most-matters is the one that should be on the smallest surface.
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.
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.
Naming a Snippet So You Can Find It Later
The name is the interface between the developer of the week and the developer of the month, and the month does not remember what the week called the thing. The naming rule that survives the month is the job name: the name describes what the snippet does, not where it came from. The deploy command is named for the deploy, not for the blog post it was copied from, because the blog post is the part that is not remembered and the deploy is the part that is. The second rule is the category tag, and the tag is the folder, and the folder is what the list groups by, and the group is what the scan finds before the name does. The third rule is the one word that must be in the name: the verb, because the verb is what the developer types when the developer is in the middle of the job, and the middle-of-the-job is the moment the search happens. The three rules are the naming convention, and the convention is the part that makes the collection findable instead of just present.
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 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.
The Collection Is a File: Backup and Migration
The storage is a directory of text files on the machine, and the directory is the property that makes the backup and the migration trivial, because the trivial is the copy and the move. The backup is the directory into the backup location, and the backup location is the sync folder, the external drive, the git repository, and the three are the same operation with different destinations. The migration to the new machine is the directory to the new home, and the home is the path the command expects, and the expects is the part that the setup documents, and the documents is the thing the new machine reads once. The cloud collection's backup is the export, and the export is the format the vendor chose, and the chose is the part that changes with the vendor's version, and the changes is the part that breaks the import. The file's backup is the file, and the file is the format that does not change, because the format is the text, and the text is the part that outlives the tool that stored it.
The takeaway
The ending of the story is the state, and the state is the part the tool holds. snippetx is Terminal code snippet manager: save, search, and copy snippets with six commands. Local-first, zero dependencies., and the install is npx @wuchunjie/snippetx, and the repository is https://github.com/wuchunjie00/snippetx. The reader at the end of the story is the reader who has the before, and the before is the part the story gave, because the gave is the specific date and the specific number and the specific moment, and the three are what the general article does not. The state above is the one the story reached, and the reached is the part the next story starts from, and the starts-from is what the habit is.
Top comments (0)