diff --git a/docs/requirements.yaml b/docs/requirements.yaml
index a3604287..d28ca113 100644
--- a/docs/requirements.yaml
+++ b/docs/requirements.yaml
@@ -9,6 +9,7 @@ dependencies:
 
     - sphinx
     - mdanalysis-sphinx-theme
+    - sphinxcontrib-youtube
 
     - pyyaml
     - pydantic
diff --git a/docs/source/about.rst b/docs/source/about.rst
index db5dc7c2..c6202305 100644
--- a/docs/source/about.rst
+++ b/docs/source/about.rst
@@ -1,5 +1,7 @@
 .. -*- coding: utf-8 -*-
 
+.. _about-mdakits:
+
 *************
 About MDAKits
 *************
@@ -27,7 +29,7 @@ requirements**:
 #. Minimal documentation is provided (what your code does, how to install it,
    and how to use it)
 #. At least minimal regression tests are present; continuous integration is encouraged
-#. The code is installable as a standard package
+#. The source code is installable as a standard package
 
 It is also highly encouraged that the MDAKit also satisfies:
 
diff --git a/docs/source/add.rst b/docs/source/add.rst
deleted file mode 100644
index df87a75d..00000000
--- a/docs/source/add.rst
+++ /dev/null
@@ -1,160 +0,0 @@
-.. _add-mdakit:
-
-********************************
-Adding an MDAKit to the Registry
-********************************
-
-Do you have an MDAKit? Consider adding it to the `MDAKit registry`_!
-
-
-.. note::   
-   The `MDAKit registry`_ is still in its initial stages. We expect that the way in
-   which MDAKits are added, and the type of information required, may change
-   over time. Please reach out via the `issue tracker`_ if you have any
-   questions.
-
-Registering an MDAKit requires you to create a single file with metadata
-(called ``metadata.yaml``). You add this file to the `MDAnalysis/mdakits
-repository`_ on GitHub.
-
-Process
-=======
-
-Add a MDAKit by following these steps:
-
-#. Create a fork of the MDAKit repository https://github.com/MDAnalysis/mdakits.
-#. Make a new branch (choose any name, but "add-my-awesome-mdakit" is a good
-   one).
-#. Add a new folder under ``mdakits`` with the name of your MDAKit. Please note that this *must* match the name provided under the `project_name` entry of the ``metadata.yaml`` file.
-#. Add a metadata YAML file with your MDAKit's details; copy the template from
-   `mdakits/template/metadata.yaml`_ and modify it. See the comments in the
-   file and the :ref:`notes below<template>` for more explanations.
-#. Create a Pull Request (PR) from your branch against the *main*
-   branch of the `MDAnalysis/mdakits repository`_. Add a title with
-   the name of the kit (e.g. "register MyAwesomeTool") and add a short
-   description of your MDAKit.
-
-   A number of tests should automatically start to run.
-#. Wait for the tests to pass (i.e., all results should be green and
-   pass).
-
-   * If there are problems at this stage (tests don't pass and you don't
-     know where to start fixing the problem), add a comment to your PR
-     with the text
-
-        *@MDAnalysis/mdakits-reviewers please help with tests.*
-
-     in order to notify the MDAnalysis team that you need assistance
-     with fixing your submission.
-   * If the tests passed, add a comment to your PR with the text
-
-        *@MDAnalysis/mdakits-reviewers, ready for review.*
-
-#. Someone from the MDAnalysis team will *review* your Pull Request for
-   fulfilling the :ref:`requirements for an MDAKit<requirements>` and for any
-   technical issues.
-
-   They may ask for modifications so please *check your PR regularly*
-   or `enable GitHub notifications`_. Part of the registration process
-   is to engage in a conversation with the MDAnalysis team. The PR
-   cannot be merged until all relevant questions have been addressed.
-#. When your PR passes review, it will be merged and your MDAKit is registered.
-#. Remember: **You remain responsible for maintaining your code**. The
-   registry will continuously test your code but the
-   MDAnalysis team cannot fix it for you.
-
-   .. Note:: 
-
-      The registry will alert you via GitHub issues when your tests
-      start failing with newer versions of your code, MDAnalysis, or other
-      dependencies. In this case your MDAKit will be displayed as broken in the registry. **It is your responsibility to fix any relevant code in your package and (if necessary) make a new
-      release of your code**.  
-
-.. _specification:
-   
-Specification of the ``metadata.yaml`` file
-===========================================
-
-The ``metadata.yaml`` file is in `YAML format`_.
-
-The file contains required and optional entries.
-
-**Required entries**
-   Any variable in the *Required entries* section **must** be
-   provided. If missing or empty, the MDAKit cannot be registered.
-
-**Optional entries**
-   Any variable in the *Optional entries* section **may** be left
-   empty or be left out. However, it is recommended to provide as much
-   information as possible. Some aspects of the registry checks may not work if these details are missing.
-
-
-.. Note::    
-
-   For now, the :ref:`template file<template>` serves as the primary
-   specification for the MDAKits registry ``metadata.yaml`` file.  The
-   MDAKits registry specification will likely be updated in the future
-   with new optional and required entries. The MDAKits team will assist developers with migrations should they become necessary.
-
-
-      
-.. _template:
-
-Template ``metadata.yaml`` file
-===============================
-
-The following is the template metadata file
-`mdakits/template/metadata.yaml`_. Please see the *comments in the template*
-for an explanation of all possible items. Replace values with content
-appropriate for your MDAKit.
-
-.. Note::
-
-   The template uses the strings ``GH_HOST_ACCOUNT``,  ``MYPROJECT``, and
-   ``MYPACKAGE`` to indicate that you should be filling in *your* details.
-
-   
-``GH_ACCOUNT``
-   The GitHub account where the source code repository is held; typically your
-   username or the organization that you're part of.
-
-``MYPROJECT``
-   The name of your project. This is the name of your repository. In the template we
-   also use it as the PyPi/conda package name.
-   
-``MYPACKAGE``
-   The name of the Python package. It describes how you import it in Python
-   code, i.e. it is used in ``import MYPACKAGE``.
-
-The file is in `YAML format`_ so please look at the latest
-specifications to learn more about how to write correct YAML
-files. Typically you should be able to get started by modifying the
-template. Note that YAML is a file format where indentation matters so
-make sure that your editor uses spaces and not TAB for indentation as
-this can lead to incorrect YAML. Lines starting with hash marks ``#``
-are comments. You can add your own comments and modify the existing
-ones as needed.
-
-The comments in the template file indicate two sections. The first
-one contains all **required entries**, the second one all **optional
-entries**.
-
-.. literalinclude:: ../../mdakits/template/metadata.yaml
-   :language: yaml
-   :lines: 1-2,13-
-
-.. _`issue tracker`:
-   https://github.com/MDAnalysis/MDAKits/issues
-
-.. _`MDAnalysis/mdakits repository`:
-   https://github.com/MDAnalysis/mdakits
-   
-.. _`MDAKit registry`: https://mdakits.mdanalysis.org/mdakits.html
-
-.. _`enable GitHub notifications`:
-   https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications
-
-.. _`mdakits/template/metadata.yaml`:
-   https://github.com/MDAnalysis/MDAKits/blob/main/mdakits/template/metadata.yaml
-
-.. _YAML format: https://yaml.org/   
diff --git a/docs/source/addingakit.rst b/docs/source/addingakit.rst
new file mode 100644
index 00000000..15e1fef6
--- /dev/null
+++ b/docs/source/addingakit.rst
@@ -0,0 +1,34 @@
+.. _add-mdakit:
+
+********************************
+Adding an MDAKit to the Registry
+********************************
+
+Do you have an MDAKit? Consider adding it to the 
+:ref:`MDAKits Registry! <mdakits>`.
+
+.. note::   
+   The `MDAKit registry`_ is still in its initial stages. We expect that the way 
+   in which MDAKits are added, and the type of information required, may change
+   over time. Please reach out via the `issue tracker`_ if you have any
+   questions.
+
+Registering an MDAKit requires you to create a single file with meta information
+(called ``metadata.yaml``) describing the Kit, and add this to the 
+`MDAnalysis/mdakits repository`_ on GitHub. The links below provide information
+about this process and more detail about the ``metadata.yaml`` file.
+
+.. toctree::
+   :maxdepth: 2
+
+   registering-a-kit/step-by-step
+   registering-a-kit/metadata-yaml
+
+
+.. _`MDAKit registry`: https://mdakits.mdanalysis.org/mdakits.html
+
+.. _`issue tracker`:
+   https://github.com/MDAnalysis/MDAKits/issues
+
+.. _`MDAnalysis/mdakits repository`:
+   https://github.com/MDAnalysis/mdakits
diff --git a/docs/source/conf.py b/docs/source/conf.py
index 961be42b..74fdaa61 100644
--- a/docs/source/conf.py
+++ b/docs/source/conf.py
@@ -56,6 +56,7 @@
     'sphinx.ext.napoleon',
     'sphinx.ext.intersphinx',
     'sphinx.ext.extlinks',
+    'sphinxcontrib.youtube',
 ]
 
 autosummary_generate = True
diff --git a/docs/source/index.rst b/docs/source/index.rst
index 93a7065f..6eaaa1f1 100644
--- a/docs/source/index.rst
+++ b/docs/source/index.rst
@@ -11,8 +11,11 @@ Welcome to the MDAKit registry!
 Showcased here are a list of community generated packages which extend the
 functionality of the `MDAnalysis library`_.
 
-Follow the links below to begin exploring the available MDAKits, or view
-additional resources about MDAKits and how to write and/or add your own.
+For more information about MDAKits and the motivation behind them, please see 
+the :ref:`about-mdakits` page. 
+
+To begin exploring the :ref:`available MDAKits <mdakits>`, or view additional 
+resources on MDAKits and how to write and/or add your own, follow the links below!
 
 
 .. toctree::
@@ -24,12 +27,25 @@ additional resources about MDAKits and how to write and/or add your own.
 
 .. toctree::
    :maxdepth: 1
-   :caption: Resources
+   :caption: About
 
    about
+
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Resources for MDAKit Authors
+
    makingakit
-   add
+   addingakit
+   maintainingakit
    troubleshooting
+
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Other Resources
+
    reviewersguide
    
 
