Skip to content


Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Gemsmith is a command line interface for smithing Ruby gems. Perfect for when you need a professional and robust tool beyond Bundler's basic gem skeletons. While Bundler is great for creating your first gem, you’ll quickly outgrow Bundler when creating and maintaining multiple gems. This is where Gemsmith can increase your productivity by providing much of the tooling you need from the start with the ability to customize as desired.


  • Supports all Rubysmith features.

  • Supports basic gem skeletons or more advanced Command Line Interface (CLI) skeletons.

  • Supports gem building, installing for local development, and publishing.

  • Supports the editing and viewing of installed gems.


  1. A UNIX-based system.

  2. Ruby.

  3. RubyGems.


To install, run:

gem install gemsmith


Command Line Interface (CLI)

From the command line, type: gemsmith --help

  -b, --build NAME [options]               Build new project.
  -c, --config ACTION                      Manage gem configuration: edit or view.
      --edit GEM                           Edit installed gem in default editor.
  -h, --help                               Show this message.
  -i, --install [NAME]                     Install gem for local development.
  -p, --publish [NAME]                     Publish gem to remote gem server.
  -v, --version                            Show gem version.
      --view GEM                           View installed gem in default browser.

      --[no-]amazing_print                 Add Amazing Print gem. Default: true.
      --[no-]bundler-leak                  Add Bundler Leak gem. Default: true.
      --[no-]caliber                       Add Caliber gem. Default: true.
      --[no-]circle_ci                     Add Circle CI configuration and badge. Default: false.
      --[no-]citation                      Add citation documentation. Default: true.
      --[no-]community                     Add community documentation. Default: false.
      --[no-]conduct                       Add code of conduct documentation. Default: true.
      --[no-]console                       Add console script. Default: true.
      --[no-]contributions                 Add contributions documentation. Default: true.
      --[no-]debug                         Add Debug gem. Default: true.
      --[no-]funding                       Add GitHub funding configuration. Default: false.
      --[no-]git                           Add Git. Default: true.
      --[no-]git_hub                       Add GitHub templates. Default: false.
      --[no-]git-lint                      Add Git Lint gem. Default: true.
      --[no-]guard                         Add Guard gem. Default: true.
      --[no-]license                       Add license documentation. Default: true.
      --max                                Use maximum/enabled options. Default: false.
      --min                                Use minimum/disabled options. Default: false.
      --[no-]rake                          Add Rake gem. Default: true.
      --[no-]readme                        Add readme documentation. Default: true.
      --[no-]reek                          Add Reek gem. Default: true.
      --[no-]refinements                   Add Refinements gem. Default: true.
      --[no-]rspec                         Add RSpec gem. Default: true.
      --[no-]security                      Add security. Default: true.
      --[no-]setup                         Add setup script. Default: true.
      --[no-]simple_cov                    Add SimpleCov gem. Default: true.
      --[no-]versions                      Add version history. Default: true.
      --[no-]yard                          Add Yard gem. Default: false.
      --[no-]zeitwerk                      Add Zeitwerk gem. Default: true.
      --[no-]cli                           Add command line interface. Default: false.


The core functionality of this gem centers around the --build command and associated flags. The build options allow you to further customize the kind of gem you want to build. Most build options are enabled by default. For detailed documentation on all supported flags, see the Rubysmith documentation.

The build option which is unique to Gemsmith is the --cli option. This allows you to build a gem which has a Command Line Interface (CLI). There are multiple ways a CLI can be built in Ruby but Gemsmith takes an approach which builds upon Ruby’s native OptionParser with help from Dry Container. All of this culminates in a design that is mix of Objected Oriented + Functional Programming design. Building a gem with CLI support is a simple as running:

gemsmith --build demo --cli

The above will give you a new gem with CLI support which includes working specs. It’s the same design used to build this Gemsmith gem. You’ll have both a configuration and CLI namespace for configuring your gem and adding additional CLI support. Out of the box, the CLI gem generated for you supports the following options:

  -c, --config ACTION                      Manage gem configuration: edit or view.
  -h, --help                               Show this message.
  -v, --version                            Show gem version.

From here you can add whatever you wish to make an awesome CLI gem for others to enjoy.


After you’ve designed, implemented, and built your gem, you’ll want to test it out within your local environment by installing it. You can do this by running:

# Implicit
gemsmith --install

# Explicit
gemsmith --install demo

