semantic-release · gr2m · Jun 16, 2022 · Jun 16, 2022 · HonkingGoose · Jun 16, 2022
diff --git a/docs/developer-guide/plugin.md b/docs/developer-guide/plugin.md
@@ -12,9 +12,9 @@ To create a plugin for `semantic-release`, you need to decide which parts of the
 - `success`
 - `fail`
 
-`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecyles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
+`semantic-release` will require the plugin via `node` and look through the required object for methods named like the lifecycles stated above. For example, if your plugin only had a `verifyConditions` and `success` step, the `main` file for your object would need to `export` an object with `verifyConditions` and `success` functions.
 
-In addition to the lifecycle methods, each lifecyle is passed two objects:
+In addition to the lifecycle methods, each lifecycle is passed two objects:
 
 1. `pluginConfig` - an object containing the options that a user may pass in via their `release.config.js` file (or similar)
 2. `context` - provided by `semantic-release` for access to things like `env` variables set on the running process.

diff --git a/docs/extending/plugins-list.md b/docs/extending/plugins-list.md
@@ -55,12 +55,12 @@
 - [@semantic-release-plus/docker](https://github.com/semantic-release-plus/semantic-release-plus/tree/master/packages/plugins/docker)
   - `verifyConditions`: Verify that all needed configuration is present and login to the configured docker registry.
   - `publish`: Tag the image specified by `name` with the new version and channel and push it to the configured docker registry.
-  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry ie: next to latest.
+  - `addChannel`: Updates a release published on one channel with the destinations channel tag and pushes to the registry i.e.: next to latest.
 - [semantic-release-gcr](https://github.com/carlos-cubas/semantic-release-gcr)
   - `verifyConditions`: Verify that all needed configuration is present and login to the Docker registry
   - `publish`: Tag the image specified by `name` with the new version, push it to Docker Hub and update the latest tag
 - [semantic-release-vsce](https://github.com/raix/semantic-release-vsce)
-  - `verifyConditions`: Verify the presence and the validity of the vsce authentication and release configuration
+  - `verifyConditions`: Verify the presence and the validity of the "VS Code extension" authentication and release configuration
   - `prepare`: Create a `.vsix` for distribution
   - `publish`: Publish the package to the Visual Studio Code marketplace
 - [semantic-release-verify-deps](https://github.com/piercus/semantic-release-verify-deps)
@@ -84,7 +84,7 @@
   - `prepare`: Changes the version number in the `pom.xml` (or all `pom.xml` files in maven projects with multiple `pom.xml` files) and optionally creates a commit with this version number and pushes it to `master`
   - `publish`: Runs `mvn deploy` to deploy to maven central and optionally will update to next snapshot version and merge changes to development branch
 - [semantic-release-ado](https://github.com/lluchmk/semantic-release-ado)
-  - `prepare`: Stores the version number as an Azure DevOps pipeline variable availabe to downstream steps on the job
+  - `prepare`: Stores the version number as an Azure DevOps pipeline variable available to downstream steps on the job
 - [gradle-semantic-release](https://github.com/KengoTODA/gradle-semantic-release-plugin)
   - `verifyConditions`: Verify that project has a Gradle wrapper script, and `build.gradle` contains a task to publish artifacts.
   - `prepare`: Changes the version number in the `gradle.properties`

diff --git a/docs/extending/shareable-configurations-list.md b/docs/extending/shareable-configurations-list.md
@@ -6,7 +6,7 @@
 
 ## Community configurations
 - [@jedmao/semantic-release-npm-github-config](https://github.com/jedmao/semantic-release-npm-github-config)
-  - Provides an informative [git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., "chore(release): 1.2.3 [skip ci]\n\nnotes").
+  - Provides an informative [Git](https://github.com/semantic-release/git) commit message for the release commit that does not trigger continuous integration and conforms to the [conventional commits specification](https://www.conventionalcommits.org/) (e.g., `chore(release): 1.2.3 [skip ci]\n\nnotes`).
   - Creates a tarball that gets uploaded with each [GitHub release](https://github.com/semantic-release/github).
   - Publishes the same tarball to [npm](https://github.com/semantic-release/npm).
   - Commits the version change in `package.json`.
@@ -18,4 +18,3 @@
   - Updates GitHub release with release-notes.
   - Bumps a version in package.json.
   - Publishes the new version to [NPM](https://npmjs.org).
-
diff --git a/docs/recipes/ci-configurations/gitlab-ci.md b/docs/recipes/ci-configurations/gitlab-ci.md
@@ -14,7 +14,7 @@ GitLab CI supports [Pipelines](https://docs.gitlab.com/ee/ci/pipelines.html) all
 
 ### `.gitlab-ci.yml` configuration for Node projects
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
 **Note**: The`semantic-release` execution command varies depending on whether you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 
@@ -48,7 +48,7 @@ publish:
 
 ### `.gitlab-ci.yml` configuration for all projects
 
-This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
+This example is a minimal configuration for **semantic-release** with a build running Node 10 and 12. See [GitLab CI - Configuration of your jobs with `.gitlab-ci.yml`](https://docs.gitlab.com/ee/ci/yaml/README.html) for additional configuration options.
 
 **Note**: The`semantic-release` execution command varies depending if you are using a [local](../../usage/installation.md#local-installation) or [global](../../usage/installation.md#global-installation) **semantic-release** installation.
 

diff --git a/docs/support/FAQ.md b/docs/support/FAQ.md
@@ -44,7 +44,7 @@ Yes, **semantic-release** is a Node CLI application, but it can be used to publi
 
 To publish a non-Node package (without a `package.json`) you would need to:
 - Use a [global](../usage/installation.md#global-installation) **semantic-release** installation
-- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or rc file](../usage/configuration.md#configuration)
+- Set **semantic-release** [options](../usage/configuration.md#options) via [CLI arguments or `.rc` file](../usage/configuration.md#configuration)
 - Make sure your CI job executing the `semantic-release` command has access to a version of Node that [meets our version requirement](./node-version.md) to execute the `semantic-release` command
 
 See the [CI configuration recipes](../recipes/release-workflow/README.md#ci-configurations) for more details on specific CI environments.

diff --git a/docs/usage/configuration.md b/docs/usage/configuration.md
@@ -69,8 +69,8 @@ The branches on which releases should happen. By default **semantic-release** wi
 - regular releases to a distribution channel matching the branch name from any existing branch with a name matching a maintenance release range (`N.N.x` or `N.x.x` or `N.x` with `N` being a number)
 - regular releases to the `next` distribution channel from the branch `next` if it exists
 - regular releases  to the `next-major` distribution channel from the branch `next-major` if it exists
-- prereleases to the `beta` distribution channel from the branch `beta` if it exists
-- prereleases to the `alpha` distribution channel from the branch `alpha` if it exists
+- pre-releases to the `beta` distribution channel from the branch `beta` if it exists
+- pre-releases to the `alpha` distribution channel from the branch `alpha` if it exists
 
 **Note**: If your repository does not have a release branch, then **semantic-release** will fail with an `ERELEASEBRANCHES` error message. If you are using the default configuration, you can fix this error by pushing a `master` branch.