Attaching Callbacks to Standard Drush Commands
Take a look at the sync_enable.drush.inc example file.  If you configure this example as it describes, then your alias file can be configured to disable any modules that you do not want to have enabled on staging or dev sites.  This is presuming that you are copying your database from @prod down to @stage or @dev.  Disabling as sql-sync time is probably best, as this will protect you if, for example, someone clears the caches through the admin interface on a dev machine.

If you do need to run code prior to the cache-clear command, you can easily do so, as Drush does provide a general callback mechanism that can be used to hook any Drush command.  sync_enable is just one example of this; a policy file is another example of the same thing.

To get started, first you will need a Drush commandfile.  We'll call it mycf.drush.inc in this example.  Drush will tell you what hooks are available for a command if you specify the --show-invoke global option.  There are many many possible hook functions, so you'll probably want to pipe the output through grep, and filter on your commandfile name.

$ drush cc all --show-invoke 2>&amp;1 | grep mycf

drush_mycf_cache_clear_pre_validate
drush_mycf_cache_clear_validate
drush_mycf_pre_cache_clear
drush_mycf_cache_clear
drush_mycf_post_cache_clear

In your case, you would want to implement the function drush_mycf_pre_cache_clear(), and put whatever guard function you wanted in there.

I'm not sure what you are asking vis-a-vis patch files and bash scripts &amp; c.; perhaps ask this part in another question with more specific details, if the Drush pre-and-post command hooks do not solve the problem for you.