diff --git a/docs/source/maintainingakit.rst b/docs/source/maintainingakit.rst
new file mode 100644
index 00000000..c1116a8a
--- /dev/null
+++ b/docs/source/maintainingakit.rst
@@ -0,0 +1,27 @@
+.. _maintaining:
+
+*********************
+Maintaining an MDAKit
+*********************
+
+.. note::   
+   This section is still under construction. If you have topics you would
+   like to see covered here, please get in touch via 
+   `MDAnalysis Github Discussion`_.
+
+There are a variety of reasons a kit may behave unexpectedly after being 
+submitted to the registry. Apart from actively developing the kit, changes in 
+kit dependencies, or even Python itself, can introduce/deprecate new/old functionality.
+For this reason, the kits' continuous integration is rerun weekly to 
+confirm the kits expected behavior.
+
+In the event that a kit no longer passes its tests, an issue in 
+MDAnalysis/MDAKits is automatically raised while notifying the maintainers 
+indicated in the `metadata.yaml` file.
+While the registry developers will be happy to help where possible, ultimately,
+the maintainers of the MDAKit are responsible for resolving such issues and 
+ensuring that the tests pass.
+The issue will automatically close after the next CI run if the tests pass again.
+
+.. _`MDAnalysis GitHub Discussions`:
+   https://github.com/MDAnalysis/mdanalysis/discussions
diff --git a/docs/source/making-a-kit/documentation.rst b/docs/source/making-a-kit/documentation.rst
new file mode 100644
index 00000000..388eaa8e
--- /dev/null
+++ b/docs/source/making-a-kit/documentation.rst
@@ -0,0 +1,24 @@
+.. _documentation:
+
+*************
+Documentation
+*************
+
+Basic documentation is **required** for MDAKit registration. The detail and 
+depth of the documentation is ultimately up to you, but we require **at a 
+minimum** that you provide README-style documentation explaining what the code
+is supposed to do, how to install it, and the basics of its use.
+
+Although this is the minimum, we highly recommend that you consider generating
+your documentation with dedicated tools such as 
+`Sphinx <https://www.sphinx-doc.org/en/master/>`_, which allows you to generate
+static documentation using 
+`reStructuredText <https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html>`_
+-formatted plain text directly from your code. This makes it easier for your
+documentation to change alongside code changes.
+
+Using a **documentation hosting service** such as 
+`Read the Docs <https://readthedocs.org>`_ or 
+`GitHub Pages <https://pages.github.com/>`_ allows easy public access to your
+automatically generated documentation.
+
diff --git a/docs/source/making-a-kit/from-cookiecutter.rst b/docs/source/making-a-kit/from-cookiecutter.rst
new file mode 100644
index 00000000..8d08ad67
--- /dev/null
+++ b/docs/source/making-a-kit/from-cookiecutter.rst
@@ -0,0 +1,51 @@
+.. _guided-example:
+
+*********************************************
+Guided Example: Building an RMSF analysis Kit
+*********************************************
+
+In this section, we provide a guided example for creating an MDAKit
+using the `MDAKit cookiecutter <https://cookiecutter-mdakit.readthedocs.io>`_.
+A `video walk-through <https://www.youtube.com/watch?v=viCPUHkgSxg>`_ 
+of this tutorial is available on YouTube:
+
+.. youtube:: viCPUHkgSxg
+   :align: center
+
+
+We will create a kit for RMSF analysis, replicating the functionality 
+of the `RMSF analysis class <https://docs.mdanalysis.org/stable/documentation_pages/analysis/rms.html#MDAnalysis.analysis.rms.RMSF>`_ 
+in the core library.
+
+First, let's refresh ourselves on the :ref:`requirements <requirements>` 
+for a 'registerable' kit. In brief:
+
+**MDAKit requirements**
+
+#. Uses MDAnalysis
+#. Open source + OSI license
+#. Versioned + on a version-controlled repository
+#. Designated authors and maintainers
+#. (At least) minimal documentation
+#. (At least) minimal regression tests
+#. Installable as a standard package
+#. (Recommended) community information available
+#. (Recommended) available on a package distribution platform
+
+
+Below are the steps we'll go through to create our MDAKit. We'll check
+back in after each part to see how we're progressing through these
+requirements!
+
+.. toctree::
+   :maxdepth: 1
+   :caption: Steps for creating an MDAKit from the cookiecutter
+
+   guided-example/use-cookiecutter
+   guided-example/add-code
+   guided-example/add-tests
+   guided-example/to-github
+   guided-example/add-docs
+   guided-example/make-release
+   guided-example/registering
+
diff --git a/docs/source/making-a-kit/guided-example/add-code.rst b/docs/source/making-a-kit/guided-example/add-code.rst
new file mode 100644
index 00000000..8456e54e
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/add-code.rst
@@ -0,0 +1,125 @@
+*******************
+Part 2: Adding code
+*******************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=48s>`_
+*for a video demonstration of this section.*
+
+The cookiecutter created a ``<package_name>/`` directory where the MDAKit's 
+code can live - now it's time to start adding that code!
+
+#. In this example, we are recreating the existing MDAnalysis RMSF analysis, so
+   we will simply copy and paste this analysis class into a new file,
+   ``rmsfkit/rmsfkit.py``. The in-code documentation (which has been trimmed 
+   here for brevity) is written in 
+   `reStructuredText syntax <https://docutils.sourceforge.io/rst.html>`_ for 
+   building with Sphinx later. 
+
+   The contents of the file now resemble the following code block:
+
+   .. code-block:: python
+
+	"""
+	rmsfkit.py
+	A package to perform RMSF analysis on molecular dynamics data.
+	
+	All code and documentation, both of which are trimmed for the sake of brevity,
+	are taken from the MDAnalysis Python package. Used under GPLv2+.
+	"""
+	
+	from MDAnalysis.analysis.base import AnalysisBase
+	import numpy as np
+	
+	class RMSF(AnalysisBase):
+	    r"""Calculate RMSF of given atoms across a trajectory.
+	
+	    Note
+	    ----
+	    No RMSD-superposition is performed; it is assumed that the user is
+	    providing a trajectory where the protein of interest has been structurally
+	    aligned to a reference structure. The protein also has to be whole because
+	    periodic boundaries are not taken into account.
+	
+	    Run the analysis with :meth:`RMSF.run`, which stores the results in the
+	    array :attr:`RMSF.results.rmsf`.
+	
+	    """
+	    def __init__(self, atomgroup, **kwargs):
+	        r"""Parameters
+	        ----------
+	        atomgroup : AtomGroup
+	            Atoms for which RMSF is calculated
+	        verbose : bool (optional)
+	             Show detailed progress of the calculation if set to ``True``; the
+	             default is ``False``.
+	
+	        Raises
+	        ------
+	        ValueError
+	             raised if negative values are calculated, which indicates that a
+	             numerical overflow or underflow occurred
+	
+	        Notes
+	        -----
+	        The root mean square fluctuation of an atom :math:`i` is computed as the
+	        time average
+	
+	        .. math::
+	
+	          \rho_i = \sqrt{\left\langle (\mathbf{x}_i - \langle\mathbf{x}_i\rangle)^2 \right\rangle}
+	
+	        No mass weighting is performed. 
+	        
+	        This method implements an algorithm for computing sums of squares while
+	        avoiding overflows and underflows :cite:p:`Welford1962`.
+	
+	        References
+	        ----------
+	        .. bibliography::
+	            :filter: False
+	
+	            Welford1962
+	
+	        """
+	        super(RMSF, self).__init__(atomgroup.universe.trajectory, **kwargs)
+	        self.atomgroup = atomgroup
+	
+	    def _prepare(self):
+	        self.sumsquares = np.zeros((self.atomgroup.n_atoms, 3))
+	        self.mean = self.sumsquares.copy()
+	
+	    def _single_frame(self):
+	        k = self._frame_index
+	        self.sumsquares += (k / (k+1.0)) * (self.atomgroup.positions - self.mean) ** 2
+	        self.mean = (k * self.mean + self.atomgroup.positions) / (k + 1)
+	
+	    def _conclude(self):
+	        k = self._frame_index
+	        self.results.rmsf = np.sqrt(self.sumsquares.sum(axis=1) / (k + 1))
+	
+	        if not (self.results.rmsf >= 0).all():
+	            raise ValueError("Some RMSF values negative; overflow " +
+	                             "or underflow occurred")
+
+#. We have now added the ``RMSF`` analysis class to our package. Finally, to 
+   make this class easier to access, we import it in ``__init__.py`` by adding:
+
+   .. code-block:: python
+
+	from .rmsfkit import RMSF
+
+
+Progress: MDAKit requirements
+-----------------------------
+
+#. **✓ Uses MDAnalysis** - the added code uses the MDAnalysis ``AnalysisBase``
+   class, and takes MDAnalysis ``AtomGroup`` objects as inputs.
+#. **✓ Open source + OSI license**
+#. *Versioned + on a version-controlled repository*
+#. **✓ Designated authors and maintainers**
+#. *(At least) minimal documentation*
+#. *(At least) minimal regression tests*
+#. **✓ Installable as a standard package**
+#. **✓ (Recommended) community information available**
+#. *(Recommended) on a package distribution platform*
+
diff --git a/docs/source/making-a-kit/guided-example/add-docs.rst b/docs/source/making-a-kit/guided-example/add-docs.rst
new file mode 100644
index 00000000..aadb5d88
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/add-docs.rst
@@ -0,0 +1,248 @@
+*******************************
+Part 5: Providing documentation
+*******************************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=153s>`_
+*for a video demonstration of this section.*
+
+When registering an MDAKit, you'll be asked to identify which of the following
+(or combination thereof) best describes your documentation (*note that these are
+very flexible descriptions, and may cover a range of documentation styles and 
+levels of detail*):
+
+- **README**: a ``README.md``-type file containing basic information 
+  (description, installation, usage).
+- **API**: 'technical' documentation, describing the functions/methods/etc and
+  their input/outputs.
+- **User Guide**: more 'user friendly' documentation, similar to but likely 
+  expanding on README-style documentation; may include more detailed usage, 
+  descriptions, examples, etc.
+
+To keep registration easily attainable, MDAKits require only **minimal 
+documentation** - e.g. only a ``README.md``. However, more extensive 
+documentation is a good idea. We demonstrate here the process for adding further
+documentation for ``rmsfkit``.
+
+`Read the Docs <read the docs_>`_ can be used to build and host documentation 
+online. The cookiecutter includes a *Read the Docs* configuration as well a 
+pre-made documentation environment file that is used by *Read the Docs* and for 
+building locally. Frameworks for autogenerated API and basic User Guide 
+documentation are also provided.
+
+
+Building documentation locally
+------------------------------
+
+You can build documentation locally to check on the appearance as you work on
+it.
+
+#. First, add the required packages (listed in the autogenerated 
+   ``requirements.yaml`` file) to the environment: 
+
+   .. code-block:: bash
+
+	mamba env update --name rmsfkit -f requirements.yaml
+
+#. Then the documentation HTML files can be built by running:
+   
+   .. code-block:: bash
+
+	make html
+
+   This uses instructions in the included ``Makefile`` to convert 
+   reStructuredText files in the ``source/`` directory into HTML files in 
+   ``_build``. These files can now be opened and viewed. 
+  
+To view changes to the documentation after changing any of the source files, 
+rerun ``make html`` and refresh the browser.
+
+
+Adding to the documentation
+---------------------------
+
+**The cookiecutter-generated template**
+
+The cookiecutter starts our documentation with three pages:
+
+- ``index``: a "home" page with a table of contents, but otherwise blank.
+- ``getting_started``: a blank page intended to contain information for
+  potential users.
+- ``API``, containing API documentation autogenerated from the docstrings.
+
+These files are written in 
+`reStructuredText syntax <https://docutils.sourceforge.io/rst.html>`_, and can 
+now be added to expand the documentation.
+
+#. **Expanding the API documentation**: for our ``rmsfkit`` example, the 
+   autogenerated API documentation does not currently contain all of the 
+   information found in the code docstrings. This is because the 'autosummary' 
+   in ``source/api.rst`` by default specifies ``rmsfkit``, rather than 
+   specifically the analysis class, ``rmsfkit.RMSF``. We update it, so 
+   ``api.rst`` now reads:
+
+   .. code-block:: rst
+
+	API Documentation
+	=================
+	
+	.. autosummary::
+	   :toctree: autosummary
+	
+	   rmsfkit.RMSF
+
+   After rerunning ``make html`` and refreshing, there will be a table entry
+   for the RMSF class. Clicking this will open the documentation that was 
+   present in the docstrings.
+
+
+#. **Updating the home page**: ``index.rst`` will be the landing page for our 
+   User Guide. To make it more welcoming, let's add a short desciption of our 
+   code:
+
+   .. code-block:: rst
+
+	Welcome to rmsfkit's documentation!
+	=========================================================
+	
+	``rmsfkit`` is an example MDAKit that implements the functionality of the `analysis.rms.RMSF` class within the MDAnalysis package.
+	This MDAKit does not serve as a replacement for this functionality and using this MDAKit for real work is discouraged.
+	
+	.. toctree::
+	   :maxdepth: 2
+	   :caption: Contents:
+	
+	   getting_started
+	   api
+	
+	
+	Indices and tables
+	==================
+	
+	* :ref:`genindex`
+	* :ref:`modindex`
+	* :ref:`search`
+
+
+#. **Adding installation information**: The ``getting_started`` page is intended
+   to provide information for users to get started with our code. Let's add some
+   installation instructions for ``rmsfkit``:
+
+   .. code-block:: rst
+
+	Getting Started
+	===============
+	
+	The ``rmsfkit`` package is installable from source.
+	
+	.. code-block:: bash
+	
+	    git clone git@github.com:ianmkenney/rmsfkit.git
+	    cd rmsfkit/
+	    pip install .
+
+
+   We could add more information here (or in additional pages) demonstrating  
+   usage; but as this is covered by the API documentation, we will stop here 
+   for now.
+   
+
+**Citations in documentation**
+
+You can include citations in your docs using the bibtex format. We demonstrate
+this below to fix an unformatted citation (``:cite:p:`Welford1962```) in the 
+``rmsfkit.RMSF`` class documentation. 
+
+
+#. We first create a bibtex file, ``references.bib`` in the ``doc/source/`` 
+   directory:
+
+   .. code-block::
+
+	@article{Welford1962,
+	    author = {B. P. Welford},
+	    title = {Note on a Method for Calculating Corrected Sums of Squares and Products},
+	    journal = {Technometrics},
+	    volume = {4},
+	    number = {3},
+	    pages = {419-420},
+	    year  = {1962},
+	    publisher = {Taylor & Francis},
+	    doi = {10.1080/00401706.1962.10490022}
+	}
+
+#. In the confirguration file ``conf.py``, we need to add a new extension 
+   (``sphinxcontrib.bibtex``) as well as the name of the bibtex file:
+
+   .. code-block:: Python
+
+	extensions = [
+	    'sphinx.ext.autosummary',
+	    'sphinx.ext.autodoc',
+	    'sphinx.ext.mathjax',
+	    'sphinx.ext.viewcode',
+	    'sphinx.ext.napoleon',
+	    'sphinx.ext.intersphinx',
+	    'sphinx.ext.extlinks',
+	    'sphinxcontrib.bibtex',  # add this line
+	]
+	
+	bibtex_bibfiles = ['references.bib'] # and this one!
+
+#. We also have to add this extension the install requirements in 
+   ``docs/requirements.yaml`` - add ``- sphinxcontrib-bibtex`` as an additional
+   dependency here.
+
+#. Finally, update the environment with
+
+   .. code-block:: bash
+
+	mamba env update --name rmsfkit -f requirements.yaml
+
+   before once again running ``make html``.
+
+Refreshing the documentation will now show a properly formatted citation using 
+the information in the bibtex file.
+
+
+Deploying the documentation
+---------------------------
+
+After pushing documentation changes to GitHub, you can then display them on 
+their own shiny new website!
+
+#. Make sure all changes are pushed to GitHub. Log into 
+   `Read the Docs <read the docs_>`_ (using your GitHub account) and navigate to
+   the dashboard -  click the "Import a Project" button.
+
+   .. image:: ../../img/rmsftutorial/import.png
+	:alt: Import a project into RTD
+
+#. Find the Kit repository and click "+". Confirm that the name, URL, and 
+   default branch (likely `main`) are correct.
+
+   .. image:: ../../img/rmsftutorial/adding.png
+	:alt: Adding your repository to RTD
+
+#. Clicking next will begin the deployment. This immediately starts the build
+   process, which can be confirmed by clicking the "Builds" tab. Once the build 
+   is completed, you can view the deployed documentation (which is now public!). 
+   
+This completes the documentation requirement for an MDAKit! Notice that the "docs"
+badge in the GitHub rendered ``README.md`` is now green.
+
+
+Progress: MDAKit requirements
+-----------------------------
+
+#. **✓ Uses MDAnalysis**
+#. **✓ Open source + OSI license**
+#. **✓ Versioned + on a version-controlled repository**
+#. **✓ Designated authors and maintainers**
+#. **✓ (At least) minimal documentation** - documentation is now included
+   with the code and hosted online.
+#. **✓ (At least) minimal regression tests**
+#. **✓ Installable as a standard package**
+#. **✓ (Recommended) community information available**
+#. *(Recommended) on a package distribution platform*
+
+.. _read the docs: https://readthedocs.org
diff --git a/docs/source/making-a-kit/guided-example/add-tests.rst b/docs/source/making-a-kit/guided-example/add-tests.rst
new file mode 100644
index 00000000..1a98d69e
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/add-tests.rst
@@ -0,0 +1,193 @@
+********************
+Part 3: Adding tests
+********************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=72s>`_
+*for a video demonstration of this section.*
+
+The cookiecutter set up the framework for tests in ``<package_name>/tests``. 
+Here we demonstrate the process for adding tests, running them locally, and
+preparing them for automatic running (continuous integration).
+
+Adding the tests
+----------------
+
+#. For our ``rmsfkit`` example, we once again take directly from the 
+   existing code in the MDAnalysis package. We take the 
+   `RMSF testing class <https://github.com/MDAnalysis/mdanalysis/blob/develop/testsuite/MDAnalysisTests/analysis/test_rms.py>`_ 
+   and update the contents of ``rmsfkit/tests/test_rmsfkit.py`` as follows:
+
+   .. code-block:: python
+
+	"""
+	Unit and regression test for the rmsfkit package.
+	
+	The TestRMSF class was taken from the MDAnalysis rms tests file and
+	the relevant modules were switched.
+	"""
+	
+	# Import package, test suite, and other packages as needed
+	from MDAnalysisTests.datafiles import GRO, XTC, rmsfArray
+	import MDAnalysis as mda
+	
+	from numpy.testing import assert_equal, assert_almost_equal
+	import numpy as np
+	import os
+	import pytest
+	
+	import rmsfkit
+	import sys
+	
+	def test_rmsfkit_imported():
+	    """Sample test, will always pass so long as import statement worked"""
+	    assert "rmsfkit" in sys.modules
+	
+	
+	class TestRMSF(object):
+	    @pytest.fixture()
+	    def universe(self):
+	        return mda.Universe(GRO, XTC)
+	
+	    def test_rmsf(self, universe):
+	        rmsfs = rmsfkit.RMSF(universe.select_atoms('name CA'))
+	        rmsfs.run()
+	        test_rmsfs = np.load(rmsfArray)
+	
+	        assert_almost_equal(rmsfs.results.rmsf, test_rmsfs, 5,
+	                            err_msg="error: rmsf profile should match test "
+	                            "values")
+	
+	    def test_rmsf_single_frame(self, universe):
+	        rmsfs = rmsfkit.RMSF(universe.select_atoms('name CA')).run(start=5, stop=6)
+	
+	        assert_almost_equal(rmsfs.results.rmsf, 0, 5,
+	                            err_msg="error: rmsfs should all be zero")
+	
+	    def test_rmsf_identical_frames(self, universe, tmpdir):
+	
+	        outfile = os.path.join(str(tmpdir), 'rmsf.xtc')
+	
+	        # write a dummy trajectory of all the same frame
+	        with mda.Writer(outfile, universe.atoms.n_atoms) as W:
+	            for _ in range(universe.trajectory.n_frames):
+	                W.write(universe)
+	
+	        universe = mda.Universe(GRO, outfile)
+	        rmsfs = rmsfkit.RMSF(universe.select_atoms('name CA'))
+	        rmsfs.run()
+	        assert_almost_equal(rmsfs.results.rmsf, 0, 5,
+	                            err_msg="error: rmsfs should all be 0")
+
+
+#. *Adding a test dependency:* Since these tests use files from the 
+   ``MDAnalysisTests`` package, we need to add this as a dependency. We do this
+   in two configuration files:
+
+   - In ``devtools/conda-envs/test_env.yaml``, in the ``dependencies:`` section:
+
+     .. code-block:: yaml
+     
+        dependencies:
+        # Base depends
+        - python
+        - pip
+
+        # MDAnalysis
+        - MDAnalysis
+
+        # Testing
+        - pytest
+        - pytest-cov
+        - pytest-xdist
+        - codecov
+        - MDAnalysisTests # <-- add this! 
+
+   - In ``pyproject.toml``, under ``[project.optional-dependencies]``:
+
+     .. code-block:: toml
+
+	[project.optional-dependencies]
+	test = [
+	    "pytest>=6.0",
+	    "pytest-xdist>=2.5",
+	    "pytest-cov>=3.0",
+	    "MDAnalysisTests>=2.0.0", # <-- add this!
+	]
+
+
+Running the tests
+-----------------
+
+#. Before running the tests, you need an environment with the necessary 
+   packages installed. Following the instructions from the generated 
+   ``README.md``, you can create a testing environment using ``mamba`` 
+   (preferred) or ``conda``; e.g. for ``rmsfkit``:
+
+   .. code-block:: bash
+
+        $ mamba create -n rmsfkit
+        $ mamba env update --name rmsfkit --file devtools/conda-envs/test_env.yaml
+        $ mamba activate rmsfkit
+
+
+#. Then install the MDAKit package in *editable mode*:
+
+   .. code-block:: bash
+
+        $ pip install -e .
+
+
+#. Tests can now be run locally using:
+
+   .. code-block:: bash
+
+	$ pytest rmsfkit/tests
+
+   This should pass without errors, though with some potential warnings. 
+
+Steps 1-2 only need to be performed once. Thereafter, tests can be run at any 
+point with ``pytest rmsfkit/tests`` (though you may need to reactivate the 
+environment, ``mamba activate rmsfkit``).
+
+
+Preparing for CI
+----------------
+
+Local tests passing is only half of testing. Ideally, tests should also pass 
+through **continuous integration services**. The cookiecutter generates the 
+necessary GitHub workflow files ``.github/workflows/gh-ci.yaml`` to do this on
+GitHub.
+
+#. Since our tests for ``rmsfkit`` use the ``MDAnalysisTests`` package, we again
+   need to make a change to ``.github/workflows/gh-ci.yaml``. In the *Install 
+   MDAnalysis version* job we change the ``install-tests`` flag to ``true``:
+
+  .. code-block:: yaml
+
+	- name: Install MDAnalysis version
+	  uses: MDAnalysis/install-mdanalysis@main
+	  with:
+		version: ${{ matrix.mdanalysis-version }}
+		install-tests: true  # <-- this needs to be true! 
+		installer:  mamba 
+		shell: bash  -l {0} 
+
+In the next part, we will demonstrate uploading the MDAKit to a GitHub 
+repository in order to run the pre-built continuous integration provided by the
+cookiecutter. 
+
+
+Progress: MDAKit requirements
+-----------------------------
+
+#. **✓ Uses MDAnalysis**
+#. **✓ Open source + OSI license**
+#. *Versioned + on a version-controlled repository*
+#. **✓ Designated authors and maintainers**
+#. *(At least) minimal documentation*
+#. **✓(At least) minimal regression tests** - these are ready and (hopefully)
+   passing! CI should be finalised in the next step by pushing to GitHub.
+#. **✓ Installable as a standard package**
+#. **✓ (Recommended) community information available**
+#. *(Recommended) on a package distribution platform*
+
diff --git a/docs/source/making-a-kit/guided-example/make-release.rst b/docs/source/making-a-kit/guided-example/make-release.rst
new file mode 100644
index 00000000..f3387340
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/make-release.rst
@@ -0,0 +1,78 @@
+*********************************
+Part 6: Making an initial release
+*********************************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=247s>`_
+*for a video demonstration of this section.*
+
+While using git does satisfy the requirement that our MDAKit code be versioned,
+it is a good idea to make numbered releases with (human-understandable) version
+numbers to easily track your code as changes and improvements are made.
+
+The MDAKit cookiecutter uses 
+`versioningit <https://versioningit.readthedocs.io/en/stable/index.html>`_
+for version management. In brief, software versions are set through 
+`git tags <https://git-scm.com/book/en/v2/Git-Basics-Tagging>`_.
+
+.. image:: ../../img/rmsftutorial/creating_a_release.gif
+	:alt: Process for creating a release by making a tag
+
+#. Since the Kit is initiated without tags, the current version is set to 
+   ``0.0.0``. 
+
+   .. code-block:: bash
+
+	>>> import rmsfkit  
+	>>> rmsfkit.__version__  
+	'0.0.0+3.g0b64a6c'
+
+   *Note: As commits are added, the version is updated with the commit hash. The
+   exact output here differs between the YouTube tutorial and video embedded 
+   above, and from what you will see.*
+
+   Bump this to a ``0.1.0`` in preparation for an initial release on GitHub 
+   using a `git tag`:
+
+   .. code-block:: bash
+
+	$ git tag 0.1.0
+
+   This should now be reflected in the interpreter (though may require a package
+   reinstall):
+
+   .. code-block:: bash
+
+	>>> import rmsfkit  
+	>>> rmsfkit.__version__  
+	'0.1.0'
+
+#. Tags are not pushed to remote repositories by default. To push the ``0.1.0``
+   tag, use:
+
+   .. code-block:: bash
+
+	$ git push --tags
+
+#. Viewing the repository tags page on GitHub, you should now see a ``0.1.0`` 
+   tag. Expanding its menu gives us the option to create a release based on the 
+   tagged code. Enter a release name, such as `v0.1.0` and publish!
+
+Going forward, you could publish this release to a package distribution 
+platforms such as PyPi or Conda-Forge, though this is not covered in this 
+example.
+
+Having met all the requirements, it's now time to register our MDAKit!
+
+Progress: MDAKit requirements
+-----------------------------
+
+#. **✓ Uses MDAnalysis**
+#. **✓ Open source + OSI license**
+#. **✓ Versioned + on a version-controlled repository**
+#. **✓ Designated authors and maintainers**
+#. **✓ (At least) minimal documentation**
+#. **✓ (At least) minimal regression tests**
+#. **✓ Installable as a standard package**
+#. **✓ (Recommended) community information available**
+#. *(Recommended) on a package distribution platform*
+
diff --git a/docs/source/making-a-kit/guided-example/registering.rst b/docs/source/making-a-kit/guided-example/registering.rst
new file mode 100644
index 00000000..15ad68d9
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/registering.rst
@@ -0,0 +1,91 @@
+.. _example-registration:
+
+*****************************
+Part 7: Registering an MDAKit
+*****************************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=287s>`_
+*for a video demonstration of this section.*
+
+The MDAKit registration is the same regardless of how the Kit was created.
+When registering your own Kit, be sure to also read the general information in 
+the :ref:`add-mdakit` section. 
+
+In order to submit your MDAKit to the registry, you will need to create a pull
+request on GitHub against the *MDAnalysis/MDAKits* repository.
+
+#. First, create a fork of the *MDAnalysis/MDAKits* repository on GitHub. 
+
+
+#. Clone the fork to your local machine, navigate into ``MDAKits/mdakits/``, 
+   and make an empty directory with your MDAKit name - this must match the 
+   `project_name` you specify below.
+
+   .. code-block:: bash
+
+	git clone git@github.com:yourusername/MDAKits
+	cd MDAKits/mdakits
+	mkdir rmsfkit/
+	cd rmsfkit
+
+#. Add a ``metadata.yaml`` for your MDAKit in this directory. A template can be
+   found in ``mdakits/template/metadata.yaml``. See 
+   :ref:`the metadata.yaml specifications <specification>` for more details on
+   this file and its fields. 
+
+   For our ``rmsfkit``, the contents of ``metadata.yaml`` are:
+
+   .. code-block:: yaml
+
+	project_name: rmsfkit
+	authors:
+	  - https://github.com/yourusername/rmsfkit/blob/main/AUTHORS.md
+	maintainers:
+	  - yourusername
+	description:
+	    An analysis module for calculating the root-mean-square fluctuation of atoms in molecular dynamics simulations.
+	keywords:
+	  - rms
+	  - rmsf
+	license: GPL-2.0-or-later
+	project_home: https://github.com/yourusername/rmsfkit
+	documentation_home: https://rmsfkit.readthedocs.io/en/latest/
+        documentation_type: API
+        src_install:
+          - git clone https://github.com/yourusername/rmsfkit.git
+          - cd rmsfkit/
+          - pip install .
+
+	## Optional entries
+	python_requires: ">=3.9"
+	mdanalysis_requires: ">=2.0.0"
+	run_tests:
+	  - pytest --pyargs rmsfkit.tests
+	development_status: Beta
+
+#. Commit and push this to your fork, e.g.:
+
+   .. code-block:: bash
+
+        git add metadata.yaml
+        git commit -m "Adding rmsfkit"
+        git put origin main
+
+#. On the forked repository page in your browser, click *"Contribute"* to make a
+   Pull Request (you may need to first refresh for the changes to show up). Add 
+   a title with the name of the Kit and add a quick description and click 
+   *"Create pull request"*.
+  
+   .. image:: ../../img/rmsftutorial/submitting.gif
+        :alt: Process for submitting a kit to the registy
+
+   Once the tests have passed, you can add a comment along the lines of 
+   *"@MDAnalysis/mdakits-reviewers, ready for review"*. The reviewers will get 
+   back to you with any change requests before merging it in as a Kit.
+
+At this point there are no additional steps for registering your kit! However,
+your responsibility for your new MDAKit does not end here. Once on the Registry,
+the weekly CI runs will notify you if anything starts failing; and you can 
+continue to expand and improve your code, it's documentation/tests, make 
+releases, and so on. Read the information on the :ref:`maintaining` page for 
+more.
diff --git a/docs/source/making-a-kit/guided-example/to-github.rst b/docs/source/making-a-kit/guided-example/to-github.rst
new file mode 100644
index 00000000..67fe6cda
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/to-github.rst
@@ -0,0 +1,51 @@
+*************************
+Part 4: Pushing to GitHub
+*************************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=114s>`_
+*for a video demonstration of this section.*
+
+Putting the MDAKit on GitHub will fulfill the requirement that the Kit be hosted
+on a version-controlled repository, and finalise the continuous integration set
+up in the previous step.
+
+During the cookiecutter generation process, the target GitHub repository 
+``<repo_name>`` was identified, and inserted into the workflows configuration as
+well as into the ``README.md`` file. 
+
+#. Add this repository as a remote to the local git repository, e.g.:
+
+   .. code-block:: bash
+
+	$ git remote add origin git@github.com:myusername/rmsfkit
+
+   (substituting ``myusername`` for your GitHub username). Make sure that this
+   repository exists on GitHub and is *empty*.
+   
+#. Then, push the local code to GitHub:
+
+   .. code-block:: bash
+
+	$ git push origin main
+
+The ``rmsfkit`` repository on GitHub will now be up-to-date the local repository
+you have been working on. Navigate to *Actions* on GitHub to see the status of 
+the tests. If all was done correctly in the previous sections, these will all 
+pass!
+
+
+Progress: MDAKit requirements
+-----------------------------
+
+#. **✓ Uses MDAnalysis**
+#. **✓ Open source + OSI license**
+#. **✓ Versioned + on a version-controlled repository** -- our code is
+   now on GitHub.
+#. **✓ Designated authors and maintainers**
+#. *(At least) minimal documentation*
+#. **✓ (At least) minimal regression tests** -- CI should be up and
+   running, and the tests added in the last step all passing.
+#. **✓ Installable as a standard package**
+#. **✓ (Recommended) community information available**
+#. *(Recommended) on a package distribution platform*
+
diff --git a/docs/source/making-a-kit/guided-example/use-cookiecutter.rst b/docs/source/making-a-kit/guided-example/use-cookiecutter.rst
new file mode 100644
index 00000000..edae446b
--- /dev/null
+++ b/docs/source/making-a-kit/guided-example/use-cookiecutter.rst
@@ -0,0 +1,112 @@
+************************************
+Part 1: Using the MDAKit cookicutter
+************************************
+
+*See our* `YouTube tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg&t=38s>`_
+*for a video demonstration of this section.*
+
+The **MDAKits cookiecutter** (a `Cookiecutter tool`_) can be used to rapidly 
+develop a FAIR-compliant MDAKit by generating placeholder code for 
+documentation, testing and installation. 
+
+More information on its usage is can be found in the 
+`MDAKit cookiecutter documentation`_, but in short using the cookiecutter 
+involved running a command line prompt and then responding to a series of 
+subsequent prompts. Below, we demonstrate this process for creating an 
+``rmsfkit`` project.
+
+#. **Initial requirements**: to use the Cookiecutter, you will need a GitHub 
+   account, and an environment with Python 3.10+ and the `Cookiecutter tool`_ 
+   installed.
+
+#. The following command and responses will create a template for an 
+   ``rmsfkit`` project. Note that some prompts have been left blank, accepting
+   the default response.
+
+   .. code-block:: bash
+
+	$ cookiecutter gh:MDAnalysis/cookiecutter-mdakit
+
+	project_name (ProjectName): rmsfkit
+	repo_name (rmsfkit): 
+	package_name (rmsfkit): 
+	description (A short description of the project.): A package to perform RMSF analysis on molecular dynamics data.
+	github_username (Your personal GitHub username): myusername
+	github_host_account (GitHub account for hosting rmsfkit (e.g. myusername or an organization account). Press Enter to use myusername): 
+	author_name (Your name (or your organization/company/team)): Firstname Lastname
+	author_email (Your email (or your organization/company/team)): myemail@email-provider.com
+	Select dependency_source:
+	1 - Prefer conda-forge over the default anaconda channel with pip fallback
+	2 - Prefer default anaconda channel with pip fallback
+	3 - Dependencies from pip only (no conda)
+	Choose from [1/2/3] (1): 
+	Select include_ReadTheDocs:
+	1 - y
+	2 - n
+	Choose from [1/2] (1): 
+	template_analysis_class (Class name to template (e.g. Rmsfkit ). Press Enter to skip including analysis templates):
+
+   Details on these options can be found on the MDAKit cookiecutter 
+   documentation `here <cookiecutter options>`_. For ``rmsfkit``, we
+   have opted to *'include ReadTheDocs'* (so that we can use it to host our 
+   documentation later), and *'not create a template Analysis class'* for our 
+   code (since we will be copying the existing MDAnalysis RMSF code).
+
+A new git repository named ``rmsfkit`` has been generated. Navigating into this
+directory, we find a number of files and subdirectories. The `cookiecutter 
+documentation <cookiecutter usage>`_ provides more information on these, but some 
+to take note of now: 
+
+- ``LICENSE`` -- a text file containing the license information (GLPv2+ by 
+  default).
+- ``AUTHORS.md`` -- a template text file for listing code authors as each new
+  contribution is made. Auto-populated with your name as the initial project
+  creator.
+- ``README.md`` -- a text file containing the project description and other 
+  useful information. This will be the landing page content rendered on GitHub.
+- ``pyproject.toml`` -- a configuration file with information for packaging (and
+  other tools).
+- ``rmsfkit/`` -- folder containing template files for a python package. This is
+  where the source code (and tests) will live.
+- ``CODE_OF_CONDUCT.md`` and ``CONTRIBUTING.md`` -- text files containing sample
+  community guidelines and autogenerated instructions for reporting issues,
+  contributing, etc (once the code is on GitHub). 
+- ``docs/`` -- folder containing documentation templates and configuration files
+  for building the documentation.
+
+We'll address some further files as they become relevant.
+
+
+Progress: MDAKit requirements
+-----------------------------
+
+#. *Uses MDAnalysis* 
+#. **✓ Open source + OSI license** -- the default GPLv2 license falls under 
+   OSI. If you wish to choose another license, you can replace the default 
+   ``LICENSE`` file with another; see :ref:`licensing` for more information.
+#. *Versioned + on a version-controlled repository* -- the cookiecutter has set
+   up versioning with git; in a later step, we'll add it to GitHub to complete
+   this requirement.
+#. **✓ Designated authors and maintainers** -- in the autogenerated 
+   ``AUTHORS.md`` file, assuming that the maintained and author are the same 
+   person. Future authors will also be added here.
+#. *(At least) minimal documentation* -- the autogenerated ``README.md`` does 
+   contain the Kit description, which is a start. We will be adding more formal
+   documentation in a later step. 
+#. *(At least) minimal regression tests*
+#. **✓ Installable as a standard package** -- the configuration file 
+   ``pyproject.toml`` and the file structure set up in ``rmsfkit/`` will allow
+   this. 
+#. **✓ (Recommended) community information available** -- provided with
+   ``CODE_OF_CONDUCT.md`` and ``CONTRIBUTING.md``. Adjust these files to suit 
+   your needs.
+#. *(Recommended) on a package distribution platform*
+
+
+.. _`Cookiecutter tool`: https://cookiecutter.readthedocs.io/en/stable/
+
+.. _`MDAKit cookiecutter documentation`: https://cookiecutter-mdakit.readthedocs.io/en/latest/
+
+.. _`cookiecutter options`: https://cookiecutter-mdakit.readthedocs.io/en/latest/options
+
+.. _`cookiecutter usage`: https://cookiecutter-mdakit.readthedocs.io/en/latest/usage
diff --git a/docs/source/making-a-kit/hosting.rst b/docs/source/making-a-kit/hosting.rst
new file mode 100644
index 00000000..eec74711
--- /dev/null
+++ b/docs/source/making-a-kit/hosting.rst
@@ -0,0 +1,26 @@
+.. _hosting:
+
+***********************************************
+Hosting code in a version controlled repository
+***********************************************
+
+The MDAKits registry makes heavy use of the GitHub actions infrastructure. Thus,
+registration of a kit **requires** that all code maintainers also have a GitHub 
+account for communication purposes.
+
+For this reason, if your code is not already hosted in an accessible version 
+controlled repository, hosting on `GitHub <https://github.com>`_ is 
+*recommended*, although other services such as 
+`Bitbucket <https://bitbucket.org/>`_, `GitLab <https://gitlab.com>`_, or self 
+hosting are possible.
+
+The registry **does not require** that your code be available through packaging
+repositories such as the Python Package Index (`PyPi <https://pypi.org/>`_) or
+`conda-forge <https://conda-forge.org/>`_, although having your code available
+through these services is highly encouraged. 
+
+However, your code **does** need to be installable from source. You'll specify 
+the commands for this in the ``src_install`` field of your ``metadata.yaml`` 
+file (see the :ref:`metadata.yaml documentation <specification>`). This will 
+then be made available to users on your MDAKit's page on the
+:ref:`Registry <mdakits>`.
diff --git a/docs/source/making-a-kit/license.rst b/docs/source/making-a-kit/license.rst
new file mode 100644
index 00000000..b237b8c5
--- /dev/null
+++ b/docs/source/making-a-kit/license.rst
@@ -0,0 +1,25 @@
+.. _licensing:
+
+*********
+Licensing
+*********
+
+One of the more pressing requirements for kit registration is clearly 
+identifying the license that is applied to your code. This is typically included
+in a ``LICENSE`` file at the top level of your repository.
+`Without a license <https://choosealicense.com/no-permission/>`_, the only 
+assumption a user can make about your code is that they are not in a position to
+use your code.
+
+Your license needs to be compatible with the GPLv2+ license currently used by 
+MDAnalysis, in addition to the licenses of any other packages your MDAKit depends 
+on. Take time to consider how you would like to 
+`license your project <https://choosealicense.com/>`_.
+
+Further information on open source licensing can be found from sources such as: 
+
+- `choose a license <https://choosealicense.com/>`_, 
+- `tl;dr Legal <https://tldrlegal.com/>`_,
+- the `Open Source Initiative <https://opensource.org/osd>`_, 
+- the `Software Sustainability Insitute <https://www.software.ac.uk/resources/guides/choosing-open-source-licence>`_.
+
diff --git a/docs/source/making-a-kit/testing.rst b/docs/source/making-a-kit/testing.rst
new file mode 100644
index 00000000..7364e020
--- /dev/null
+++ b/docs/source/making-a-kit/testing.rst
@@ -0,0 +1,25 @@
+.. _testing: 
+
+*******
+Testing
+*******
+
+The MDAKit Registry requires that **minimal regression tests are present**.
+These tests are not just useful for when you make changes to your code, but
+also when any package dependencies (e.g. MDAnalysis, NumPy, and Python) change.
+Additionally, tests inform the users of your packages that the code performs at
+least the way you say it should and give them confidence that it can be used.
+
+Basic tests can be written with a variety of packages, such as 
+`pytest <https://docs.pytest.org/en/7.4.x/>`_ (the default choice for MDAnalysis
+organization projects) or
+`unittest <https://docs.python.org/3/library/unittest.html#module-unittest>`_.
+
+Further improvements to your testing procedure may include automatically running
+the tests on pushing to your remote repositories, often referred to as 
+**continuous integration (CI)**. CI can be set up using repository pipeline 
+tools, such as `GitHub Actions <https://github.com/features/actions>`_.
+
+When submitting an MDAKit to the registry, you'll include the instructions for 
+running the tests in the required ``metadata.yaml`` file under ``run_tests`` - 
+see the :ref:`metadata.yaml documentation <specifying-tests>` for more.
diff --git a/docs/source/makingakit.rst b/docs/source/makingakit.rst
index 9bdced09..8cdc4caf 100644
--- a/docs/source/makingakit.rst
+++ b/docs/source/makingakit.rst
@@ -2,684 +2,43 @@
 Making an MDAKit
 ****************
 
