Use a consistent format for links into the reference docs

docs/howto/run-workloads-with-a-charm-kubernetes.md

@@ -204,7 +204,7 @@ See the [layer specification](https://canonical-pebble.readthedocs-hosted.com/en
 
 #### Add a configuration layer
 
-To add a configuration layer, call [`Container.add_layer`](ops.Container.add_layer) with a label for the layer, and the layer's contents as a YAML string, Python dict, or [`pebble.Layer`](#ops.pebble.Layer) object.
+To add a configuration layer, call [`Container.add_layer`](ops.Container.add_layer) with a label for the layer, and the layer's contents as a YAML string, Python dict, or [`pebble.Layer`](ops.pebble.Layer) object.
 
 You can see an example of `add_layer` under the ["Replan" heading](#replan). The `combine=True` argument tells Pebble to combine the named layer into an existing layer of that name (or add a layer if none by that name exists). Using `combine=True` is common when dynamically adding layers.
 

docs/howto/turn-a-hooks-based-charm-into-an-ops-charm.md

@@ -205,7 +205,7 @@ That allows us to fetch the Relation wherever we need it and access its contents
         )
 ```
 
-Note how `relation.data` provides an interface to the relation databag (see [](#ops.Relation.data)) and we need to select which part of that bag to access by passing an `ops.model.Unit` instance.
+Note how `relation.data` provides an interface to the relation databag (see [](ops.Relation.data)) and we need to select which part of that bag to access by passing an `ops.model.Unit` instance.
 
 #### Logging
 

docs/howto/write-unit-tests-for-a-charm.md

@@ -74,7 +74,7 @@ Notably, specifying relations in `charmcraft.yaml` does not automatically make t
 harness.  If you have e.g. code that accesses relation data, you must manually add those relations
 (including peer relations) for the harness to provide access to that relation data to your charm.
 
-In some cases it may be useful to start the test harness and fire the same hooks that Juju would fire on deployment. This can be achieved using the `begin_with_initial_hooks()` method , to be used in place of the `begin()` method. This method will trigger the events: `install -> relation-created -> config-changed -> start -> relation-joined` depending on whether any relations have been created prior calling `begin_with_initial_hooks()`. An example of this is shown in [](#ops.testing.Harness).
+In some cases it may be useful to start the test harness and fire the same hooks that Juju would fire on deployment. This can be achieved using the `begin_with_initial_hooks()` method , to be used in place of the `begin()` method. This method will trigger the events: `install -> relation-created -> config-changed -> start -> relation-joined` depending on whether any relations have been created prior calling `begin_with_initial_hooks()`. An example of this is shown in [](ops.testing.Harness).
 
 Using the `harness` variable, we can simulate various events in the charm’s lifecycle:
 

docs/tutorial/from-zero-to-hero-write-your-first-kubernetes-charm/integrate-your-charm-with-postgresql.md

@@ -252,7 +252,7 @@ The diagram below illustrates the workflow for the case where the database integ
 
 Now that the charm is getting more complex, there are many more cases where the unit status needs to be set. It's often convenient to do this in a more declarative fashion, which is where the collect-status event can be used.
 
-> Read more: [](#ops.CollectStatusEvent)
+> Read more: [](ops.CollectStatusEvent)
 
 In your charm's `__init__` add a new observer: