I'm not 100% sure how I feel about this and ideally I'd like to talk it over in person with Hunner next week before I commit.  I think this is an improvement on the existing skeleton but it obviously enforces more of a standardized workflow on modules than exists today, and I want to be sure we get this right going forward.

I generally build most "generic" modules with an x, x::install, x::config, x::service and the various boilerplate to make them easy to stop/start and pass in specific versions to, so I generally appreciate the changes proposed in this skeleton as it's much closer to what I'd be looking for.

However, having said that it brings in the ability to set packages absent by default and I'm not sure how useful that is to users.  It also adds a file{} for _config that drags in from a template and I don't know if users are going to want that every time.

I suppose my issue here is the more skeleton we bring in the more users have to delete to get going if their module standards differ and that's going to annoy them.

I'd like to whiteboard this up with @hunner first and talk more in depth first.

(If I had my ideal world we would have several skeletons and the ability to choose one with module generate.  Something like:  puppet module generate --type=generic, or --type=barebones, or --type=provider or something.  Something like that, anyway.  Or at least the ability to toggle features on and off in a skeleton so that users who don't use testing can ditch spec/ and so forth.  I don't quite know how this would look but I do know a one size fits all rarely works in Puppet)