Gemsmith can be used to install any gem, in fact. Doesn’t matter if the gem was built by Gemsmith, Bundler, or some other tool. As long as your gem has a *.gemspec file, Gemsmith will be able to install it.


Once you’ve built your gem; installed it locally; and thoroughly tested it, you’ll want to publish your gem so anyone in the world can make use of it. You can do this by running the following:

# Implicit
gemsmith --publish

# Explicit
gemsmith --publish demo

Security is important which requires a GPG key for signing your Git tags and RubyGems Multi-Factor Authentication for publishing to RubyGems. Both of which are enabled by default. You’ll want to read through the linked article which delves into how Gemsmith automatically makes use of your YubiKey to authenticate with RubyGems. Spending the time to set this up will allow Gemsmith to use of your YubiKey for effortless and secure publishing of new versions of your gems so I highly recommend doing this.

As with installing a gem, Gemsmith can be used to publish existing gems which were not built by Gemsmith too. As long as your gem has a *.gemspec file with a valid version, Gemsmith will be able to publish it.


Gemsmith can be used to edit existing gems on your local system. You can do this by running:

gemsmith --edit <name of gem>

If multiple versions of the same gem are detected, you’ll be prompted to pick which gem you want to edit. Otherwise, the gem will immediately be opened within your default editor (or whatever you have set in your EDITOR environment variable).

Editing a local gem is a great way to learn from others or quickly debug issues.


Gemsmith can be used to view existing gem documentation. You can do this by running:

gemsmith --view <name of gem>

If multiple versions of the same gem are detected, you’ll be prompted to pick which gem you want to view. Otherwise, the gem will immediately be opened within your default browser.

Viewing a gem is a great way to learn more about the gem and documentation in general.


This gem can be configured via a global configuration:


It can also be configured via XDG environment variables.

The default configuration is everything provided in the Rubysmith with the addition of the following:

  :cli: false

Feel free to take the combined Rubysmith + Gemsmith configuration, modify, and save as your own custom configuration.yml.

It is recommended that you provide URLs for your project which would be all keys found in this section:

    # Add sub-key values here.

When these values exist, you’ll benefit from having this information added to your generated gemspec and project documentation. Otherwise — if these values are empty — they are removed from new gem generation.


When building/testing your gem locally, a typical workflow is:

# Build
gemsmith --build demo

# Design, Implement and Test.
cd demo
bundle exec rake

# Install
gemsmith --install

# Publish
gemsmith --publish


Git Signing Key

To securely sign your Git tags, install and configure GPG:

brew install gpg
gpg --gen-key

When creating your GPG key, choose these settings:

  • Key kind: RSA and RSA (default)

  • Key size: 4096

  • Key validity: 0

  • Real Name: <your name>

  • Email: <your email>

  • Passphrase: <your passphrase>

To obtain your key, run the following and take the part after the forward slash:

gpg --list-keys | grep pub

Add your key to your global Git configuration in the [user] section. Example:

  signingkey = <your GPG key>

Now, when publishing your gems with Gemsmith (i.e. bundle exec rake publish), signing of your Git tag will happen automatically.

Gem Certificates

To create a certificate for your gems, run the following:

cd ~/.ssh
gem cert --build
chmod 600 gem-*.pem

The resulting .pem key files can be referenced via the signing_key and cert_chain of your .gemspec which Gemsmith provides for you via the --security build option. Example:

# frozen_string_literal: true do |spec|
  # Truncated for brevity.
  spec.signing_key = Gem.default_key_path
  spec.cert_chain = [Gem.default_cert_path]

To learn more about gem certificates, read about RubyGems Security.

Private Gem Servers

By default, the following command will publicly publish your gem to RubyGems:

gemsmith --publish

You can change this behavior by adding metadata to your gemspec that will allow Gemsmith to publish your gem to an alternate/private gem server instead. This can be done by updating your gem specification and RubyGems credentials.

Gem Specification Metadata

Add the following gemspec metadata to privately publish new versions of your gem: do |spec|
  spec.metadata = {"allowed_push_host" => ""}

💡 The gemspec metadata (i.e. keys and values) must be strings per the RubyGems Specification.

Use of the allowed_push_host key provides two important capabilities:

  • Prevents you from accidentally publishing your private gem to the public RubyGems server (default behavior).

  • Defines the lookup key in your $HOME/.gem/credentials file which contains your private credentials for authentication to your private server (more on this below).

Gem Credentials