-Here, we outline the process of creating an MDAKit that fulfills all of the requirements for acceptance into the MDAKit registry.
-For a video walk-through of this tutorial, watch `our recorded tutorial <https://www.youtube.com/watch?v=viCPUHkgSxg>`_ on YouTube.
+The MDAKit registry has a number of :ref:`requirements <requirements>`
+to ensure that registered packages are FAIR-compliant and hold up to
+an ideal scientific standard.
 
-Unlike the code in the core MDAnalysis library, the structure of an MDAKit is much less restrictive.
-In order to be accepted, there are several :ref:`requirements <requirements>` that must be addressed:
 
-#. Code in the package uses the MDAnalysis library
-#. The code is open source and published under an `OSI approved license <https://opensource.org/licenses/>`_
-#. Code is versioned and provided in an accessible version-controlled repository (GitHub, GitLab, Bitbucket, etc.)
-#. Code authors and maintainers are clearly designated
-#. Minimal documentation is provided (what your code does, how to install it,
-   and how to use it)
-#. At least minimal regression tests are present; continuous integration is encouraged
-#. The source code is installable as a standard package
+Building a Kit using the cookiecutter
+-------------------------------------
 
-It is also highly encouraged that the MDAKit also satisfies:
+Without prior experience, some of the MDAKit Registry requirements
+can be daunting. The `MDAKit cookiecutter <https://cookiecutter-mdakit.readthedocs.io/>`_
+can be used to aid rapid development of a FAIR-compliant MDAKit
+by generating placeholder code for documentation, testing and 
+installation. A guided example of creating an MDAKit, from cookiecutter
+to registration, is provided below.
 
