a fork of Metasploit set up and ready to run, and that you have added in your SSH keys
(see [Adding a New SSH Key To Your GitHub Account](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)),
set up Ruby and optionally the PostgreSQL database, and done any custom shortcuts you wish to configure.
to your PR being rejected if these changes are too complex.
## Making Sure Your Gems Are Updated
The next step is to make sure you have the latest copy of the Gems that Metasploit Framework depends on. This can be done by running `bundle install`
from the same directory as where the `Gemfile.lock` file is located, which will be in the same folder as wherever you cloned your fork to locally.
Doing this will allow you to make sure that you are running the latest libraries, which will ensure if you do encounter any bugs whilst
developing code, those bugs are not related to out of date Gems being installed, and are therefore potentially legitimate bugs that need fixing.
## Creating a New Branch for Your Code
Once all of this is done, you will want to create a new branch for your code, which can be done by running `git checkout -b <your branch name here>`.
This will snapshot the current branch that you are on, and use that to create a new branch with the name provided. Note that I did say snapshot. This is
to be 50 characters or less while telling readers what was changed in that commit. You generally don't want to create commits that do multiple things at once,
instead create a separate commit for each group of items that you are changing, and make sure that the commit message reflects what changed in a general sense.
Note also that maintainers may end up squashing your commits down so that your commit A, B, and C, now become commit D which
contains all of the same changes as commit A, B, and C, but in one commit and with one associated commit message. This is often
done when the code is ready to be landed into Metasploit Framework to help make the commit history easier for people to read.
## Checking for Code Errors
Before code can be accepted into Metasploit Framework, it must also pass our RuboCop and MsfTidy rules. These help ensure that
all contributors are committing code that follows a common set of standards. To check if your code meets our RuboCop standards,
As a good practice rule, you should always separate your commits that contain RuboCop changes from those that contain non-RuboCop related changes.
This helps ensure that when it comes time to review your code, review can proceed a lot quicker and more efficiently.
Note that special cases exist if you are writing library code as our RuboCop rules are primarily designed to be run against modules.
If at any point you are confused r.e this, please feel free to reach out and ask us for help on Slack at https://metasploit.com/slack.
Once this is done, the next tool to run is located in the root of the Metasploit local fork at `tools/dev/msftidy.rb`. You will want to run this tool
against your module code (if applicable), using `tools/dev/msftidy.rb <path to module>`. This will give some output if there are any errors, or no output
if your module passed the tests. Try and fix any errors mentioned here.
## Writing Documentation
The next step to do, if you are writing a module, is to write the documentation for the module. You can find some information
on how to write module documentation at [Writing Module Documentation](https://docs.metasploit.com/docs/development/quality/writing-module-documentation.html).
In general when writing documentation you will want to search for a similar documentation file under the `documentation`
folder located in the root of the Metasploit fork. You can then copy one of these files and use it as the basis for writing
your new documentation for your module.
When writing the information for the documentation, be sure to make sure your installation steps are as clear as possible. Any confusion over
how to set up the target to be exploited will likely result in delays. You will want to put as much detail here as possible.
Additionally any information about caveats, scenarios you have tested, custom options you added in, or quirks you noticed
should also go into this file.
## Checking Documentation Syntax
Once you have written the documentation, you then want to run `toos/dev/msftidy_docs.rb <path to documentation file>`. This will report on any
errors with your documentation file, which you will want to fix before submitting your PR. Notice however that if you get a warning about long lines,
these may be okay to ignore depending on the context. A good example is if a line is long merely because of a URL. Such warnings can be
