The Open-Closed principle should be your guide here. Having a single UITableViewController subclass with a "flag variable" that is then checked all over the place inside the class is a very poor design choice. Every time you want to add a new table view controller in your app, you will end up having to dig into the MonsterTableViewController class and add yet another flag and a bunch of switch/if checks to handle the differences. Your class isn't "open for extension and closed for modification" that way.
If you find that you have, say, 3-4 different behaviors when a cell is tapped, but all the rest of the code is the same, then provide your view controller with a delegate or closure that represents the Strategy (à la the Strategy pattern) used when an item is tapped and provide that either at construction time, or if you are using a storyboard to construct, then in the previous prepare for segue.
You can even go so far as to make the strategy class generic and have it hold the array of objects that are used for the datasource. Then provide a closure for both the cellForRowAtIndexPath and the didSelect. Or you could go the more traditional route and make the strategy class a protocol and have several implementations.
Note this is very reminiscent of how UITableViewDatasource and UITableViewDelegate are already handled. What many people end up doing is just having a bunch of classes that implement both of those protocols. Pass an instance of one of those classes to the UITableViewController to handle the details.