-#. Information on bug reporting, user discussions, and community guidelines is made available
-#. The code is made available on a package distribution platform (e.g. PyPi or conda-forge).
+.. toctree::
+   :maxdepth: 2
 
-These requirements ensure that registered packages are FAIR-compliant and hold up to an ideal scientific standard.
-Without prior experience, some of the requirements listed above can be daunting.
-To aid in this process, we make use of the MDAKit cookiecutter in this example.
+   making-a-kit/from-cookiecutter
 
-Building from the cookiecutter
-##############################
 
-The MDAKits cookiecutter template (using the `Cookiecutter tool <https://cookiecutter.readthedocs.io/en/stable/>`_) can be used to rapidly develop a FAIR-compliant MDAKit by generating placeholder code for documentation, testing, and installation. 
-While its usage is outlined in detail in the `MDAKit cookiecutter <https://cookiecutter-mdakit.readthedocs.io/en/latest/>`_ documentation, here we provide a full walk-through for creating an RMSF analysis kit, recreating the functionality of the `RMSF analysis class <https://docs.mdanalysis.org/stable/documentation_pages/analysis/rms.html#MDAnalysis.analysis.rms.RMSF>`_ in the core library.
+Building without the cookiecutter (or from an existing project)
+---------------------------------------------------------------
 
