typesof("/proc") //global procs (user defined only, built ins don't show)
typesof("/mob/proc") //mob procs (generally user defined only, some time builtins show but they mostly don't)

You can also do the same with /verbs
This is documented, and how most admins system add/remove commands.
In response to Nadrew
Except, it's used with type path literals, not strings:

Of course, strings let you build the path at runtime.
I used strings mainly for the /proc version, because i do not think byond recognizes /proc on its own as a path
Things get super weird with call(), typesof() and overrides though.

I'm pretty strict about taking advantage of polymorphism and not leaving structural assumptions in my code without an internal safety check or some standard capability flag foo in the works, and I've run into all kinds of weirdness in the process.

It's almost like writing code in DM actively discourages proper design principles.
Things like this are generally for doing things at runtime.

You could use such a system to modularly initialize and bring compiled code into a system at runtime, like dynamically get every hook an object has subscribed to by looking at what it has defined, so that you don't have to make the master proc defined at some silly level or add vars/flags to define what hooks something listens to.

Why add a subscribe step to a hooks and events system when you can make defining the proc auto subscribe?
I tend to avoid using strings in typesof() unless absolutely necessary (like the case of /proc MSO mentioned), you lose the compile-time error checking and things can get a bit weird with non-standard types and stuff of that nature.
I'd rather have a "procs" list like the "verbs" list honestly instead of having to rely on typesof(), which will go a bit weird if you have awkward parent_type setups and things of that nature (in edge cases most of the time though). But we make due with what we've got =P
the verbs lists can be changed and added to and removed from and blanked out, and is a per-object list.

typesof(/type/verb) would actually be a better list.
You could use initial(atom.verbs) and avoid the overhead. You don't even actually need to initialize the atom for it to work. (It should work at least, I can't test it right this moment).