`bundle gem foo` will create a subdirectory `foo` and setup a decent starting skeleton for a gem named 'foo'. I'd maybe suggest 'standard' over 'rubocop' as a

`bundle gem foo` will create a subdirectory `foo` and setup a decent starting skeleton for a gem named 'foo'. I'd maybe suggest 'standard' over 'rubocop' as a linter to begin with. foo/ - foo.gemspec: needs to fix the TODOs to start, and this is where runtime deps will go - Gemfile: where your development deps will go - Gemfile.lock: built by 'bundle install' do not touch - Rakefile: the build system (build gems, push gems, run tests, etc) - bin/ drop binary scripts here or delete if you're making a library (generally make them tiny stubs that require "foo" or "foo/application" and call run on the app or something) - lib/ this is where you put all your code. already setup with lib/foo.rb and lib/foo/version.rb which are accessible via `require "foo"` and `require "foo/version"` mostly you'll want to put code under lib/foo/ and then have `lib/foo.rb` be a pile of require statements (ish). - spec/ this is where tests go. bundler will set you up with rspec installed to begin with with a spec_helper.rb already setup (this is where you tweak rspec). i would suggest using spec/unit/whatever_spec.rb to test lib/foo/whatever.rb and keeping those directory structures roughly in sync for your unit tests. To get started: bundle install # updates all the gems in the Gemfile (plus the referenced gemspec file) and installs rspec and updated rake and stuff bundle exec rake spec # runs all the spec/ tests bundle exec rake # runs rake + rubocop/standard both bundle exec rake -T # shows all the rake tasks bundle exec rake release # will build and push the gem to rubygems publicly