Test prettier linter on docs

docs/_index.md

@@ -8,8 +8,9 @@ type: "docs"
 noToc: true
 hide_feedback: true
 sitemap:
-  priority: 1.0
+    priority: 1.0
 ---
+
 <div class="max-page">
   <p>
     Welcome to the Viam Documentation!

docs/appendix/_index.md

@@ -5,4 +5,4 @@ weight: 90
 simple_list: true
 type: "docs"
 description: "Reference and Background Material"
----
+---

docs/appendix/contribute.md

@@ -6,10 +6,11 @@ draft: true
 type: "docs"
 description: "A guide to viewing and contributing to Viam's open source efforts."
 ---
+
 ## Coming soon
 
 This page will contain information on:
 
-- Gaining access (while necessary) to our repos
-- Repo guidelines for commits and code style
-- Pull request processes and SLAs
+-   Gaining access (while necessary) to our repos
+-   Repo guidelines for commits and code style
+-   Pull request processes and SLAs

docs/appendix/glossary/api-namespace-triplet.md

@@ -8,15 +8,15 @@ aka:
 
 Every Viam {{< glossary_tooltip term_id="resource" text="resource" >}} subtype exposes an [application programming interface (API)](https://en.wikipedia.org/wiki/API) to describe how you can interact with that resource.
 
- These APIs are organized by colon-delimited-triplet identifiers, in the form of `namespace:type:subtype`.
+These APIs are organized by colon-delimited-triplet identifiers, in the form of `namespace:type:subtype`.
 
- The `namespace` for built-in Viam resources is `rdk`, while the `type` is `component` or `service`.
- `subtype` refers to a specific component or service, like a `camera` or `vision`.
+The `namespace` for built-in Viam resources is `rdk`, while the `type` is `component` or `service`.
+`subtype` refers to a specific component or service, like a `camera` or `vision`.
 
 One subtype can have various models, custom or built-in, but they all must conform to the subtype's API definition.
 This requirement ensures that when a resource of that model is deployed, you can [interface with it](/program/) using the same [client API methods](/program/apis/) you would when programming resources of the same subtype with a different model.
 
 For example:
 
-- The API of the built-in component [camera](/components/camera/) is `rdk:component:camera`, which exposes methods such as `GetImage()`.
-- The API of the built-in service [vision](/services/vision/) is `rdk:service:vision`, which exposes methods such as `GetDetectionsFromCamera()`.
+-   The API of the built-in component [camera](/components/camera/) is `rdk:component:camera`, which exposes methods such as `GetImage()`.
+-   The API of the built-in service [vision](/services/vision/) is `rdk:service:vision`, which exposes methods such as `GetDetectionsFromCamera()`.

docs/appendix/glossary/attribute.md

@@ -7,4 +7,4 @@ aka:
 type: "page"
 ---
 
- A configuration parameter of a resource.
+A configuration parameter of a resource.

docs/appendix/glossary/index.md

@@ -6,7 +6,7 @@ type: "docs"
 layout: "glossary"
 description: "A glossary that explains robotics and Viam-specific jargon."
 card:
-  name: reference
-  weight: 10
-  title: Glossary
----
+    name: reference
+    weight: 10
+    title: Glossary
+---

docs/appendix/glossary/model-namespace-triplet.md

@@ -10,5 +10,5 @@ aka:
 
 For example:
 
-- The `rdk:builtin:gpio` model implements the `rdk:component:motor` API to support [GPIO-controlled DC motors](/components/motor/gpio/).
-- The `rdk:builtin:DMC4000` model implements the `rdk:component:motor` API to support [DMC4000](/components/motor/dmc4000/) motor controllers.
+-   The `rdk:builtin:gpio` model implements the `rdk:component:motor` API to support [GPIO-controlled DC motors](/components/motor/gpio/).
+-   The `rdk:builtin:DMC4000` model implements the `rdk:component:motor` API to support [DMC4000](/components/motor/dmc4000/) motor controllers.

docs/appendix/glossary/model.md

@@ -8,4 +8,4 @@ aka:
 
 A particular implementation of a {{< glossary_tooltip term_id="resource" text="resource" >}} {{< glossary_tooltip term_id="subtype" text="subtype" >}}.
 
-For example: `ur5e` is a *model* of arm, implementing the [resource API](/program/apis/) of the [arm](/components/arm/) subtype of {{< glossary_tooltip term_id="component" text="component" >}}, which, in turn, is a {{< glossary_tooltip term_id="type" text="type" >}} of resource.
+For example: `ur5e` is a _model_ of arm, implementing the [resource API](/program/apis/) of the [arm](/components/arm/) subtype of {{< glossary_tooltip term_id="component" text="component" >}}, which, in turn, is a {{< glossary_tooltip term_id="type" text="type" >}} of resource.

docs/appendix/glossary/part.md

@@ -6,6 +6,6 @@ short_description: A single-board computer, desktop, laptop, or other computer r
 aka:
 ---
 
-Robots are organized into *parts*, where each part represents a computer (a [single-board computer](/installation/), desktop, laptop, or other computer) running `viam-server`, the hardware {{< glossary_tooltip term_id="component" text="components" >}} attached to it, and any {{< glossary_tooltip term_id="service" text="services" >}} or other resources running on it.
+Robots are organized into _parts_, where each part represents a computer (a [single-board computer](/installation/), desktop, laptop, or other computer) running `viam-server`, the hardware {{< glossary_tooltip term_id="component" text="components" >}} attached to it, and any {{< glossary_tooltip term_id="service" text="services" >}} or other resources running on it.
 
 For more information, see [Robot Architecture: Parts, Sub-Parts and Remotes](/manage/parts-and-remotes/).

docs/appendix/glossary/resource.md

@@ -10,10 +10,10 @@ Resources are individual, addressable elements of a robot.
 
 {{< glossary_tooltip term_id="part" text="Parts" >}} can operate multiple types of resources:
 
-- physical {{< glossary_tooltip term_id="component" text="components" >}}
-- software {{< glossary_tooltip term_id="service" text="services" >}}
-- [modular resources](/extend/modular-resources/) provided by {{< glossary_tooltip term_id="module" text="modules" >}}
-- {{< glossary_tooltip term_id="process" text="processes" >}}
+-   physical {{< glossary_tooltip term_id="component" text="components" >}}
+-   software {{< glossary_tooltip term_id="service" text="services" >}}
+-   [modular resources](/extend/modular-resources/) provided by {{< glossary_tooltip term_id="module" text="modules" >}}
+-   {{< glossary_tooltip term_id="process" text="processes" >}}
 
 Each part has local resources and can also have resources from another {{< glossary_tooltip term_id="remote" text="remote">}} robot part.
 The capabilities of each resource are exposed through the part’s API.

docs/appendix/glossary/robot.md

@@ -6,6 +6,6 @@ short_description: An organizational concept, consisting of either one part, or
 aka:
 ---
 
-An organizational concept, consisting of either one *{{< glossary_tooltip term_id="part" text="part" >}}*, or multiple *parts* working closely together to complete tasks.
+An organizational concept, consisting of either one _{{< glossary_tooltip term_id="part" text="part" >}}_, or multiple _parts_ working closely together to complete tasks.
 
 For more information, see [Robots](../../manage/fleet/robots/).

docs/appendix/glossary/type.md

@@ -2,11 +2,11 @@
 title: Type
 id: type
 full_link:
-short_description: Component and service are the built-in types of resource API the RDK provides. 
+short_description: Component and service are the built-in types of resource API the RDK provides.
 aka:
 ---
 
-In the {{< glossary_tooltip term_id="rdk" text="RDK" >}} architecture's {{< glossary_tooltip term_id="api-namespace-triplet" text="namespace triplet" >}} for resource APIs, *type* refers to the distinction between {{< glossary_tooltip term_id="component" text="component" >}} or {{< glossary_tooltip term_id="service" text="service" >}}.
+In the {{< glossary_tooltip term_id="rdk" text="RDK" >}} architecture's {{< glossary_tooltip term_id="api-namespace-triplet" text="namespace triplet" >}} for resource APIs, _type_ refers to the distinction between {{< glossary_tooltip term_id="component" text="component" >}} or {{< glossary_tooltip term_id="service" text="service" >}}.
 
 However, the meaning of "type" can be context dependent across the Viam platform.
 

docs/appendix/glossary/viam-robot-api.md

@@ -8,9 +8,9 @@ aka:
 
 The specification for communication with resources.
 
-- The SDKs implement the Viam Robot API server-side.
-- The SDKs use the Viam Robot API to act as clients.
+-   The SDKs implement the Viam Robot API server-side.
+-   The SDKs use the Viam Robot API to act as clients.
 
 Currently, the Viam Robot API is defined in a collection of Protocol Buffer files.
 
-All SDKs written by Viam use {{< glossary_tooltip term_id="grpc" text="gRPC" >}}  but the Viam Robot API itself does not mandate gRPC as the transport mechanism.
+All SDKs written by Viam use {{< glossary_tooltip term_id="grpc" text="gRPC" >}} but the Viam Robot API itself does not mandate gRPC as the transport mechanism.

docs/appendix/learning-resources.md

@@ -5,6 +5,7 @@ description: "A collection of links to external sources discussing robotics topi
 type: "docs"
 draft: true
 ---
+
 ## Overview
 
 The following sections contain links that we think you will find useful during your journey into robotics.
@@ -32,11 +33,11 @@ Unlike [motors](/components/motor/), servos do not require a motor driver chip.
 
 A typical servo control setup comprises the following:
 
-- A Raspberry Pi (or other [board](/components/board/))
-- A servo
-- An appropriate power supply
-  - If the servo will not be under any significant load and thus won’t draw much current, you may be able to get away with powering it off 5V (if that’s its required voltage) from the Pi pins.
-    However it is advisable to power it directly from a power supply that can meet its peak current needs so as not to inadvertently power cycle the Pi or other components.
+-   A Raspberry Pi (or other [board](/components/board/))
+-   A servo
+-   An appropriate power supply
+    -   If the servo will not be under any significant load and thus won’t draw much current, you may be able to get away with powering it off 5V (if that’s its required voltage) from the Pi pins.
+        However it is advisable to power it directly from a power supply that can meet its peak current needs so as not to inadvertently power cycle the Pi or other components.
 
 #### Wiring
 
@@ -66,12 +67,12 @@ Black, Brown, Red, Orange, Yellow, Green, Blue, Violet, Gray, White
 And their values on a resistor:
 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
 
-- The bands 1 and 2 indicate the first two significant digits on a resistor.
-- Band 3 is a multiplier on four-band resistors.
-For example, a resistor with brown, green, orange bands representing, 1, 5, and  3, respectively, which equates to 15 times ten to the third, or 15,000 Ohms, or 15 kOhms.
-- On resistors with four bands, the band 4 indicates tolerance, with gold being +/- 5% and silver being +/- 10%.
-- On five-band resistors, band 3 becomes an additional significant digit, band 4 becomes the multiplier, and band 5 becomes the tolerance band.
-- Six-band resistors are read identically to five-band resistors, their difference being that the sixth band indicates the resistor's temperature coefficient.
+-   The bands 1 and 2 indicate the first two significant digits on a resistor.
+-   Band 3 is a multiplier on four-band resistors.
+    For example, a resistor with brown, green, orange bands representing, 1, 5, and 3, respectively, which equates to 15 times ten to the third, or 15,000 Ohms, or 15 kOhms.
+-   On resistors with four bands, the band 4 indicates tolerance, with gold being +/- 5% and silver being +/- 10%.
+-   On five-band resistors, band 3 becomes an additional significant digit, band 4 becomes the multiplier, and band 5 becomes the tolerance band.
+-   Six-band resistors are read identically to five-band resistors, their difference being that the sixth band indicates the resistor's temperature coefficient.
 
 ### LEDs (Light-Emitting Diodes)