I’d commend @Russel’s observations here. To flesh that out a bit…
A container for prototypes. Of course, if you add a built-in prototype, Tinderbox makes a root-level ‘Prototypes’ container for you with the added benefit that its $OnAdd is set to make any new child (but not descendant) note into a prototype automatically. So, for a new doc, I generally do that even if I then delete the prototype added as I’ll use my own. There is a valid exception to this. If you’re using a small doc and a single map there is some merit in just placing the prototype notes in a corner of the map. You can rein-force this with a smart adornment (query: $IsPrototype==true) which automatically gathers any prototype.
Naming prototypes. I think the underlying point is to use names that will be unique. Generally I use a lowercase ‘p’ and then CamelCase or underscores. So: pNote, pRefNotes or `pRef_notes". My experience is that any naming method that says to you ‘this is not a normal note name’ is good and that trumps consistency of naming for those who aren’t obsessive about everything matching ( Tinderbox is very forgiving for ad hoc incremental formalisation - one of the things I like most about it).
Drawing two of those themes together, if you decide you want to make an existing note into a prototype it’s worth copying/duplicating the note and making one copy the new prototype. You can then reset all the already-set but not generic attributes. Now make a new note and set it to use the new prototype. Then copy across, from the original note all the non-generic stuff like $Text and delete the original. Now the style of the source note is cleanly passed to prototype and the ‘original’ note only has per-note attributes for things like $Text as opposed to $Shape, $Color, $Badge which it now inherits.
Edit: corrected reference to wrong user at paragraph #1.