doc: fix a few minor typos (#1576)

docs/howto/store-plans-in-a-bucket.mdx

@@ -3,16 +3,16 @@ title: "Store plans in a Bucket"
 ---
 
 ### Github 
-Digger can Github Artifacts to store `terraform plan` outputs. In order to enable it you can set the following argument in digger_workflow.yml:
+Digger can use Github Artifacts to store `terraform plan` outputs. In order to enable it you can set the following argument in digger_workflow.yml:
 
 ```
 upload-plan-destination: github
 ```
 
 ### GCP 
-You can also configure plan outputs to be uploaded to GCP Buckets instead. This is handy in case you want your plan outputs to stay within your organisation's network for security or compliance reasons.
+You can also configure plan outputs to be uploaded to GCP Buckets instead. This is handy in case you want your plan outputs to stay within your organisation's approved storage providers for security or compliance reasons.
 
-To change change digger to upload the plan to GCP set the follow argument in the digger_workflow.yml file
+To change digger to upload the plan to GCP set the follow argument in the digger_workflow.yml file
 
 ```
 with:

docs/howto/using-terragrunt.mdx

@@ -11,7 +11,7 @@ There are 2 ways of using Digger with Terragrunt:
 
 [Demo repo](https://github.com/diggerhq/demo-terragrunt-gcp)
 
-Digger using a single terragrunt project if you just list it as a project as follows:
+Digger uses a single terragrunt project if you just list it as a project as follows:
 
 ```
 projects:
@@ -26,7 +26,7 @@ This will perform a `terragrunt apply` after changes are detected within this di
 
 [Demo repo](https://github.com/diggerhq/test-terragrunt-racecondition)
 
-In many cases with terragrunt you don't want to mention all of your terragrunt components since there can be tens or hundreds of those (not to mention all the dependencies of those). In this case you can just liase it to digger and it will perform dynamic generation of projects for you and trigger the relevant `terragrunt apply` commands on all impacated projects per pull request. It will also handle dependencies of these projects. You can configure this using the following:
+In many cases with terragrunt you don't want to mention all of your terragrunt components since there can be tens or hundreds of those (not to mention all the dependencies of those). In this case you can just leave it to digger and it will perform dynamic generation of projects for you before triggering the relevant `terragrunt apply` commands on all impacated projects per pull request. It will also handle dependencies of these projects. You can configure this using the following:
 
 ```
 generate_projects:

docs/howto/versioning.mdx

@@ -1,17 +1,17 @@
 ---
 title: "Specifying version"
-description: "For serious usecases always use a pinned version which is of the form @vX.Y.Z since this will download compiled binary. Addition to being faster to run, it is also more secure than using a commit from a branch"
+description: "For serious usecases always use a pinned version which is of the form @vX.Y.Z since this will download a compiled binary. In addition to being faster to run, it is also more secure than using a commit from a branch"
 ---
 
 <Warning>
   For serious usecases always use a pinned version which is of the form @vX.Y.Z
-  since this will download compiled binary. Addition to being faster to run, it
+  since this will download a compiled binary. In addition to being faster to run, it
   is also more secure than using a commit from a branch
 </Warning>
 
 ## Use vLatest tag
 
-The default and recommended way of versioning Digger is to use the vLatest tag, which is always pointing to the latest release. The difference compared to just specifying "latest" is that it is a release with pre-built binaries, so it is faster than building from a branch, which using "latest" effectively does.
+The default and recommended way of versioning Digger is to use the vLatest tag, which always points to the latest release. The difference compared to just specifying "latest" is that it is a release with pre-built binaries, so it is faster than building from a branch, which using "latest" effectively does.
 
 ```
 - name: digger