Snippet Naming Conventions That Keep a Library Usable
A naming convention for triggers and snippets that keeps a growing library searchable and memorable — the governance habits that keep a set from rotting.
A snippet library rarely fails for being too small. It fails when it grows past the point where anyone can remember the triggers or find a snippet by name — you end up with //email2, //newtemplate, and three things that all start with //follow, none of which you can recall mid-task. The fix is boring and powerful: a naming convention for triggers and titles, agreed once, that keeps the library searchable as it grows.
This guide gives you a naming convention you can adopt today and the governance habits that stop a useful library from rotting.
Why naming is the real scaling problem
Every snippet tool makes it easy to add a snippet and does nothing to keep the set coherent. So the failure mode is always the same: the library grows, triggers collide or get cryptic, and people stop using snippets because guessing the trigger is slower than retyping the text. The content was never the problem — the retrieval was. A naming convention is just a shared, predictable way to answer "what would I have called this?" so the trigger comes to mind without a search.
A convention also matters more the moment a second person is involved. Two people naming snippets freely will never converge; two people following the same rule will land on the same trigger for the same job — which is what makes a set shareable at all.
How should I name triggers so I actually remember them?
Name the trigger after the moment you reach for it, not the format of the text. You remember situations, not file names:
- Lead with the context, short:
//sales,//cs,//qa,//rec(recruiting). - Then the specific moment:
//sales-fu(follow-up),//cs-renewal,//qa-release. - Keep it pronounceable and short — if you cannot say it in your head, you will not recall it.
- Avoid numbers as the only difference.
//fu1///fu2is fine for an ordered sequence;//email1///email2is a future mystery.
The test for a good trigger: a teammate who has never seen your library should be able to guess it from the situation. If they cannot, the name is wrong.
A naming convention you can adopt today
A simple two-part scheme — context-moment — scales from ten snippets to a hundred without collisions.
Pattern: //<context>-<moment>
Sales: //sales-intro //sales-fu //sales-pricing
Recruiting: //rec-screen //rec-invite //rec-decline
Support: //sup-ack //sup-bug //sup-refund
Customer succ //cs-onboard //cs-renewal //cs-checkin
Dev / QA: //qa-release //pr-block //pr-nit
Personal: //me-sig //me-cal //me-address
Titles (what shows in the /// browse menu) follow the inverse rule: write them as a human phrase so search finds them — "Sales — first follow-up email", not "fu1". The trigger is for muscle memory; the title is for search. Naming both well means you can reach a snippet two ways — type the trigger you remember, or open /// and search the words you would describe it with.
Governance habits that keep the library healthy
A convention only holds if a few habits hold with it:
- One owner per context. Someone owns
//sales-*, someone owns//sup-*. Owners prevent two people from minting//sales-fuand//sales-followupfor the same thing. - Prune on a cadence. Once a quarter, delete snippets nobody triggered. A library you trust is one without dead weight.
- Reserve a prefix for drafts.
//x-...for experiments keeps half-baked snippets from looking official. - Write the convention down once. A three-line note — "triggers are
context-moment, titles are human phrases, prune quarterly" — is the whole governance doc.
Sharing a convention without shared storage
SlashSnip keeps snippets local to each browser and does not offer cloud sync or shared team libraries yet. That changes how a team adopts a convention but not whether it can: you agree on the context-moment scheme, and each person applies it to their own local set. To get everyone the same starting library, export a reviewed set and have teammates import it — the import and export guide covers moving a snippet set between browsers as a file. From there the shared convention keeps everyone's triggers predictable even though the storage is independent.
For the team-sharing model in more depth, the shared team templates guide covers how a local-first set is distributed today, and the starter-pack guide covers which snippets to create first so the convention has something to organize.
Next steps
Pick your contexts (most teams need three or four), write the one-line convention, and rename your existing snippets to match before the library grows further — retrofitting names later is the painful version. The import/export guide shows how to share a reviewed set, and the free tier summary covers the current plan.
Keep going with the same intent cluster
Build a snippet starter pack
Move from article context into docs, workflow pages, pricing, or comparisons.
Shared team templates, kept local
Move from article context into docs, workflow pages, pricing, or comparisons.
Import and export your snippets
Move from article context into docs, workflow pages, pricing, or comparisons.
Pricing and current plan boundaries
Move from article context into docs, workflow pages, pricing, or comparisons.
Guide
Candidate Screening Reply Templates Recruiters Can Reuse
Screening replies are the highest-volume, lowest-variety messages a recruiter sends. Here is a small set of advance, hold, and decline templates that stay warm and consistent — pasted in with a trigger.
Guide
Cold Email Follow-Up Cadence Snippets That Stay Consistent
Most follow-up emails get worse the further into a cadence you go, because reps improvise each one. Here is a small set of follow-up snippets that keep every touch consistent — pasted into the compose field with a trigger.
Guide
CRM Note Templates Sales Reps Actually Reuse
Most CRM notes are unstructured and unsearchable a week later. Here is a small set of reusable note templates that keep call logs consistent — typed straight into the note field with a short trigger.