-Starting from an environment with Python 3.10+ and the `Cookiecutter tool <https://cookiecutter.readthedocs.io/en/stable/>`_, the MDAKit template is generated using
+If you have an existing package you wish to register as an MDAKit,
+or if you wish to develop a Kit without use of the cookiecutter, that's
+also okay! For existing code, chances are very little restructuring is 
+required before registration - just make sure you meet the core 
+:ref:`requirements <requirements>` for registration. 
 
-.. code-block::
+You may still find the above links helpful, along with the additional
+information below.
 
-	$ cookiecutter gh:MDAnalysis/cookiecutter-mdakit
+.. toctree::
+   :maxdepth: 1
 
-	project_name [ProjectName]: rmsfkit
-	repo_name [rmsfkit]: 
-	package_name [rmsfkit]: 
-	description [A short description of the project.]: A package to perform RMSF analysis on molecular dynamics data.
-	github_username [Your personal GitHub username]: myusername
-	github_host_account [GitHub account for hosting rmsfkit (e.g. myusername or an organization account). Press Enter to use myusername]: 
-	author_name [Your name (or your organization/company/team)]: Firstname Lastname
-	author_email [Your email (or your organization/company/team)]: myemail@email-provider.com
-	Select dependency_source:
-	1 - Prefer conda-forge over the default anaconda channel with pip fallback
-	2 - Prefer default anaconda channel with pip fallback
-	3 - Dependencies from pip only (no conda)
-	Choose from 1, 2, 3 [1]: 
-	Select include_ReadTheDocs:
-	1 - y
-	2 - n
-	Choose from 1, 2 [1]: 
-	template_analysis_class [Class name to template (e.g. Rmsfkit ). Press Enter to skip including analysis templates]:
-
-This generates a new git repository named ``rmsfkit`` (note that the author of the initial commit will match that of the user's global git configurations).
-Navigating into this directory, we find the following notable files and directories:
-
-#. LICENSE -- defaults to GLPv2+
-#. pyproject.toml -- pip dependencies
-#. MANIFEST.in -- Packaging information
-#. README.md -- Project description and typically landing page content rendered on GitHub
-#. docs/ -- Sphinx documentation template, instructions and build environment documented within!
-#. rmsfkit/ -- Python package source code template
-
-See `the cookiecutter documentation <https://cookiecutter-mdakit.readthedocs.io/en/latest/usage.html>`_ for information on additional files. 
-Using the cookiecutter checks off a couple of the requirements for a valid MDAKit right from the start:
-
-* Open source code is published under an OSI approved license \[defaults to GPLv2\]
-* Code authors and maintainers are clearly designated (assuming that the maintainer and the author are the same person)
-* Code is installable as a standard package (optional feature)
-* Information on bug reporting, user discussions, and community guidelines is made available (optional feature)
-
-Adding our code to the newly created repository
-***********************************************
-
-Since we are recreating the RMSF analysis,  we are simply copy and pasting the
-analysis class into the ``rmsfkit/rmsfkit.py`` file, where the documentation has been
-trimmed for the sake of brevity. Documentation is written in `reStructuredText syntax <https://docutils.sourceforge.io/rst.html>`_
-syntax for building with Sphinx. The contents of the file should now resemble
-the following code block:
-
-.. code-block:: python
-
-	"""
-	rmsfkit.py
-	A package to perform RMSF analysis on molecular dynamics data.
-	
-	All code and documentation, both of which are trimmed for the sake of brevity,
-	are taken from the MDAnalysis Python package. Used under GPLv2+.
-	"""
-	
-	from MDAnalysis.analysis.base import AnalysisBase
-	import numpy as np
-	
-	class RMSF(AnalysisBase):
-	    r"""Calculate RMSF of given atoms across a trajectory.
-	
-	    Note
-	    ----
-	    No RMSD-superposition is performed; it is assumed that the user is
-	    providing a trajectory where the protein of interest has been structurally
-	    aligned to a reference structure. The protein also has to be whole because
-	    periodic boundaries are not taken into account.
-	
-	    Run the analysis with :meth:`RMSF.run`, which stores the results in the
-	    array :attr:`RMSF.results.rmsf`.
-	
-	    """
-	    def __init__(self, atomgroup, **kwargs):
-	        r"""Parameters
-	        ----------
-	        atomgroup : AtomGroup
-	            Atoms for which RMSF is calculated
-	        verbose : bool (optional)
-	             Show detailed progress of the calculation if set to ``True``; the
-	             default is ``False``.
-	
-	        Raises
-	        ------
-	        ValueError
-	             raised if negative values are calculated, which indicates that a
-	             numerical overflow or underflow occurred
-	
-	        Notes
-	        -----
-	        The root mean square fluctuation of an atom :math:`i` is computed as the
-	        time average
-	
-	        .. math::
-	
-	          \rho_i = \sqrt{\left\langle (\mathbf{x}_i - \langle\mathbf{x}_i\rangle)^2 \right\rangle}
-	
-	        No mass weighting is performed. 
-	        
-	        This method implements an algorithm for computing sums of squares while
-	        avoiding overflows and underflows :cite:p:`Welford1962`.
-	
-	        References
-	        ----------
-	        .. bibliography::
-	            :filter: False
-	
-	            Welford1962
-	
-	        """
-	        super(RMSF, self).__init__(atomgroup.universe.trajectory, **kwargs)
-	        self.atomgroup = atomgroup
-	
-	    def _prepare(self):
-	        self.sumsquares = np.zeros((self.atomgroup.n_atoms, 3))
-	        self.mean = self.sumsquares.copy()
-	
-	    def _single_frame(self):
-	        k = self._frame_index
-	        self.sumsquares += (k / (k+1.0)) * (self.atomgroup.positions - self.mean) ** 2
-	        self.mean = (k * self.mean + self.atomgroup.positions) / (k + 1)
-	
-	    def _conclude(self):
-	        k = self._frame_index
-	        self.results.rmsf = np.sqrt(self.sumsquares.sum(axis=1) / (k + 1))
-	
-	        if not (self.results.rmsf >= 0).all():
-	            raise ValueError("Some RMSF values negative; overflow " +
-	                             "or underflow occurred")
-
-
-To make our ``RMSF`` analysis class easier to access, we import it in ``__init__.py``. Add 
-
-.. code-block:: python
-
-	from .rmsfkit import RMSF
-
-This satisfies the first MDAKit requirement ("code in the package uses MDAnalysis").
-
-Filling in tests
-****************
-
-Once again, we take directly from the MDAnalysis package. 
-Here we take the `RMSF testing class <https://github.com/MDAnalysis/mdanalysis/blob/develop/testsuite/MDAnalysisTests/analysis/test_rms.py>`_ and update the contents of ``rmsfkit/tests/test_rmsfkit.py`` to reflect the following code block:
-
-.. code-block:: python
-
-	"""
-	Unit and regression test for the rmsfkit package.
-	
-	The TestRMSF class was taken from the MDAnalysis rms tests file and
-	the relevant modules were switched.
-	"""
-	
-	# Import package, test suite, and other packages as needed
-	from MDAnalysisTests.datafiles import GRO, XTC, rmsfArray
-	import MDAnalysis as mda
-	
-	from numpy.testing import assert_equal, assert_almost_equal
-	import numpy as np
-	import os
-	import pytest
-	
-	import rmsfkit
-	import sys
-	
-	def test_rmsfkit_imported():
-	    """Sample test, will always pass so long as import statement worked"""
-	    assert "rmsfkit" in sys.modules
-	
-	
-	class TestRMSF(object):
-	    @pytest.fixture()
-	    def universe(self):
-	        return mda.Universe(GRO, XTC)
-	
-	    def test_rmsf(self, universe):
-	        rmsfs = rmsfkit.RMSF(universe.select_atoms('name CA'))
-	        rmsfs.run()
-	        test_rmsfs = np.load(rmsfArray)
-	
-	        assert_almost_equal(rmsfs.results.rmsf, test_rmsfs, 5,
-	                            err_msg="error: rmsf profile should match test "
-	                            "values")
-	
-	    def test_rmsf_single_frame(self, universe):
-	        rmsfs = rmsfkit.RMSF(universe.select_atoms('name CA')).run(start=5, stop=6)
-	
-	        assert_almost_equal(rmsfs.results.rmsf, 0, 5,
-	                            err_msg="error: rmsfs should all be zero")
-	
-	    def test_rmsf_identical_frames(self, universe, tmpdir):
-	
-	        outfile = os.path.join(str(tmpdir), 'rmsf.xtc')
-	
-	        # write a dummy trajectory of all the same frame
-	        with mda.Writer(outfile, universe.atoms.n_atoms) as W:
-	            for _ in range(universe.trajectory.n_frames):
-	                W.write(universe)
-	
-	        universe = mda.Universe(GRO, outfile)
-	        rmsfs = rmsfkit.RMSF(universe.select_atoms('name CA'))
-	        rmsfs.run()
-	        assert_almost_equal(rmsfs.results.rmsf, 0, 5,
-	                            err_msg="error: rmsfs should all be 0")
-
-Since these tests use files included with the ``MDAnalysisTests`` package,
-we need to add it as a dependency in ``devtools/conda-envs/test_env.yaml``.
-Additionally, we need to add this dependency to the ``pyproject.toml``
-file. Under the ``[project.optional-dependencies]`` table, ensure that
-``MDAnalysisTests>=2.0.0`` is listed in ``test``.
-
-.. code-block:: toml
-
-	[project.optional-dependencies]
-	test = [
-	    "pytest>=6.0",
-	    "pytest-xdist>=2.5",
-	    "pytest-cov>=3.0",
-	    "MDAnalysisTests>=2.0.0",
-	]
-
-
-
-Confirm that the code and tests work
-************************************
-
-Up until this point we haven't tested any of the code. Following the the
-instructions from the generated ``README.md``, we can create a testing
-environment using ``conda`` or ``mamba`` (recommended).
-
-.. code-block:: bash
-
-	$ mamba create -n rmsfkit
-	$ mamba env update --name rmsfkit --file devtools/conda-envs/test_env.yaml
-        $ mamba activate rmsfkit
-	$ pip install -e .
-
-This installs the package as well as the testing environment. We can run tests locally using:
-
-.. code-block:: bash
-
-	$ pytest rmsfkit/tests
-
-This should pass without errors, but with some potential warnings. Local
-tests passing is only half of the testing requirement for an MDAKit. To fully
-satisfy the MDAKit testing requirement, tests must also pass through continuous
-integration services. The cookiecutter generates the necessary GitHub workflow
-files and can be found in ``.github/workflows/gh-ci.yaml``. Since our tests use
-the ``MDAnalysisTests`` package, we need to make one change to this file.
-
-Change the block
-
-.. code-block:: yaml
-
-	- name: Install MDAnalysis version
-	  uses: MDAnalysis/install-mdanalysis@main
-	  with:
-		version: ${{ matrix.mdanalysis-version }}
-		install-tests: false
-		installer:  mamba 
-		shell: bash  -l {0} 
-
-to 
-
-.. code-block:: yaml
-
-	- name: Install MDAnalysis version
-	  uses: MDAnalysis/install-mdanalysis@main
-	  with:
-		version: ${{ matrix.mdanalysis-version }}
-		install-tests: true  # this needs to be true! 
-		installer:  mamba 
-		shell: bash  -l {0} 
-
-Finishing up the tests
-**********************
-
-Our code only exists locally, but will need to be uploaded to a GitHub to run
-the prebuilt continuous integration provided by the cookiecutter.  During the
-cookie generation process, the target GitHub repository was identified and
-inserted into the workflows configuration as well as the ``README.md`` file. Add
-this repository as a remote to your local git repository,
-
-.. code-block:: bash
-
-	$ git remote add origin git@github.com:myusername/rmsfkit
-
-substituting ``myusername`` for your GitHub username. Make sure that this repository exists on GitHub and is *empty*.
-
-.. code-block:: bash
-
-	$ git push origin main
-
-Open the repository in GitHub and navigate to actions. Here you can see the status of the tests. If all was done correctly in the previous sections, these tests will pass!
-
-After this point, two more requirements are satisfied:
-
-* Code is versioned and provides in an accessible version-controlled repository
-* Tests and continuous integration are present
-
-Providing documentation
-***********************
-
-The cookiecutter includes a `Read the Docs <read the docs_>`_
-configuration as well a premade documentation environment file that is used by
-Read the Docs and for building locally. First, we need to install the correct
-environment for building the documentation. In the ``docs/`` directory, run:
-
-.. code-block:: bash
-
-	mamba env update --name rmsfkit -f requirements.yaml
-
-We can now build the documentation HTML files using the included ``Makefile``. Without looking at any of the documentation source files, run:
-
-.. code-block:: bash
-
-	make html
-
-This will convert the reStructuredText files into HTML in the ``_build`` directory.
-Open ``index.html`` and look around. 
-
-Notice that the "API Documentation" does not contain all of the information found in the docstrings of our code.
-This is because within ``source/api.rst``, the only contents are:
-
-.. code-block:: rst
-
-	API Documentation
-	=================
-	
-	.. autosummary::
-	   :toctree: autosummary
-	
-	   rmsfkit
-
-Instead, it should contain:
-
-.. code-block:: rst
-
-	API Documentation
-	=================
-	
-	.. autosummary::
-	   :toctree: autosummary
-	
-	   rmsfkit.RMSF
-
-After making the change, rerun ``make html`` and refresh the page. There will
-now be a table entry for the RMSF class. Clicking this entry will open the
-documentation that was present in the docstrings! Other than the newly visible
-docstring contents, the rest of the documentation is completely empty. Let's
-update the ``index.rst`` file to include a short description of the package:
-
-.. code-block:: rst
-
-	Welcome to rmsfkit's documentation!
-	=========================================================
-	
-	``rmsfkit`` is an example MDAKit that implements the functionality of the `analysis.rms.RMSF` class within the MDAnalysis package.
-	This MDAKit does not serve as a replacement for this functionality and using this MDAKit for real work is discouraged.
-	
-	.. toctree::
-	   :maxdepth: 2
-	   :caption: Contents:
-	
-	   getting_started
-	   api
-	
-	
-	Indices and tables
-	==================
-	
-	* :ref:`genindex`
-	* :ref:`modindex`
-	* :ref:`search`
-
-Additionally, we can update ``getting_started.rst`` to let potential users know how to install the package.
-
-.. code-block:: rst
-
-	Getting Started
-	===============
-	
-	The ``rmsfkit`` package is installable from source.
-	
-	.. code-block:: bash
-	
-	    git clone git@github.com:ianmkenney/rmsfkit.git
-	    cd rmsfkit/
-	    pip install .
-
-Run the ``make html`` command again and refresh the browser window to view the resulting changes.
-You'll notice the RMSF class documentation has an unformatted citation (``:cite:p:`Welford1962```).
-If your documentation need citations, you can easily include them using the bibtex format.
-We first create the bibtex file, ``references.bib`` in the ``doc/source/`` directory:
-
-.. code-block::
-
-	@article{Welford1962,
-	    author = { B. P.   Welford},
-	    title = {Note on a Method for Calculating Corrected Sums of Squares and Products},
-	    journal = {Technometrics},
-	    volume = {4},
-	    number = {3},
-	    pages = {419-420},
-	    year  = {1962},
-	    publisher = {Taylor & Francis},
-	    doi = {10.1080/00401706.1962.10490022}
-	}
-
-In ``conf.py``, we need to add a new extension (``sphinxcontrib.bibtex``) as well as the name of the bibtex file.
-
-.. code-block::
-
-	extensions = [
-	    'sphinx.ext.autosummary',
-	    'sphinx.ext.autodoc',
-	    'sphinx.ext.mathjax',
-	    'sphinx.ext.viewcode',
-	    'sphinx.ext.napoleon',
-	    'sphinx.ext.intersphinx',
-	    'sphinx.ext.extlinks',
-	    'sphinxcontrib.bibtex',  # add this line
-	]
-	
-	bibtex_bibfiles = ['references.bib']
-
-In addition, we have to add this extension the install requirements in ``docs/requirements.yaml``.
-Add ``- sphinxcontrib-bibtex`` as an additional dependency here.
-
-Update your environment with
-
-.. code-block:: bash
-
-	mamba env update --name rmsfkit -f requirements.yaml
-
-before once again running `make html`.
-Refreshing the RMSF documentation will now show a properly formatted citation using the information in the bibtex file.
-
-Deploying the documentation
-~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Log into `Read the Docs <read the docs_>`_ and navigate to the
-dashboard. Click the "Import a Project" button and find the repository in the
-list. Click the "+" and confirm that the name, URL, and default branch are
-correct.
-
-.. image:: img/rmsftutorial/import.png
-	:alt: Import a project into RTD
-
-.. image:: img/rmsftutorial/adding.png
-	:alt: Adding your repository to RTD
-
-Clicking next will begin the deployment. This immediately starts the build
-process, which can be confirmed by clicking the "Builds" tab. Once the build is
-completed, you can view the deployed documentation, which is now public. This
-completes the documentation requirement for an MDAKit. Notice that the "docs"
-badge in the GitHub rendered ``README.md`` is now green.
-
-Making an initial release
-*************************
-
-The MDAKit cookiecutter uses the `versioneer utility <https://github.com/python-versioneer/python-versioneer>`_ for version management.
-In brief, software versions are set through `git tags <https://git-scm.com/book/en/v2/Git-Basics-Tagging>`_.
-Since the kit is initiated without tags, the current version is set to ``0.0.0``. 
-
-.. code-block::
-
-	>>> import rmsfkit  
-	>>> rmsfkit.__version__  
-	'0+untagged.3.g3eed836'
-
-We can bump this to a ``0.1.0`` in preparation for an initial release on GitHub.
-
-.. code-block:: bash
-
-	$ git tag 0.1.0
-
-This should now be reflected in the interpreter (may require a package reinstall):
-
-.. code-block:: bash
-
-	>>> import rmsfkit  
-	>>> rmsfkit.__version__  
-	'0.1.0'
-
-Tags are not pushed to remote repositories by default. To push the `0.1.0` tag, use:
-
-.. code-block:: bash
-
-	$ git push --tags
-
-Viewing the repository tags page on GitHub, you should now see a ``0.1.0`` tag, which can then be used to create a release by expanding its menu options.
-Enter a release name, such as `v0.1.0` and publish!
-
-.. image:: img/rmsftutorial/creating_a_release.gif
-	:alt: Process for creating a release by making a tag
-
-Building from an existing project
-#################################
-
-Registering an existing package as an MDAKit is a straightforward process.
-Since the structure of an MDAKit is not as strict as the code found in the MDAnalysis core library, chances are very little restructuring is needed for registration.
-The primary concern is ensuring that the core MDAKit :ref:`requirements<requirements>` are met, as listed at the top of this document.
-
-Licensing
-*********
-
-One of the more pressing requirements for kit registration is clearly identifying the license that is applied to your code.
-This is typically included in a LICENSE file at the top level of your repository.
-`Without a license <https://choosealicense.com/no-permission/>`_, the only assumption a user can make about your code is that they are not in a position to use your code.
-Your license needs to be compatible with the GPLv2+ license currently used by MDAnalysis, in addition to the licenses of any other packages your mdakit depends on.
-Take time to consider how you would like to `license your project <https://choosealicense.com/>`_.
-Take time to consider how you would like to license your project. Further information on open source licensing can be found from sources such as: `choose a license <https://choosealicense.com/>`_, `tl;dr Legal <https://tldrlegal.com/>`_, the `Open Source Initiative <https://opensource.org/osd>`_, and the `Software Sustainability Insitute <https://www.software.ac.uk/resources/guides/choosing-open-source-licence>`_.
-
-Hosting code in a version controlled repository
-***********************************************
-
-Since the MDAKits registry makes heavy use of the GitHub actions infrastructure, registration of a kit requires that all code maintainers also have a GitHub account for communication purposes.
-For this reason, if your code is not already hosted in an accessible version controlled repository, hosting on `GitHub <https://github.com>`_ is recommended, although other services such as `Bitbucket <https://bitbucket.org/>`_, `GitLab <https://gitlab.com>`_, or self hosting is possible.
-The registry does not require that your code be available through packaging repositories such as the Python Package Index or conda-forge, although having your code available through these services is highly encouraged.
-After registration, users can find the installation instructions for the source code on your MDAKit page, which is specified in the ``src_install`` field in the ``metadata.yaml`` file (see :ref:`specification`).
-
-Documentation
-*************
-
-Basic documentation is required for MDAKit registration.
-The detail and depth of the documentation is ultimately up to you, but we require at a minimum that you provide README-style documentation explaining what the code is supposed to do, how to install it, and the basics of its use.
-Although this is the minimum, we highly recommend that you consider generating your documentation with dedicated tools such as `Sphinx <https://www.sphinx-doc.org/en/master/>`_, which allows you to generate static documentation using `reStructuredText <https://www.sphinx-doc.org/en/master/usage/restructuredtext/index.html>`_ formatted plain-text directly from your code.
-This makes it easier for your documentation to change alongside code changes.
-
-Using a documentation hosting service such as `Read the Docs <https://readthedocs.org>`_ or `GitHub Pages <https://pages.github.com/>`_ makes public access to your generated documentation automatic.
-
-Testing
-*******
-
-We also require that minimal regression tests are present.
-These tests are not just useful for when you make changes to your code, but also when any package dependencies (e.g. MDAnalysis, NumPy, and Python) change.
-Additionally, tests inform the users of your packages that the code performs at least the way you say it should and give them confidence that it can be used.
-Basic tests can be written with a variety of packages, such as the `pytest package <https://docs.pytest.org/en/7.4.x/>`_ (the default choice for MDAnalysis organization projects) or the `unittest package <https://docs.python.org/3/library/unittest.html#module-unittest>`_.
-Further improvements to your testing procedure may include automatically running the tests on pushing to your remote repositories, often referred to as continuous integration (CI).
-CI can be set up using repository pipeline tools, such as `GitHub Actions <https://github.com/features/actions>`_.
-
-When submitting an MDAKit to the registry, include the instructions for running the tests in the required ``metadata.yaml`` file (see a full example in the `registration <registration_>`_ section below).
-Assuming that your tests are in a ``test/`` directory at the top level of your repository, you could define your test commands as:
-
-.. code-block:: yaml
-
-	run_tests:
-	  - git clone latest
-	  - pytest -v tests/
-
-This makes a clone of your repository based on your latest `release tag on GitHub <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository>`_ and navigates into the repository root. Note that this is not a true :program:`git` command, but is instead specific to the MDAKits registry workflow and depends on the ``project_home`` field in the ``metadata.yaml`` file (see :ref:`specification`).
-The :program:`pytest` command then runs the tests found inside the ``tests/`` directory.
-If your tests are elsewhere, change this path appropriately.
-
-Dependencies that are only required for testing are indicated in the ``test_dependencies`` object.
-Suppose your package uses :program:`pytest` and used the `MDAnalysisTests <https://github.com/MDAnalysis/mdanalysis/wiki/UnitTests>`_ for sample data.
-This is reflected in your MDAKit metadata with
-
-.. code-block:: yaml
-
-	test_dependencies:
-	  - mamba install pytest MDAnalysis
-
-.. _registration:
-
-Registering an MDAKit
-#####################
-
-The MDAKit registration is the same regardless of the creation process for the kit.
-For simplicity, the follow examples will reference the ``rmsfkit`` MDAKit created in the cookiecutter section.
-In order to submit your MDAKit to the registry, you will need to create a pull request on GitHub against the MDAnalysis/MDAKits repository.
-Do this by creating a fork of the MDAnalysis/MDAKits repository.
-Clone the fork to your machine, navigate into ``MDAKits/mdakits/``, and make an empty directory with your MDAKit name:
-
-.. code-block:: bash
-
-	git clone git@github.com:yourusername/MDAKits
-	cd MDAKits/mdakits
-	mkdir rmsfkit/
-	cd rmsfkit
-
-Add the ``metadata.yaml`` for your MDAKit in this directory (see
-:ref:`specification` for details).     
-The contents of ``metadata.yaml`` for ``rmsfkit`` are:
-
-.. code-block:: yaml
-
-	project_name: rmsfkit
-	authors:
-	  - https://github.com/yourusername/rmsfkit/blob/main/AUTHORS.md
-	maintainers:
-	  - yourusername
-	description:
-	    An analysis module for calculating the root-mean-square fluctuation of atoms in molecular dynamics simulations.
-	keywords:
-	  - rms
-	  - rmsf
-	license: GPL-2.0-or-later
-	project_home: https://github.com/yourusername/rmsfkit
-	documentation_home: https://rmsfkit.readthedocs.io/en/latest/
-        documentation_type: API
-        src_install:
-          - git clone https://github.com/yourusername/rmsfkit.git
-          - cd rmsfkit/
-          - pip install .
-
-	## Optional entries
-	python_requires: ">=3.9"
-	mdanalysis_requires: ">=2.0.0"
-	run_tests:
-	  - pytest --pyargs rmsfkit.tests
-	development_status: Beta
-
-Commit and push this to your fork:
-
-.. code-block:: bash
-
-	git add metadata.yaml
-	git commit -m "Adding rmsfkit"
-	git push origin main
-
-Refresh the forked repository page in your browser. 
-Under "Contribute", open a pull request.  
-Add a title with the name of the kit and add a quick description.
-Click "Create pull request" and wait for the tests to pass.
-Once this is done, you can add a comment along the lines of "@MDAnalysis/mdakits-reviewers, ready for review".
-The reviewers will get back to you with any change requests before merging it in as a kit.
-At this point there are no additional steps for registering your kit!
-
-.. image:: img/rmsftutorial/submitting.gif
-	:alt: Process for submitting a kit to the registry
-
-Maintaining a kit
-#################
-
-There are a variety of reasons a kit may behave unexpectedly after being submitted to the registry.
-Apart from actively developing the kit, changes in kit dependencies, or even Python itself, can introduce (deprecate) new (old) functionality.
-For this reason, the kits' continuous integration is rerun weekly to confirm the kits expected behavior.
-In the event that a kit no longer passes its tests, an issue in MDAnalysis/MDAKits is automatically raised while notifying the maintainers indicated in the `metadata.yaml` file.
-While the registry developers will be happy to help where possible, ultimately, the maintainers of the MDAKit are responsible for resolving such issues and ensuring that the tests pass.
-The issue will automatically close after the next CI run if the tests pass again.
-
-.. _read the docs: https://readthedocs.org
+   making-a-kit/license
+   making-a-kit/hosting
+   making-a-kit/testing
+   making-a-kit/documentation
diff --git a/docs/source/registering-a-kit/metadata-yaml.rst b/docs/source/registering-a-kit/metadata-yaml.rst
new file mode 100644
index 00000000..e4554a48
--- /dev/null
+++ b/docs/source/registering-a-kit/metadata-yaml.rst
@@ -0,0 +1,108 @@
+.. _specification:
+   
+The ``metadata.yaml`` file
+==========================
+
+The ``metadata.yaml`` file is a `YAML format`_ file containing important
+information about an MDAKit. A template can be found :ref:`below <template>` 
+and in the MDAKit repository (`mdakits/template/metadata.yaml`_). For an 
+example of a completed ``metadata.yaml``, see the 
+:ref:`guided example <example-registration>`.
+
+The file includes both required and optional entries:
+
+- **Required entries**: Any variable in the 'required entries' section **must**
+  be provided. If missing or empty, the MDAKit *cannot be registered*.
+
+- **Optional entries**: Any variable in the 'optional entries' section **may** 
+  be left empty or be left out. However, it is recommended to provide as much
+  information as possible. Some aspects of the registry checks may not work if
+  these details are missing.
+
+Please see the comments in the template for an explanation of all possible
+items. Some additional notes on specifying how to run tests are also provided 
+:ref:`below <specifying-tests>`.
+
+.. Note::    
+
+   For now, the :ref:`template file <template>` serves as the primary  
+   specification for the MDAKits registry ``metadata.yaml`` file.  The MDAKits 
+   registry specification will likely be updated in the future with new optional
+   and required entries. The MDAKits team will assist developers with migrations
+   should they become necessary.
+
+
+.. _template:
+
+Template ``metadata.yaml`` file
+-------------------------------
+
+Start from this template (also available at `mdakits/template/metadata.yaml`_) 
+when creating a ``metadata.yaml`` for your MDAKit. See the comments for an 
+explanation of each item, and replace the values as appropriate for your MDAKit,
+noting the sections for *required entries* and *optional entries*.
+
+The template uses the strings ``GH_HOST_ACCOUNT``, ``MYPROJECT``, and 
+``MYPACKAGE`` to indicate that you should be filling in **your** details!
+   
+- ``GH_ACCOUNT``: The GitHub account where the source code repository is held; 
+  typically your username or the organization that you're part of.
+
+- ``MYPROJECT``: The name of your project. This is the name of your repository.
+  In the template we also use it as the PyPi/conda package name.
+   
+- ``MYPACKAGE``: The name of the Python package. It describes how you import it 
+  in Python code, i.e. it is used in ``import MYPACKAGE``.
+
+**Note on YAML format**: Please look at the `YAML format`_ specifications to 
+learn more about how to write correct YAML files. Note that YAML is a file 
+format where indentation matters so make sure that your editor uses spaces and 
+not TAB for indentation, as this can lead to incorrect YAML. Lines starting 
+with hash marks ``#`` are comments. You can add your own comments and modify the
+existing ones as needed.
+
+.. literalinclude:: ../../../mdakits/template/metadata.yaml
+   :language: yaml
+   :lines: 1-2,13-
+
+
+.. _specifying-tests:
+
+Specifying tests
+----------------
+
+The commands for running your MDAKit's tests must be added under the 
+``run_tests`` entry. Assuming that your tests are in a ``test/`` directory at
+the top level of your repository, you could define your test commands as:
+
+.. code-block:: yaml
+
+	run_tests:
+	  - git clone latest
+	  - pytest -v tests/
+
+This makes a clone of your repository based on your latest 
+`release tag on GitHub <https://docs.github.com/en/repositories/releasing-projects-on-github/managing-releases-in-a-repository>`_ 
+and navigates into the repository root. Note that this is not a true 
+:program:`git` command, but is instead specific to the MDAKits registry workflow
+and depends on the ``project_home`` field in the ``metadata.yaml`` file.
+
+The :program:`pytest` command then runs the tests found inside the ``tests/`` 
+directory. If your tests are elsewhere, change this path appropriately.
+
+Dependencies that are only required for testing are indicated in the 
+``test_dependencies`` object. Suppose your package uses :program:`pytest`, and
+used the `MDAnalysisTests <https://github.com/MDAnalysis/mdanalysis/wiki/UnitTests>`_ 
+for sample data. This is reflected in your MDAKit metadata with:
+
+.. code-block:: yaml
+
+	test_dependencies:
+	  - mamba install pytest MDAnalysis
+
+
+.. _`mdakits/template/metadata.yaml`:
+   https://github.com/MDAnalysis/MDAKits/blob/main/mdakits/template/metadata.yaml
+
+.. _YAML format: https://yaml.org/   
+
diff --git a/docs/source/registering-a-kit/step-by-step.rst b/docs/source/registering-a-kit/step-by-step.rst
new file mode 100644
index 00000000..35a0f91d
--- /dev/null
+++ b/docs/source/registering-a-kit/step-by-step.rst
@@ -0,0 +1,70 @@
+*********************************
+Step-by-step registration process
+*********************************
+
+This page lists the step-by-step process for registering an MDAKit.
+
+.. SeeAlso::
+    For an example, see :ref:`example-registration` from the guided 
+    MDAKit cookiecutter example.
+
+
+#. Create a fork of the MDAKit repository, 
+   https://github.com/MDAnalysis/mdakits.
+#. Make a new branch (choose any name, but *"add-my-awesome-mdakit"* is a good
+   one).
+#. Add a new folder under ``mdakits`` with the name of your MDAKit. Please note 
+   that this **must** match the name provided under the `project_name` entry of
+   the ``metadata.yaml`` file.
+#. Add a metadata YAML file with your MDAKit's details. Copy the template from
+   `mdakits/template/metadata.yaml`_ and modify it. See the comments in the 
+   template file and the :ref:`information here <specification>` for more 
+   details.
+#. Create a Pull Request (PR) from your branch against the *main* branch of the
+   `MDAnalysis/mdakits repository`. Add a title with the name of the kit (e.g. 
+   "register MyAwesomeTool") and add a short description of your MDAKit.
+   A number of tests should automatically start to run.
+
+#. Wait for the tests to pass (i.e., all results should be green and
+   pass).
+
+   * If there are problems at this stage (tests don't pass and you don't
+     know where to start fixing the problem), add a comment to your PR
+     with the text
+
+        *@MDAnalysis/mdakits-reviewers please help with tests.*
+
+     in order to notify the MDAnalysis team that you need assistance
+     with fixing your submission.
+   * If the tests passed, add a comment to your PR with the text
+
+        *@MDAnalysis/mdakits-reviewers, ready for review.*
+
+#. Someone from the MDAnalysis team will *review* your Pull Request for
+   fulfilling the :ref:`requirements for an MDAKit<requirements>` and for any
+   technical issues.
+
+   They may ask for modifications so please *check your PR regularly* or 
+   `enable GitHub notifications`_. Part of the registration process is to engage
+   in a conversation with the MDAnalysis team. The PR cannot be merged until all
+   relevant questions have been addressed.
+#. When your PR passes review, it will be merged and your MDAKit is registered - 
+   congrats!
+
+Remember: **You remain responsible for maintaining your code**. The registry 
+will continuously test your code but the MDAnalysis team cannot fix it for you -
+see :ref:`maintaining`.
+
+   .. Note:: 
+
+      The registry will alert you via GitHub issues when your tests
+      start failing with newer versions of your code, MDAnalysis, or other
+      dependencies. In this case your MDAKit will be displayed as broken in the registry. **It is your responsibility to fix any relevant code in your package and (if necessary) make a new
+      release of your code**.  
+
+
+.. _`mdakits/template/metadata.yaml`:
+   https://github.com/MDAnalysis/MDAKits/blob/main/mdakits/template/metadata.yaml
+
+.. _`enable GitHub notifications`:
+   https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications