Start the main CLI function with a short description of the package not just of this particular function. e.g. From the conda CLI: "conda is a tool for managing and deploying applications, environments and packages."

i.e. "COLD is a tool for reconstructing crystal structures from coded laue diffraction data"?

Add more detailed description paragraph in the middle which highlights some more detailed features.

i.e. "With COLD you can collect data faster by scanning the entire sample simultaneously [insert few more sentences about it]"

Add more detailed description about what users can expect COLD to do to their file-system? e.g. What folders and files will likely be created?

End with a link to the docs for the config file. Because the config file contains MUCH more than can be described in a quick help statement.

The .vscode directory included in this project contains file paths specific to your personal computer, so it is not portable. Add .vscode to the .gitignore.

Following convention, python packages with a CLI implement the CLI in a file called main.py which is located in the top level namespace of the package [1]. Optionally, you can then have setuptools or whatever packager create a console script entry point [2] which automatically creates a bash/batch script and puts it on the path during installation. You can see an example of this in jeweler [3].

[1] https://docs.python.org/3/library/__main__.html#main-py-in-python-packages
[2] https://setuptools.pypa.io/en/latest/userguide/entry_point.html
[3a] https://github.com/carterbox/jeweler/blob/6d9482c71046745744ab9762390191cb7d364307/setup.py#L16
[3b] https://github.com/carterbox/jeweler/blob/master/src/jeweler/__main__.py

This logging configuration should be moved to the main function of the CLI. Otherwise, the logging level will be set to INFO for anyone who imports this package. (I think this may actually, have a global effect? SO then packages outside of COLD will start logging also?

Because I don't know a better way to do it, let's use an example from the azure pipelines yaml documentation:

resources:
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers are not enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional; 2020.1 and greater
      stages: [ string ] # list of stages to evaluate for trigger event, optional; 2020.1 and greater

The configuration options on readthedocs should have comment after every parameter explaining it.

I also suggest avoiding abbreviations and using camelCase. i.e.

algorithm:
    position:
        method: string  # Do you really have multiple methods yet? If there is only one method, then don't have this parameter.
        initial: int  # The initial guess for the position
    signal:
        method: string
        initial:
            maxSize: int  # [mu] The SI abbreviation for microns is μm?
            avgSize: int  # [mu] The SI abbreviation for microns is μm?
            absoluteTolerance: int  # Don't know what this parameter means