With your gem specification metadata established, you are ready to publish your gem to a public or private server. If this is your first time publishing a gem and no gem credentials have been configured, you’ll be prompted for them. Gem credentials are stored in the RubyGems $HOME/.gem/credentials file. From this point forward, future gem publishing will use your stored credentials instead.

Multiple credentials can be stored in the $HOME/.gem/credentials file as well. Example:

:rubygems_api_key: 2a0b460650e67d9b85a60e183defa376 Basic dXNlcjpwYXNzd29yZA==

Notice how the first line contains credentials for the public RubyGems server while the second line is for our private example server. You’ll also notice that the key is not a symbol but a URL string to our private server. This is important because this is how we link our gem specification metadata to our private credentials. To illustrate further, here are both files truncated and shown together:

# Gem Specification: The metadata which defines the private host to publish to.
spec.metadata = {"allowed_push_host" => ""}

# Gem Credentials: The URL value -- shown above -- which becomes the key for enabling authentication. Basic dXNlcjpwYXNzd29yZA==

When the above are linked together, you enable Gemsmith to publish your gem using only the following command:

gemsmith --publish

This is especially powerful when publishing to GitHub Packages which would look like this when properly configured (truncated for brevity while using fake data):

# Gem specification
spec.metadata = {"allowed_push_host" => ""}

# Gem credentials Bearer ghp_c5b8d394abefebbf45c7b27b379c74978923

Lastly, should you need to delete a credential (due to a bad login/password for example), you can open the $HOME/.gem/credentials in your default editor and remove the line(s) you don’t need. Upon next publish of your gem, you’ll be prompted for the missing credentials.

Bundler Configuration

So far, I’ve shown how to privately publish a gem but now we need to teach Bundler how to install the gem as dependency within your upstream project. For demonstration purposes, I’m going to assume you are using GitHub Packages as your private gem server. You should be able to quickly translate this documentation if using an alternate private gem server, though.

The first step is to create your own GitHub Personal Access Token (PAT) which is fast to do by following GitHub’s own documentation. At a minimum, you’ll need to enable repo and packages scopes with read/write access.

With your PAT in hand, you’ll need to ensure Bundler can authenticate to the private GitHub Packages gem server by running the following:

bundle config set --global <your GitHub handle>:<PAT>
# Example: bundle config set --global jdoe:ghp_c5b8d394abefebbf45c7b27b379c74978923

💡 Using Bundler’s --global flag ensures you only have to define these credentials once for all projects which reduces maintenance burden on you. The path to this global configuration can be found here: $HOME/.config/bundler/configuration.yml.

Lastly, you can add this gem to your Gemfile as follows:

source "" do
  gem "demo", "~> 0.0"

At this point — if you run bundle install — you should see the following in your console:

Fetching gem metadata from
Resolving dependencies...Fetching gem metadata from

If so, you’re all set!

GitHub Actions/Packages Automation

Earlier, I hinted at using GitHub Packages but what if you could automate the entire publishing process? Well, good news, you can by using GitHub Actions to publish your packages. Here’s the YAML necessary to accomplish this endeavor:

name: Gemsmith

    branches: main

    runs-on: ubuntu-latest
      image: ruby:latest
      contents: write
      packages: write

      - name: Checkout
        uses: actions/checkout@v3
          fetch-depth: '0'
          ref: ${{github.head_ref}}
      - name: Setup
        run: |
          git config ""
          git config "Gemsmith Publisher"
          mkdir -p $HOME/.gem
          printf "%s\n" " Bearer ${{secrets.GITHUB_TOKEN}}" > $HOME/.gem/credentials
          chmod 0600 $HOME/.gem/credentials
      - name: Install
        run: gem install gemsmith
      - name: Publish
        run: |
          if git describe --tags --abbrev=0 > /dev/null 2>&1; then
            gemsmith --publish
            printf "%s\n" "First gem version must be manually created. Skipping."

The above will ensure the following:

  • Only the first version requires manual publishing (hence the check for existing Git tags).

  • Duplicate versions are always skipped.

  • Only when a new version is detected (by changing your gemspec version) and you are on the main branch will a new version be automatically published.

This entire workflow is explained in my talk on this exact subject too.


To contribute, run:

git clone
cd gemsmith

You can also use the IRB console for direct access to all objects:



To test, run:

bundle exec rake


Engineered by Brooke Kuhlmann.


A command line interface for smithing Ruby gems.







Sponsor this project



No packages published