Ten workflows, each with the exact command sequence and the specific time it saves. Workflow one: the capture pipe — echo or cat piped into add, the habit that makes the collection grow without effort, because the capture costs a keystroke and a name, and the cost is lower than the next time you will need it. Workflow two: the fuzzy pick — list into fzf into copy into clipboard, the one-chord retrieval that makes the collection feel like a superpower instead of a database. Workflow three: the search-then-copy — for when you know the content, not the name, which is the common case and the case the naming discipline serves.
Workflow four: the language audit — list with the language filter, which tells you what your codebase is actually made of, a surprising metric in its own right, because the distribution of snippet languages is a map of the work you actually do. Workflow five: the stale sweep — list sorted by age, delete for the snippets that are three versions of the framework old, because a stale snippet is a wrong answer with extra steps. Workflow six: the team share — the collection as a git directory, the pull and the add, the review as a normal pull request. Workflow seven: the CI snippet — a snippet that is a script, run from the collection in a pipeline, versioned with the code. Workflow eight: the onboarding dump — the top twenty snippets by retrieval count, the fastest orientation a new developer gets. Workflow nine: the secret audit — dotguard over the snippet store, because snippets are where secrets hide in plain sight. Workflow ten: the quarterly prune — the full pass, the numbers, the decision to keep or kill each category. Ten workflows, one tool, the specific minutes each one returns.
Lists are a lazy format, and a lazy list is worse than no list, because it costs you ten minutes and gives you nothing. So this one is built to a standard: every item has what it does, when you would actually use it, and the specific failure it prevents. No filler, no and-more. No item that exists only to pad the count. snippetx is the lens — Terminal code snippet manager: save, search, and copy snippets with six commands. Local-first, zero dependencies. — and the list below is the part you can screenshot and keep. If an item does not save you a specific amount of time or a specific kind of pain, it is not on the list, and the items that are on it are ordered by how often they actually earn their place.
Sharing Snippets With a Team (Without a Server)
The team use case is the one that looks like it needs infrastructure and does not. A snippet collection is a directory of text. Sharing it is a git repository: every developer pulls the shared snippets, adds their own to a shared folder, and the review of a snippet is a normal pull request. There is no server to run, no permission model to design, no sync to debug. The git history gives you something a hosted service would charge for: who added what, when, and why, reviewable. The tradeoff is that the team has to agree on naming conventions, which is a conversation, not an engineering problem. For a team of five to fifty, a git-backed snippet library is the boring, durable answer, and the tool is the reader and writer that makes it a workflow instead of a file convention. The pull request is the onboarding: a new developer reads the repository and inherits the team's past decisions, which is the closest a team of developers gets to a shared memory, and it is versioned, so it cannot quietly rot the way a wiki can.
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.
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.
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.
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.
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.
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.
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.
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 list. Screenshot it, pin it, or just remember the three items you will actually use — that is the honest success metric for a list. The tools behind it: npx @wuchunjie/snippetx, source at https://github.com/wuchunjie00/snippetx, and the same npx pattern for the rest of the toolkit. If the list saved you a specific amount of time, ko-fi.com/wuchunjie is a one-click thank-you that keeps every tool free and dependency-free. The next list is already forming, and the items that fail the specific-pain test will not make it. A list that only contains things worth keeping is the only kind of list worth publishing, and that is the standard this one was held to.
Top comments (0)