diff --git a/docs/how-to/add-plans-and-devices.md b/docs/how-to/add-plans-and-devices.md
index 702497fe2f..36c28e99f3 100644
--- a/docs/how-to/add-plans-and-devices.md
+++ b/docs/how-to/add-plans-and-devices.md
@@ -25,6 +25,8 @@ To add plans, you would add the following into your configuration file:
 :language: yaml
 ```
 
+For BlueAPI to detect plans from repositories and be registered, they must be added to the `__init__.py` file with `__all__` = [<plan_name>, ...].
+
 
 Devices are added similarly, using `deviceManager` as the `kind`, like so:
 ```{literalinclude} ../../tests/unit_tests/valid_example_config/plans_and_devices.yaml
diff --git a/docs/how-to/integrate-with-numtracker.md b/docs/how-to/integrate-with-numtracker.md
index d52bd21747..7c34b76ad4 100644
--- a/docs/how-to/integrate-with-numtracker.md
+++ b/docs/how-to/integrate-with-numtracker.md
@@ -6,7 +6,7 @@
 
 You will need to [get numtracker itself configured for your instrument](https://github.com/DiamondLightSource/numtracker/wiki/new_beamline). 
 
-Blueapi needs [valid authentication configured](./authenticate.md) to communicate with numtracker. It will propogate its auth token so both blueapi and numtracker should be aware of who the user is and that they have permission to be on the instrument sessions (visits) that are intended for use.
+Blueapi needs [valid authentication configured](../how-to/authenticate.md) to communicate with numtracker. It will propogate its auth token so blueapi is aware of who the user is and that they have permission to be on the instrument sessions (visits) that are intended for use. Numtracker will not be aware of the user. 
 
 ## Configuration
 
diff --git a/docs/tutorials/local-auth.md b/docs/how-to/local-auth.md
similarity index 67%
rename from docs/tutorials/local-auth.md
rename to docs/how-to/local-auth.md
index b1e85e657c..afbf44e193 100644
--- a/docs/tutorials/local-auth.md
+++ b/docs/how-to/local-auth.md
@@ -1,6 +1,6 @@
-# Run Auth Locally
+# Run BlueAPI and connect to services locally
 
-BlueAPI can be secured using OIDC authenticaiton. For development it can be useful to run a containerised version of the OIDC stack, to serve a local instance of BlueAPI.
+For development purposes, it can be useful to run BlueAPI and adjacent services (Numtracker, Tiled, OPA etc.) locally. To do this, a containerised version of the stack should be run. This includes launching an instance of NumTracker, RabbitMQ, Keycloak, Tiled, OPA and a number of IOCs, in detached mode. Running BlueAPI and connected services locally as opposed to connecting to the cluster can be useful for learning more about the stack, running system tests, checking if changes during development propagate as expected etc. 
 
 To run the stack:
 
@@ -18,6 +18,8 @@ To run the stack:
 > alias docker=podman
 > ```
 
+There are also docs in the [Developer Guide](https://dev-guide.diamond.ac.uk/epics-containers/reference/setup/#docker-compose) to set up docker-compose on DLS workstations.
+
 3. Run `source tests/system_tests/.env` which will set required EPICS environmental variables
 4. Run `blueapi -c tests/system_tests/config.yaml serve` to launch BlueAPI configured to use the launched stack. This may take a while, as BlueAPI will attempt to connect to a number of devices via Channel Access
 
diff --git a/docs/how-to/run-cli.md b/docs/how-to/run-cli.md
deleted file mode 100644
index 54b0b672c4..0000000000
--- a/docs/how-to/run-cli.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Control the Worker via the CLI
-
-Blueapi comes with a minimal CLI client for basic control/debugging.
-
-## Basic Introspection
-
-The worker can tell you which plans and devices are available via:
-``` 
-blueapi controller plans
-blueapi controller devices
-```
-
-By default, the CLI will talk to the worker via a message broker on `tcp://localhost:61613`,
-but you can customize this via a [configuration file](./configure-app.md).
-
-```{literalinclude} ../../tests/unit_tests/valid_example_config/client.yaml
-:language: yaml
-```
-
-Then run
-
-```
-blueapi -c custom-address.yaml controller plans
-```
-
-The CLI has a number of features including [running plans](../tutorials/run-plan.md) and 
-
-See also [Full CLI reference](../reference/cli.md)
diff --git a/docs/how-to/run-container.md b/docs/how-to/run-container.md
index 58f45827c1..9330ec8e04 100644
--- a/docs/how-to/run-container.md
+++ b/docs/how-to/run-container.md
@@ -19,3 +19,12 @@ podman run ghcr.io/diamondlightsource/blueapi:latest
 ```
 
 To get a released version, use a numbered release instead of `latest`.
+
+## Starting the message bus
+
+The worker requires a running instance of the message bus, which in this case is RabbitMQ. The easiest way to start it is
+ to `compose` the services in `tests/system_tests/compose.yaml`
+
+```sh
+docker compose -f tests/system_tests/compose.yaml run rabbitmq --detach
+```
diff --git a/docs/tutorials/run-with-dev.md b/docs/how-to/run-with-dev.md
similarity index 87%
rename from docs/tutorials/run-with-dev.md
rename to docs/how-to/run-with-dev.md
index 60024caab5..066a1dd12f 100644
--- a/docs/tutorials/run-with-dev.md
+++ b/docs/how-to/run-with-dev.md
@@ -10,7 +10,7 @@ Ensure you are inside your virtual environment:
 source venv/bin/activate
 ```
 
-You will need to follow the instructions for setting up RabbitMQ as in [instructions for setting up RabbitMQ](run-bus.md).
+You will need to follow the instructions for setting up RabbitMQ as in [instructions for setting up RabbitMQ](../tutorials/5.%20config-add-rabbitmq-and-run-plan-cli.md).
 
 The worker will be available from the command line (`blueapi serve`), but can be started from vscode with additional
 debugging capabilities.
diff --git a/docs/how-to/use-persistent-volumes.md b/docs/how-to/use-persistent-volumes.md
index 993307585d..73b28d2382 100644
--- a/docs/how-to/use-persistent-volumes.md
+++ b/docs/how-to/use-persistent-volumes.md
@@ -5,7 +5,7 @@ BlueAPI can use persistent volumes as a scratch area. This allows the user to re
 ## Configuration
 
 :::{seealso}
-[Configure the Application](./configure-app.md)
+[Configure the Application](../how-to/configure-app.md)
 :::
 
 The relevant configuration is below:
diff --git a/docs/how-to/write-devices.md b/docs/how-to/write-devices.md
index 4fc1b8b949..8c72aab1ac 100644
--- a/docs/how-to/write-devices.md
+++ b/docs/how-to/write-devices.md
@@ -23,5 +23,5 @@ The return type annotation `-> MyTypeOfDetector` is required as blueapi uses it
 The device is created via a function rather than a global to preserve side-effect-free imports. Each device must have its own factory function.
 
 :::{seealso}
-[Numtracker integration](./integrate-with-numtracker.md) for how to configure where detectors write files.
+[Numtracker integration](../how-to/integrate-with-numtracker.md) for how to configure where detectors write files.
 :::
diff --git a/docs/resources/config.yaml b/docs/resources/config_pre_made.yaml
similarity index 100%
rename from docs/resources/config.yaml
rename to docs/resources/config_pre_made.yaml
diff --git a/docs/resources/enabled_plugins b/docs/resources/enabled_plugins
new file mode 100644
index 0000000000..17b6ee00a5
--- /dev/null
+++ b/docs/resources/enabled_plugins
@@ -0,0 +1 @@
+[rabbitmq_stomp].
diff --git a/docs/tutorials/installation.md b/docs/tutorials/1. installation.md
similarity index 86%
rename from docs/tutorials/installation.md
rename to docs/tutorials/1. installation.md
index 1b8f3e9dbf..f362d10a81 100644
--- a/docs/tutorials/installation.md
+++ b/docs/tutorials/1. installation.md	
@@ -1,4 +1,4 @@
-# Installation
+# 1. Installation
 
 ## Check your version of python
 
@@ -8,6 +8,10 @@ typing into a terminal:
 python3 --version
 ```
 
+## Clone the blueapi repository locally 
+
+Clone the blueapi repository to your local scratch directory and `cd` into it.
+
 ## Create a virtual environment
 
 It is recommended that you install into a “virtual environment” so this
diff --git a/docs/tutorials/2. quickstart.md b/docs/tutorials/2. quickstart.md
new file mode 100644
index 0000000000..670d0c9774
--- /dev/null
+++ b/docs/tutorials/2. quickstart.md	
@@ -0,0 +1,39 @@
+# 2. Quickstart guide
+
+Blueapi acts as a worker that can run Bluesky plans against devices for a specific laboratory setup. It can control devices to collect data and export events to tell downstream services about the data it has collected.
+
+You should be in the blueapi directory that you have cloned. From here, if you open VSCode, you will probably be prompted to 'Reopen in Container' which you can do and then run the following commands to start the worker. 
+
+If you not, you can still run the following from the venv created in page 1 but you may need to run the command below to have the dependencies required for this tutorial.
+
+```
+pip install .[demo]
+```
+
+## Start Worker
+
+To start the worker:
+```
+blueapi serve
+```
+This will use all the defaults in `src/blueapi/config.py`
+
+## Basic Introspection
+
+Blueapi comes with a minimal CLI client for basic control/debugging. We can use this to see which plans and devices are available. In a new terminal window, run the following commands. 
+
+If working in a venv, you may need to reactivate it. To do this, assuming you are still in the blueapi repo in your terminal, use:
+```
+source .venv/bin/activate
+```
+
+Now, run the following to see what plans and devices are available:
+
+``` 
+blueapi controller plans
+blueapi controller devices
+```
+
+We should now have an empty context.
+
+See also [Full CLI reference](../reference/cli.md)
diff --git a/docs/tutorials/3. config-add-devices.md b/docs/tutorials/3. config-add-devices.md
new file mode 100644
index 0000000000..61c4f8bd3f
--- /dev/null
+++ b/docs/tutorials/3. config-add-devices.md	
@@ -0,0 +1,28 @@
+# 3. Config add devices
+
+Blueapi is highlighly configurable. The config details aspects that impact how Blueapi works and it is customisable. 
+
+As a first step, create a `config.yaml` file. This would be best placed in the `docs/resources` folder. 
+
+Intially, add devices using the following code:
+
+```yaml
+env:
+  metadata:
+    instrument: demo
+  sources:
+    - kind: deviceManager
+      module: blueapi.tutorial.devices
+```
+
+The `env` section of the `config.yaml` file lets you create and set environment variables. The `demo` points to optional dependencies in the [pyproject.toml file](../../pyproject.toml). The module above points to the devices you will use for this tutorial which can be found [here](../../src/blueapi/tutorial/devices.py).
+
+Save the file and restart the worker to use this new `config.yaml` file you have created. To do this, navigate back to the terminal window where the worker is running, CTRL+C to close it then run the following command: 
+``` 
+blueapi --config docs/resources/config.yaml serve 
+```
+
+The above command asuumes you created the `config.yaml` file in `docs/resources`. Else, replace `docs/resources/config.yaml` with whichever file path your `config.yaml` has.
+
+Now run 
+```blueapi controller devices``` in the same terminal window as you did when previously running this command and you should see `det` and `stage`.
diff --git a/docs/tutorials/4. config-add-plans.md b/docs/tutorials/4. config-add-plans.md
new file mode 100644
index 0000000000..e7e1707cce
--- /dev/null
+++ b/docs/tutorials/4. config-add-plans.md	
@@ -0,0 +1,16 @@
+# 4. Config add plans
+
+As well as adding devices to the `config.yaml`, you can add plans. Under the code you already have, add the following:
+
+``` yaml
+    - kind: planFunctions
+      module: dodal.plans
+    - kind: planFunctions
+      module: dodal.plan_stubs.wrapped
+```
+These plans that will be used in this tutorial can be found in the [dodal repository](https://github.com/DiamondLightSource/dodal/tree/b4b38f1e0cf480faeb29d67695440c45a148f169). Specifically, in `dodal/src/dodal/plans/wrapped.py` and `dodal/src/dodal/plan_stubs/wrapped.py`.
+
+Save the changes you've made to the `config.yaml` file. Navigate back to the terminal where the blueapi worker is running. Restart the server to use this updated `config.yaml` file.
+
+Now run 
+```blueapi controller plans``` in the same terminal window used previously for this command and you should see a list of plans that can be run. For example, `count`, `list_grid_scan`, `num_scan` etc.
diff --git a/docs/tutorials/5. config-add-rabbitmq-and-run-plan-cli.md b/docs/tutorials/5. config-add-rabbitmq-and-run-plan-cli.md
new file mode 100644
index 0000000000..79407ce769
--- /dev/null
+++ b/docs/tutorials/5. config-add-rabbitmq-and-run-plan-cli.md	
@@ -0,0 +1,92 @@
+# 5. Run a Plan
+
+Now that we have a running worker and we have added plans and devices to the `config.yaml` file, we should be able to run a plan. 
+
+## Example Plans
+Run the following command in the terminal. (Same terminal where you ran `blueapi controller devices/plans`).
+
+Run a Sleep plan
+```
+blueapi -c config.yaml controller run -i cm12345-1 sleep '{"time": 5}'
+```
+You may get this error in the terminal logs: 
+```
+Error: Stomp configuration required to run plans is missing or disabled
+```
+
+We need to enable stomp in our `config.yaml` file. Add the following lines to your `config.yaml`. This should not be within the `env` section, but should rather be its own section.
+
+```yaml
+stomp:
+  enabled: true
+  url: tcp://localhost:61613/
+```
+
+Your overall config.yaml should now look like:
+
+```yaml
+env:
+  metadata:
+    instrument: demo
+  sources:
+    - kind: deviceManager
+      module: blueapi.tutorial.devices
+    - kind: planFunctions
+      module: dodal.plans
+    - kind: planFunctions
+      module: dodal.plan_stubs.wrapped
+stomp:
+  enabled: true
+  url: tcp://localhost:61613/
+```
+
+If you had difficulties creating your `config.yaml` file, you can use the pre-made one in the `docs/resources` folder. 
+
+Try running the Sleep plan again. You may come across this error:
+
+```
+WARNING stomp.py could not connect to host localhost, port 61613: [Errno 111] Connection refused
+```
+To run a plan in blocking mode, we need the message bus to be started. Blueapi can publish updates to this message bus asynchronously and then the CLI can view these updates and display them to the user. Run the following command in a new terminal window and restart the blueapi server.
+
+```sh
+echo "[rabbitmq_stomp].">enabled_plugins && podman run -it --rm --name rabbitmq-docs -v $(readlink -f enabled_plugins):/etc/rabbitmq/enabled_plugins:z -p 5672:5672 -p 61613:61613 rabbitmq:latest
+``` 
+
+Now, try running the Sleep plan. You should 'Plan succeeded' in the terminal logs of the terminal window where the blueapi server is running.
+
+Below are some other plans you can try. In the terminal window where the Sleep plan was run, you should see 
+```
+INFO root Stomp client subscribing to name='public.worker.event'
+```
+
+Press CTLR+C to disconnect the Stomp client then run a new plan.
+
+Run a Scan
+```
+blueapi -c config.yaml controller run count '{"detectors": ["det"], "num":5}' -i cm1234-5
+
+```
+Run a Step Scan
+```
+blueapi -c config.yaml controller run step_scan '{"detectors":["det"], "params":[["stage.x",[0,5,1]]]}' -i cm1234-5
+```
+
+## Adding extra components to the configuration
+
+Having added the minimal configuration required to run a plan, we can add optional components. For example: 
+
+The CLI uses REST requests talk to the worker via a message broker on `tcp://localhost:61613`,
+but you can customize this via the `config.yaml` file.
+
+```{literalinclude} ../../tests/unit_tests/valid_example_config/client.yaml
+:language: yaml
+```
+
+Then run
+
+```
+blueapi -c custom-address.yaml controller plans
+```
+
+Other components that can be added to the config are detailed in the the [How-to-Guide section](../how-to/).
diff --git a/docs/tutorials/6. run-plan-docs.md b/docs/tutorials/6. run-plan-docs.md
new file mode 100644
index 0000000000..aea9d38711
--- /dev/null
+++ b/docs/tutorials/6. run-plan-docs.md	
@@ -0,0 +1,75 @@
+# 6. Run a Plan from Docs page
+
+As well as running plans through the CLI, it is possible to run plans using the docs page. This is an easy way to run one plan but if you need to run multiple plans, it may be easier to use the CLI.
+
+In the terminal window where the worker is running, scroll to this line in the logs:
+
+```
+INFO uvicorn.error Uvicorn running on http://localhost:8000 (Press CTRL+C to quit)
+```
+Open the link (ctrl+click) and this should take you to the BlueAPI Control docs page. It should look like this:
+
+
+![BlueAPI docs page](docs_homepage.png)
+
+Scrolling down will show you endpoints grouped. The different groups are described below. 
+
+## Definitions:
+- Plan: a set of instructions for one aspect of experiment orchestration. More details can be found [here](https://blueskyproject.io/bluesky/v1.13.1rc1/plans.html)
+- Task: one individual instance of the plan being run. 
+- Device: hardware defined via ophyd protocols. For more information visit [dodal](https://github.com/DiamondLightSource/dodal) and its [Glossary page](https://diamondlightsource.github.io/dodal/main/reference/glossary.html).
+- Environment - definition already provided under the endpoint. 
+- Meta - definition already provided under the endpoint.
+
+## Steps for running a plan
+1. Find available devices. 
+
+The first recommended step is to find out what devices are available on the instrument. Scroll down to the 'Get Devices' endpoint (/api/v1/devices) and press the downwards arrow which should expand it to show the 'Try it out' button. Click the 'Try it out' button to enable further interaction. 
+
+![Find devices endpoint](find_devices.png)
+
+Next, press the 'Execute' button and scroll down to 'Responses' where you should see available devices (e.g. 'det' in the example below). Take note of the device name for later use.
+
+![Show devices](show_devices.png)
+
+2. Create a task using one of the available devices.
+
+Scroll back up to the 'Submit Task' endpoint (/api/v1/tasks). The default setting that should appear in the request body is the example of a 'count' task using detector 'x' and instrument session 'cm12345-1'. 
+
+![Submit task default](submit_task.png)
+
+Press the 'Try it out' button and replace the placeholder 'x' in the request body with the device you took note of in step 1 ('det' in this example). The instrument session can be left as 'cm12345-1' for the purposes of this tutorial.
+
+![Submit task with details](add_detector.png)
+
+Press 'Execute' and you should receive a '201' response that contains a 'task_id'. At the end of the response body box, press the clipboard symbol to copy this 'task_id'. 
+
+![Execute task](submit_task.png)
+
+3. Set created task in the previous step to be the active task 
+
+After creating a task in Step 2, it still needs to be set to be the active task. Scroll down to the 'Set Active Task' endpoint (/api/v1/worker/task). The default for 'task_id' should be 'string'.
+
+![Set active task default](create_task_default.png)
+
+Press 'Try it out' and paste the copied 'task_id' from earlier in the 'Request' body.
+
+![Set active task](set_active_task.png)
+
+Press the 'Execute' button and scroll down to 'Responses' and check if you got a '200 Successful Response'. The BlueAPI docs page only provides feedback for submitting the task to be the active task. To check if the plan actually ran successfully, check the logs (e.g. through ArgoCD, see below).
+
+4. Check the logs in the terminal window where the blueapi server is running
+
+To confirm if the plan ran successfully check the terminal logs. You should see something like: 
+
+```
+INFO blueapi.worker.task_worker Task ran successfully - returned: None
+```
+
+## Troubleshooting
+- 401 Response/cannot Execute plan - reload whole BlueAPI docs web page and log-in again using Keycloak. 
+- 2XX Task was created but could not be run successfully, no response - check logs for correct instrument session, have motor limits been exceeded?
+- New plan changes have been pushed to the repo but the plan isn't showing up 
+    - May need to pull through PlanDev and reload the environment
+    - Make sure the blueapi pod is pointing to the correct commit in ArgoCD (check values.yaml file in pxx-depolyment repo which is accessed through [epics-containers] (https://github.com/epics-containers) ). 
+        - Update values.yaml as needed, re-submit and re-create a task using BlueAPI and run again using same steps as above. 
diff --git a/docs/tutorials/scripting-plans.md b/docs/tutorials/7. scripting-plans.md
similarity index 99%
rename from docs/tutorials/scripting-plans.md
rename to docs/tutorials/7. scripting-plans.md
index 42554885a4..5a7b8fd889 100644
--- a/docs/tutorials/scripting-plans.md
+++ b/docs/tutorials/7. scripting-plans.md	
@@ -1,4 +1,4 @@
-# Scripting Plans
+# 7. Scripting Plans
 
 While the CLI can be used to query devices and run plans, it can be useful to
 combine multiple plans within a better interface than bash/shell scripting.
diff --git a/docs/tutorials/add_detector.png b/docs/tutorials/add_detector.png
new file mode 100644
index 0000000000..580d606e66
Binary files /dev/null and b/docs/tutorials/add_detector.png differ
diff --git a/docs/tutorials/create_task_default.png b/docs/tutorials/create_task_default.png
new file mode 100644
index 0000000000..82a0a0cfe0
Binary files /dev/null and b/docs/tutorials/create_task_default.png differ
diff --git a/docs/tutorials/docs_homepage.png b/docs/tutorials/docs_homepage.png
new file mode 100644
index 0000000000..52b4c50fb8
Binary files /dev/null and b/docs/tutorials/docs_homepage.png differ
diff --git a/docs/tutorials/find_devices.png b/docs/tutorials/find_devices.png
new file mode 100644
index 0000000000..b442d02405
Binary files /dev/null and b/docs/tutorials/find_devices.png differ
diff --git a/docs/tutorials/quickstart.md b/docs/tutorials/quickstart.md
deleted file mode 100644
index c4d783a21a..0000000000
--- a/docs/tutorials/quickstart.md
+++ /dev/null
@@ -1,33 +0,0 @@
-# Quickstart guide
-
-Blueapi acts as a worker that can run bluesky plans against devices for a specific
-laboratory setup. It can control devices to collect data and export events to tell
-downstream services about the data it has collected.
-
-## Start Worker
-
-To start the worker:
-
-```
-blueapi serve
-```
-
-The worker can also be started using a custom config file:
-
-```
-blueapi --config path/to/file serve
-```
-
-## Test that the Worker is Running
-
-Blueapi comes with a CLI so that you can query and control the worker from the terminal.
-
-```
-blueapi controller plans
-```
-
-The above command should display all plans the worker is capable of running.
-
-
-
-See also [full cli reference](../reference/cli.md)
diff --git a/docs/tutorials/run-bus.md b/docs/tutorials/run-bus.md
deleted file mode 100644
index f7d3b988be..0000000000
--- a/docs/tutorials/run-bus.md
+++ /dev/null
@@ -1,28 +0,0 @@
-# Run with local message bus
-
-Blueapi can publish updates to a message bus asynchronously, the CLI can then view these updates display them to the user.
-
-## Start RabbitMQ
-
-The worker requires a running instance of RabbitMQ. The easiest way to start it is
- to `compose` the services in `tests/system_tests/compose.yaml`
-
-```sh
-docker compose -f tests/system_tests/compose.yaml run rabbitmq --detach
-```
-
-## Config File
-
-Create a YAML file for configuring blueapi:
-
-```{literalinclude} ../../tests/unit_tests/valid_example_config/stomp.yaml
-:language: yaml
-```
-
-## Run the Server
-
-```
-blueapi --config /path/to/stomp.yaml serve
-```
-
-The server should print a connection message to the console. If there is an error, it will print an error message instead.
diff --git a/docs/tutorials/run-plan.md b/docs/tutorials/run-plan.md
deleted file mode 100644
index aa597ccf7f..0000000000
--- a/docs/tutorials/run-plan.md
+++ /dev/null
@@ -1,54 +0,0 @@
-# Run a Plan
-
-:::{note}
-You will need [a running server connected to a message bus](./run-bus.md) to complete this tutorial.
-:::
-
-With a [running worker](./quickstart.md), you can then run a plan. In a new terminal:
-
-```
-blueapi controller run -i cm12345-1 sleep '{"time": 5}'
-```
-
-## Example Plans
-
-Move a Motor
-
-```
-blueapi -c stomp.yaml controller run move \
-'{
-    "moves": {"x": 5}
-}'
-```
-
-Take a Snapshot on a Detector
-
-```
-blueapi -c stomp.yaml controller run count \
-'{
-    "detectors": ["image_det"]
-}'
-```
-
-Run a Scan
-
-```
-blueapi -c stomp.yaml controller run scan \
-'{
-    "detectors": ["image_det"], 
-    "spec": {
-        "type": "Line", 
-        "axis": "x", 
-        "start": 0, 
-        "stop": 10, 
-        "num": 10
-    }, 
-    "axes_to_move": {"x": "x"}
-}'
-```
-
-The names of the devices used (`"image_det"` and `"x"`) can be found via:
-
-```
-blueapi controller devices
-```
diff --git a/docs/tutorials/set_active_task.png b/docs/tutorials/set_active_task.png
new file mode 100644
index 0000000000..d30d3c49ea
Binary files /dev/null and b/docs/tutorials/set_active_task.png differ
diff --git a/docs/tutorials/show_devices.png b/docs/tutorials/show_devices.png
new file mode 100644
index 0000000000..46327c2286
Binary files /dev/null and b/docs/tutorials/show_devices.png differ
diff --git a/docs/tutorials/submit_task.png b/docs/tutorials/submit_task.png
new file mode 100644
index 0000000000..49819f3d77
Binary files /dev/null and b/docs/tutorials/submit_task.png differ
diff --git a/enabled_plugins b/enabled_plugins
new file mode 100644
index 0000000000..17b6ee00a5
--- /dev/null
+++ b/enabled_plugins
@@ -0,0 +1 @@
+[rabbitmq_stomp].
diff --git a/src/blueapi/cli/cli.py b/src/blueapi/cli/cli.py
index 8c746fe921..696f78af0a 100644
--- a/src/blueapi/cli/cli.py
+++ b/src/blueapi/cli/cli.py
@@ -379,7 +379,10 @@ def on_event(event: AnyEvent) -> None:
                 case TaskResult(result=None, type="NoneType"):
                     print("Plan succeeded")
                 case TaskResult(result=None, type=t):
-                    print(f"Plan returned unserializable result of type '{t}'")
+                    print(
+                        f"Plan succeeded but returned "
+                        f"unserializable result of type '{t}'"
+                    )
                 case TaskResult(result=r):
                     print(f"Plan succeeded: {r}")
                 case TaskError(type=exc, message=m):
diff --git a/tests/unit_tests/cli/test_cli.py b/tests/unit_tests/cli/test_cli.py
index 3e27cfc98e..c94c926349 100644
--- a/tests/unit_tests/cli/test_cli.py
+++ b/tests/unit_tests/cli/test_cli.py
@@ -357,7 +357,7 @@ def mock_events(topic: MessageTopic, callback: Callable[[Any, Any], Any]):
         (
             TaskResult(result=None, type="CustomType"),
             False,
-            "Plan returned unserializable result of type 'CustomType'\n",
+            "Plan succeeded but returned unserializable result of type 'CustomType'\n",
         ),
         (
             TaskError(type="ValueError", message="Error with value"),
diff --git a/tests/unit_tests/tutorial/test_devices.py b/tests/unit_tests/tutorial/test_devices.py
index 81c80e7f03..0d00b53d3f 100644
--- a/tests/unit_tests/tutorial/test_devices.py
+++ b/tests/unit_tests/tutorial/test_devices.py
@@ -9,7 +9,7 @@
 @pytest.fixture
 def context() -> BlueskyContext:
     loader = ConfigLoader(ApplicationConfig)
-    loader.use_values_from_yaml(Path("docs/resources/config.yaml"))
+    loader.use_values_from_yaml(Path("docs/resources/config_pre_made.yaml"))
     config: ApplicationConfig = loader.load()
     return BlueskyContext(configuration=config)