Sounds like a good name.
I think it makes sense to include the mission briefing code, particularly if it doesn't change between levels. You can put all the related files in the project folder. At the very least, if it's inappropriate to use them directly from the library, you could put them in a Sample folder, so people can just copy out of there.
In C/C++ you can do some really strange things with header files. Part of that stems from just how incredibly simple the system works, which has lots of complicated side effects. A #include statement is equivalent to an in-place copy-paste of the included file's contents. That's it. A C/C++ compiler doesn't know anything particularly special about header files. It only knows how to compile C/C++ code, which it expects in a .c or .cpp file. What goes in a header file is just convention, as is the extension ".h".
What you should put in a header file is largely dictated by what a C/C++ compiler will do if it encounters the same code in two separate "compilation units" (roughly, two separate .cpp files, along with all their #included content pasted in). A struct or class declaration can be repeated without problem. It tells the compiler the format of a structure, but does not allocate any space for it. It only dictates how other code will interact with such objects. On the other hand, a function which is compiled and takes up space in the code section should not be repeated. A global variable which takes up space in the data section should not be repeated. You can declare an extern global variable in a header file, which lets the compiler know a variable with a given name and type is defined somewhere, but the actual definition should only appear once.
If a header file declares a single function, there isn't much savings in typing to declare that function at the start of a .cpp file that needs it, as opposed to including a header file with the declaration. In either case, it's one line of code that is basically pasted into the start of the .cpp file. Hence, for a single function, particularly one with no parameters, people will sometimes omit a header file.
If you want to see what the compiler sees, run the compiler with an option to only do the pre-precessing step. It should output a new source file with all the #includes pasted in, and all the macros expanded. The result is what the compiler actually sees, and what actually needs to be valid C/C++ code. A C/C++ compiler actually implements two languages. The C/C++ pre-processor language, and then the C/C++ language. They can have some funny interactions too.
Of course there's nothing stopping you from abusing the #include system. In fact, I highly recommend it. Not in actual practice of course. Just in fun little experiments. There's no need to always stick the #include at the start of your file either. If you wanted, you could put the body of a function in a separate file, write the start and end of a function in your main file, and then #include the body of the function from inside the wrapper. Not much point, but it works.
If you really want to twist your brain about, read up on
X-Macros. By making use of #define before #include, you can include header files more than once, with a different effect each time. This is actually a very clever and sometimes useful way of abusing the system. This is some acceptance behind this method when it's done in a clean way. There are also many code obfuscation examples when this is done in a non-clean way.
You can find some examples of
X-Macros using #include on WikiBooks.
It's a little off topic, but fun, and educational. If you can get your head around that stuff, you should be better able to reason about header files, and what should go where.
