diff --git a/SECURITY.md b/SECURITY.md
index b841241..fc658ff 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -29,15 +29,16 @@
 - Privately engage community members to understand and address the problem.
   Anyone brought onboard should be given a link to the OpenBMC [security
   response team guidelines][].
-- Work to determine the scope and severity of the problem, such as [CVSS metrics][].
+- Work to determine the scope and severity of the problem, such as [CVSS
+  metrics][].
 - Work to create or identify an existing [CVE][].
 - Coordinate workarounds and fixes with you and the community.
 - Coordinate announcement details with you, such as timing or how you want to be
   credited.
 - Create an OpenBMC security advisory.
 
-Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][], (SPECIAL
-REPORT CMU/SEI-2017-SR-022) for additional considerations.
+Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
+(SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
 
 Alternatives to this process:
 
diff --git a/architecture/code-update/emmc-storage-design.md b/architecture/code-update/emmc-storage-design.md
index 59ccba1..875f2a7 100644
--- a/architecture/code-update/emmc-storage-design.md
+++ b/architecture/code-update/emmc-storage-design.md
@@ -135,8 +135,8 @@
 
 - No initramfs: It may be possible to boot the rootfs by passing the UUID of the
   logical volume to the kernel, although a [pre-init script][] will likely still
-  be needed. Therefore, having an initramfs would offer a more standard implementation
-  for initialization.
+  be needed. Therefore, having an initramfs would offer a more standard
+  implementation for initialization.
 
 - FAT MBR partitioning: FAT is a simple and well understood partition table
   format. There is space for 4 independent partitions. Alternatively one slot
diff --git a/architecture/code-update/flash-layout.md b/architecture/code-update/flash-layout.md
index 68eb1c6..b47f957 100644
--- a/architecture/code-update/flash-layout.md
+++ b/architecture/code-update/flash-layout.md
@@ -10,7 +10,8 @@
 
 ### Boot loading and init
 
-For system initialization and bootstrap, [Das U-Boot][] was selected as the bootloader.
+For system initialization and bootstrap, [Das U-Boot][] was selected as the
+bootloader.
 
 After basic initialization of the system, the bootloader may present a prompt
 and/or start automatic boot. The commands and/or data to select the boot image
diff --git a/architecture/interface-overview.md b/architecture/interface-overview.md
index b66c240..ebc38db 100644
--- a/architecture/interface-overview.md
+++ b/architecture/interface-overview.md
@@ -23,12 +23,14 @@
 
 OpenBMC's services and the interfaces they provide are controlled by `systemd`.
 This document references OpenBMC `systemd` unit names to help link concepts to
-the source code. The reader is assumed to be familiar with [systemd
-concepts][]. The templated units ("unit@.service") may be omitted for clarity. Relevant
-details from the unit file may be shown, such as the program which implements a service.
+the source code. The reader is assumed to be familiar with [systemd concepts][].
+The templated units ("unit@.service") may be omitted for clarity. Relevant
+details from the unit file may be shown, such as the program which implements a
+service.
 
 The OpenBMC [Service Management][] interface can control `systemd` services. For
-example, disabling a BMC service will disable the corresponding external interface.
+example, disabling a BMC service will disable the corresponding external
+interface.
 
 [systemd concepts]:
   https://www.freedesktop.org/software/systemd/man/systemd.html#Concepts
@@ -250,8 +252,8 @@
         +--------------------------------------------------+
 ```
 
-To learn more, read the [Phosphor D-Bus interface docs][] and search for README files
-in various subdirectories under the xyz/openbmc_project path.
+To learn more, read the [Phosphor D-Bus interface docs][] and search for README
+files in various subdirectories under the xyz/openbmc_project path.
 
 [phosphor d-bus interface docs]:
   https://github.com/openbmc/phosphor-dbus-interfaces
diff --git a/community-membership.md b/community-membership.md
index 78a7e5a..e0bdf7b 100644
--- a/community-membership.md
+++ b/community-membership.md
@@ -15,8 +15,9 @@
 
 ## New contributors
 
-[New contributors] should be welcomed to the community by existing members, helped
-with review workflow, and directed to relevant documentation and communication channels.
+[New contributors] should be welcomed to the community by existing members,
+helped with review workflow, and directed to relevant documentation and
+communication channels.
 
 ## Established community members
 
diff --git a/designs/dump-manager.md b/designs/dump-manager.md
index f774c73..67d12bf 100644
--- a/designs/dump-manager.md
+++ b/designs/dump-manager.md
@@ -165,7 +165,8 @@
       come from a parallel class with this specific Enum name. All of the Enum
       strings should be in the format
       'domain.Dump.Create.CreateParameters.ParamName'. e.g.: { "key1": "value1",
-      "key2": "value2" } ends up in AdditionaData like: ["KEY1=value1", "KEY2=value2"]
+      "key2": "value2" } ends up in AdditionaData like: ["KEY1=value1",
+      "KEY2=value2"]
 
   - **Notify**: Notify the dump manager that a new dump is created.
     - ID: ID of the dump, if not 0 this will be the external id of the dump
diff --git a/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md b/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
index 394b6cb..8e61021 100644
--- a/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
+++ b/designs/entity-manager-hw-id-vpd-discover-via-device-tree.md
@@ -307,9 +307,9 @@
 
 8. Proposal: xyz.openbmc_project.MachineContext
 
-   Rejection: "We have all this stuff [.Model, .SerialNumber, ect. properties] defined
-   already. I'm not going to accept a new "bunch of random properties HPe thinks
-   are important [today] globbed into a new interface" interface"
+   Rejection: "We have all this stuff [.Model, .SerialNumber, ect. properties]
+   defined already. I'm not going to accept a new "bunch of random properties
+   HPe thinks are important [today] globbed into a new interface" interface"
 
    - Patrick Williams, Phosphor-dbus-interfaces maintainer.
 
diff --git a/designs/expired-password.md b/designs/expired-password.md
index ad9db23..a2c5dc8 100644
--- a/designs/expired-password.md
+++ b/designs/expired-password.md
@@ -37,9 +37,9 @@
 reason. Some servers (such as the OpenSSH server) handle the
 PasswordChangeRequired by implementing a "password change dialog".
 
-The [Redfish Specification version 1.7.0][] section 13.2.6.1 ("Password change required
-handling") provides the ManagerAccount resource v1.3 with a PasswordChangeRequired
-property which supports a password change dialog.
+The [Redfish Specification version 1.7.0][] section 13.2.6.1 ("Password change
+required handling") provides the ManagerAccount resource v1.3 with a
+PasswordChangeRequired property which supports a password change dialog.
 
 [redfish specification version 1.7.0]:
   https://www.dmtf.org/sites/default/files/standards/documents/DSP0266_1.7.0.pdf
diff --git a/designs/vpd-collection.md b/designs/vpd-collection.md
index 50950f7..1e52b63 100644
--- a/designs/vpd-collection.md
+++ b/designs/vpd-collection.md
@@ -8,9 +8,10 @@
 
 On OpenBMC, Vital Product Data (VPD) collection is limited to only one or two
 Field Replaceable Units (FRUs) today - one example is the BMC FRU. On OpenPower
-systems, the BMC also supports just one VPD format, the [OpenPower VPD] [1] format.
-As a part of its enterprise class servers, IBM will use the IPZ format VPD, which
-the BMC currently does not support. Certain FRUs also have keyword format VPD.
+systems, the BMC also supports just one VPD format, the [OpenPower VPD] [1]
+format. As a part of its enterprise class servers, IBM will use the IPZ format
+VPD, which the BMC currently does not support. Certain FRUs also have keyword
+format VPD.
 
 The BMC requires to read VPD for all FRUs for several reasons:
 
diff --git a/features.md b/features.md
index 86ca688..6963e1d 100644
--- a/features.md
+++ b/features.md
@@ -5,8 +5,7 @@
 - [BMCWeb][] HTTP/Web server
 - [WebUI Vue][] web application
 - REST Management: [BMCWeb Redfish][], [Phosphor REST APIs][] includes [Host
-  management
-  REST APIs][]
+  management REST APIs][]
 - [D-Bus interfaces][] describes internal interfaces
 - [D-Bus Object Mapper][]
 - [Remote KVM][]
diff --git a/security/how-to-report-a-security-vulnerability.md b/security/how-to-report-a-security-vulnerability.md
index d577376..3bc3589 100644
--- a/security/how-to-report-a-security-vulnerability.md
+++ b/security/how-to-report-a-security-vulnerability.md
@@ -44,15 +44,16 @@
 - Privately engage community members to understand and address the problem.
   Anyone brought onboard should be given a link to the OpenBMC [security
   response team guidelines][].
-- Work to determine the scope and severity of the problem, such as [CVSS metrics][].
+- Work to determine the scope and severity of the problem, such as [CVSS
+  metrics][].
 - Coordinate workarounds and fixes with you and the community.
 - Coordinate announcement details with you, such as timing or how you want to be
   credited.
 - At the agreed time, publish the OpenBMC security advisory, reveal the fix, and
   publish the CVE.
 
-Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][], (SPECIAL
-REPORT CMU/SEI-2017-SR-022) for additional considerations.
+Please refer to the [CERT Guide to Coordinated Vulnerability Disclosure][],
+(SPECIAL REPORT CMU/SEI-2017-SR-022) for additional considerations.
 
 Alternatives to this process:
 
diff --git a/security/network-security-considerations.md b/security/network-security-considerations.md
index 674bbfb..e9ebff3 100644
--- a/security/network-security-considerations.md
+++ b/security/network-security-considerations.md
@@ -6,13 +6,14 @@
 
 This is only intended to be a guide; security is ultimately the responsibility
 of projects which choose to incorporate OpenBMC into their project. If you find
-a security vulnerability, please consider [how to report a security vulnerability][].
+a security vulnerability, please consider [how to report a security
+vulnerability][].
 
 [how to report a security vulnerability]:
   https://github.com/openbmc/docs/blob/master/security/how-to-report-a-security-vulnerability.md
 
-Threats to the BMC are classified using the [CIA triad][]. All threat types are significant;
-here is an example of each:
+Threats to the BMC are classified using the [CIA triad][]. All threat types are
+significant; here is an example of each:
 
 - Confidentiality: If an attacker can get data from the BMC, they may be able to
   chain other vulnerabilities to establish a covert information channel to get
@@ -51,9 +52,9 @@
 the `https://github.com/openbmc/meta-aspeed` repository under
 `recipes-kernel/linux/linux-aspeed_git.bb`.
 
-Per [CVE 1999-0524][], responding to certain ICMP packets can give an attacker more
-information about the BMC's clock or subnet, which can help with subsequent attacks.
-OpenBMC responds to all ICMP requests.
+Per [CVE 1999-0524][], responding to certain ICMP packets can give an attacker
+more information about the BMC's clock or subnet, which can help with subsequent
+attacks. OpenBMC responds to all ICMP requests.
 
 [cve 1999-0524]: https://nvd.nist.gov/vuln/detail/CVE-1999-0524
 
@@ -108,9 +109,9 @@
 1.  Configure OpenBMC recipes to build the unwanted feature out of the BMC's
     firmware image. This gives the BMC the advantage of a smaller attack
     surface.
-2.  Implement something like the [Redfish ManagerNetworkProtocol][] properties for
-    IPMI, SSH, and other BMC services, possibly by using shell commands like 'systemctl
-    disable ipmid' and 'systemctl stop ipmid'.
+2.  Implement something like the [Redfish ManagerNetworkProtocol][] properties
+    for IPMI, SSH, and other BMC services, possibly by using shell commands like
+    'systemctl disable ipmid' and 'systemctl stop ipmid'.
 
 [redfish managernetworkprotocol]:
   https://redfish.dmtf.org/schemas/ManagerNetworkProtocol.v1_4_0.json
@@ -208,9 +209,9 @@
 
 #### The webui-vue Web application
 
-General considerations for Web applications such as given by [OWASP
-Web Application Security Guidance][] apply to OpenBMC. The webui-vue uses
-username and password-based authentication, and REST APIs for subsequent access.
+General considerations for Web applications such as given by [OWASP Web
+Application Security Guidance][] apply to OpenBMC. The webui-vue uses username
+and password-based authentication, and REST APIs for subsequent access.
 
 [owasp web application security guidance]:
   https://www.owasp.org/index.php/Web_Application_Security_Guidance
diff --git a/security/obmc-github-security-advisory-template.md b/security/obmc-github-security-advisory-template.md
index 6fd299b..76a8448 100644
--- a/security/obmc-github-security-advisory-template.md
+++ b/security/obmc-github-security-advisory-template.md
@@ -1,7 +1,8 @@
 # OpenBMC Security Advisory Template
 
 This has guidelines for OpenBMC repository maintainers to follow when creating
-new draft GitHub security advisories as part of the [Security response team guidelines][].
+new draft GitHub security advisories as part of the [Security response team
+guidelines][].
 
 Note that the sections under the "Description" section are intended for the
 security advisory "Description" field
diff --git a/security/obmc-security-response-team-guidelines.md b/security/obmc-security-response-team-guidelines.md
index b2b351f..2a3f615 100644
--- a/security/obmc-security-response-team-guidelines.md
+++ b/security/obmc-security-response-team-guidelines.md
@@ -47,8 +47,8 @@
      response team. For example, link to these guidelines.
    - Coordinate with all collaborators and keep them informed.
 
-   Considerations in the [CERT Guide to Coordinated Vulnerability Disclosure][] (SPECIAL
-   REPORT CMU/SEI-2017-SR-022) may guide the process.
+   Considerations in the [CERT Guide to Coordinated Vulnerability Disclosure][]
+   (SPECIAL REPORT CMU/SEI-2017-SR-022) may guide the process.
 
    Example collaborations:
 
@@ -64,9 +64,10 @@
       problems. When fixing the problem, use the contribution process but limit
       the details in the issue or use a private channel to discuss.
    3. Negotiate how the code review will proceed.
-      - Consider [contributing][] using a Gerrit [private change][] if everyone has
-        access to Gerrit.
-      - Consider using [Patch set][] emails to make reviews accessible to all stakeholders.
+      - Consider [contributing][] using a Gerrit [private change][] if everyone
+        has access to Gerrit.
+      - Consider using [Patch set][] emails to make reviews accessible to all
+        stakeholders.
    4. When agreed:
       - Publish a security advisory to the affected OpenBMC repository.
       - Make the Gerrit review publicly viewable.
@@ -76,18 +77,19 @@
 Repository maintainer process steps: 1. Create a private gerrit code review and
 oversee development of the fix. 2. Create a draft advisory under
 github.com/openbmc/<REPO>/security/advisories. Please follow guidance in the
-[OpenBMC Security Advisory Template][]. Add the openbmc security-response group and
-other stakeholders to the advisory. 3. Review the security bulletin with stakeholders
-to get it ready to publish. 4. Work with the SRT to identify CVEs. If you are unsure
-what counts as a vulnerability, please consult with the SRT. For example, independent
-bugs should have separate CVEs. A security advisory can reference multiple CVEs.
-When the CVE is known, add it to the security advisory, and reference it in the commit
-message, stating how the fix relates to the CVE. For example: This fixes CVE-yyyy-nnnnn.
-Doing so helps downstream security responders. If the commit is a partial fix, please
-explain that and provide references to the other parts of the fix. 5. If stakeholders
-negotiate for coordinated disclosure, plan to release the fix and the security advisory
-on the negotiated day. 6. When the code fix and the advisory are both ready (subject
-to coordinated disclosure), please merge the fixes (and make any private review be
+[OpenBMC Security Advisory Template][]. Add the openbmc security-response group
+and other stakeholders to the advisory. 3. Review the security bulletin with
+stakeholders to get it ready to publish. 4. Work with the SRT to identify CVEs.
+If you are unsure what counts as a vulnerability, please consult with the SRT.
+For example, independent bugs should have separate CVEs. A security advisory can
+reference multiple CVEs. When the CVE is known, add it to the security advisory,
+and reference it in the commit message, stating how the fix relates to the CVE.
+For example: This fixes CVE-yyyy-nnnnn. Doing so helps downstream security
+responders. If the commit is a partial fix, please explain that and provide
+references to the other parts of the fix. 5. If stakeholders negotiate for
+coordinated disclosure, plan to release the fix and the security advisory on the
+negotiated day. 6. When the code fix and the advisory are both ready (subject to
+coordinated disclosure), please merge the fixes (and make any private review be
 public) publish the security advisory, and email the security-response team.
 
 [security vulnerability reporting process]: ./obmc-security-response-team.md