Skip to content
Back to blog
Guide6 min read

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.

May 28, 2026

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:

  1. Lead with the context, short: //sales, //cs, //qa, //rec (recruiting).
  2. Then the specific moment: //sales-fu (follow-up), //cs-renewal, //qa-release.
  3. Keep it pronounceable and short — if you cannot say it in your head, you will not recall it.
  4. Avoid numbers as the only difference. //fu1///fu2 is fine for an ordered sequence; //email1///email2 is 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-fu and //sales-followup for 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