diff --git a/hips/hip-0018.md b/hips/hip-0018.md
index 4d432563..53fcf6eb 100644
--- a/hips/hip-0018.md
+++ b/hips/hip-0018.md
@@ -62,7 +62,7 @@ A potential positive is that including the tarballDigest would mean that utiliti
 
 ## How to teach this
 
-The feature can be documented by describing how we get the URL (taken from the description in the [Specification](#Specification) section). The usage of this URL is up to a user or third-party tool developer, but the URL would be included in the release object as one more informational piece with no prescribed usage.
+The feature can be documented by describing how we get the URL (taken from the description in the [Specification](#specification) section). The usage of this URL is up to a user or third-party tool developer, but the URL would be included in the release object as one more informational piece with no prescribed usage.
 
 ## Reference implementation
 A PR has been created to show a possible implementation: https://github.com/helm/helm/pull/10369
diff --git a/hips/hip-0026.md b/hips/hip-0026.md
index 701539ae..0df25b06 100644
--- a/hips/hip-0026.md
+++ b/hips/hip-0026.md
@@ -18,7 +18,7 @@ This will result in making Helm not only more extensible, but also more maintain
 
 ## Scope
 
-This HIP will cover the overall vision for the new plugin system, and an [implementation plan](#Implementation-Plan) for initial plugin types introduced into this system. This will will allow more categories of Helm functionality to become extended through additional plugin types in the future.
+This HIP will cover the overall vision for the new plugin system, and an [implementation plan](#implementation-plan) for initial plugin types introduced into this system. This will will allow more categories of Helm functionality to become extended through additional plugin types in the future.
 
 This HIP focuses primarily on CLI users.
 SDK users will not be required to use Wasm plugin functionality—it is expected that they may instead prefer to directly include Go libraries exposed by authors of those plugins.
@@ -40,7 +40,7 @@ The [high-level goal](https://helm.sh/docs/topics/plugins/#an-overview) of the H
 However, Helm 3 plugins had the following limitations:
 
 - Because plugins are primarily intended to add new Helm CLI subcommands, the Helm 3 plugin architecure is not helpful for SDK users, nor Chart Authors, or for customizing the existing Helm core functionality.
-- Helm 3 plugins call a user-specified arbitrary binary through a subprocess, which does not allow Helm to limit the scope of these commands (see Wasm sandboxing under [Security implications](#Security-implications) for how this will be resolved). Plugin maintainers must also be concerned about OS and architecture compatbility of pre-built binaries and scripts.
+- Helm 3 plugins call a user-specified arbitrary binary through a subprocess, which does not allow Helm to limit the scope of these commands (see Wasm sandboxing under [Security implications](#security-implications) for how this will be resolved). Plugin maintainers must also be concerned about OS and architecture compatbility of pre-built binaries and scripts.
 - There is only one specialized type of Helm 3 plugin—**downloader plugins**—which comes closest to what Helm 4 is modeling its new plugin types after. Downloader plugins are called by Helm for a specific purpose and have a well-defined scope. The main limitation here is that it does not allow users to modify other default behaviors of Helm.
 
 ### Other Helm 3 customization options did not adequately address the problem this HIP solves either
@@ -97,7 +97,7 @@ Initial plugins will be launched with the release of the new Plugin System, with
     For downloading a chart or subchart from a remote source using some other protocol than HTTP/S or OCI, such as [s3](https://artifacthub.io/packages/helm-plugin/s3/s3) or [git](https://artifacthub.io/packages/helm-plugin/git/helm-git).
 - **Postrender**
 
-    The [Helm 3 post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering) functionality moved to the new Wasm plugin system. See [Security implications](#Security-implications) section.
+    The [Helm 3 post-renderer](https://helm.sh/docs/topics/advanced/#post-rendering) functionality moved to the new Wasm plugin system. See [Security implications](#security-implications) section.
 - **CLI**
 
     The new plugin system will continue to allow users to build and install CLI plugins, which specify subcommands for the Helm CLI. However, these will also be run in Wasm sandbox rather than directly calling arbitrary executables as a subprocess as was done in Helm 3. This will require Helm 4 plugin developers to follow our tutorials for migrating their legacy CLI plugin to the new Wasm CLI plugin framework.
@@ -118,7 +118,7 @@ config: {}
 New fields:
 - `apiVersion`: This field is added to specify compatibility with the overall [Plugins System](#plugin-system) API. This will allow us to move to a new major version of Extism or other Wasm tooling independent of Helm major version.
 - `type`: added to specify the Plugin Type message schema version the plugin expects to handle. Versioning this allows it to be updated within the same MAJOR version of Helm. The proposed format is `PLUGIN_TYPE.plugins.helm.sh/PLUGIN_TYPE_VERSION`.
-- `sourceURL`: added to encourage best security practices. See [Security implications](#Security-implications).
+- `sourceURL`: added to encourage best security practices. See [Security implications](#security-implications).
 - `config`: Per-plugin configuration allowable by it's [Plugin Type](#plugin-type) definition.
 
 ### Helm plugin commands specification
@@ -162,7 +162,7 @@ A plugin comprises of the following filesystem structure (or a tar archive of):
 Helm will require plugins to be signed, producing an error if an unsigned plugin is attempted to be installed. With an exception for the following situation:
 
 - Installing from the local filesystem (for local development)
-- When the user provides an `--allow-insecure-plugins` flag (see [Security implications](#Security-implications))
+- When the user provides an `--allow-insecure-plugins` flag (see [Security implications](#security-implications))
 
 Helm 4 will support the same provenance functionality for Plugins as Helm 3 supports for charts. See <https://helm.sh/docs/topics/provenance/>. When Helm supports additional signing mechanisms such as [sigstore](https://www.sigstore.dev/) based signing for charts, this will also be supported for plugins. To follow this initiative, see [Support additional signing mechanisms than PGP](https://github.com/helm/community/issues/325).
 
@@ -182,7 +182,7 @@ sequenceDiagram
     P->> h: Call imported function
 ```
 
-For this, Helm 4 will be using 2 of the 3 main technologies that exist for interfacing with Wasm modules/components today (the 3rd option—WASI P2—is under [Rejected ideas](#Rejected-ideas)). The two that will be used here are:
+For this, Helm 4 will be using 2 of the 3 main technologies that exist for interfacing with Wasm modules/components today (the 3rd option—WASI P2—is under [Rejected ideas](#rejected-ideas)). The two that will be used here are:
 
 1. Native WASI P1 (POSIX/C-life FFI)
 [WASI P1](https://wasi.dev) defines a way for a module to export basic types in a C/POSIX style FFI. While simple, the caller has to manage much of the details, like converting internal structures into simple types (integers, pointers) and (manually) managing memory.
@@ -286,7 +286,7 @@ Two example Wasm plugins leveraging Extism have been prototyped. The first is an
 - https://github.com/gjenkins8/helm-plugin-ocigetter
 - https://github.com/gjenkins8/helm-plugin-gotemplate-renderer/
 
-The host functions are prototyped using Go testing, in `/testdriver/main_test.go` in each Git repo. These are fairly basic to start, but proves out that this capability works. Creating the proper interfaces will be part of the work implementing this HIP (see [Implementation Plan](#Implementation-Plan)).
+The host functions are prototyped using Go testing, in `/testdriver/main_test.go` in each Git repo. These are fairly basic to start, but proves out that this capability works. Creating the proper interfaces will be part of the work implementing this HIP (see [Implementation Plan](#implementation-plan)).
 
 ## Rejected ideas