Minor fixes to various typos and improved grammar for better readability

docs/blueprint-designer-guide/blueprints/blueprints-yaml-structure.md

@@ -15,7 +15,7 @@ spec_version: 2
 ```
 
 ### `description`
-The blueprint’s description is an optional but recommended field. Blueprint description will be presented in the Torque's UI and API so users consuming environment will have more information about the blueprints to batter match their business need to the available set of blueprints published in the account catalog.
+The blueprint’s description is an optional but recommended field. Blueprint description will be presented in the Torque's UI and API so users consuming environment will have more information about the blueprints to better match their business need to the available set of blueprints published in the account catalog.
 
 
 ```yaml

docs/workflows/workflows-overview.md

@@ -7,7 +7,7 @@ Torque Workflows are a powerful way to automate and orchestrate complex processe
 
 ## Workflow Discovery
 
-Workflow discovery is done in the same way as Blueprints. The YAML files need to be under the `blueprints/` directory in the repository. Torque automatically scans for workflow files and makes them available based on their scope and configuration.
+Workflow discovery is done in the same way as Blueprints. The YAML files need to be under the `blueprints/` directory in the repository. Torque will automatically scan for workflow files and make them available based on their scope and configuration.
 
 The Workflow YAML standard is similar to the Blueprint standard. The only addition to the Workflow specification is the `workflow` block, which defines the workflow-specific configuration.
 
@@ -54,15 +54,15 @@ grains:
 
 ### `scope`
 
-The `scope` field in a Torque workflow determines where the workflow is available. There are two possible values for the `scope` field:
+The `scope` field in a Torque workflow determines where the workflow is available. There are three possible values for the `scope` field:
 
 1. `space`: Workflows with this scope are available at the space level, and can be triggered and executed without any dependencies.
 2. `env`: Workflows with this scope are available at the environment level. This means that they can be triggered and executed for the entire environment. These workflows can be used to automate and orchestrate processes that involve multiple resources within the environment.
 3. `env_resource`: Workflows with this scope will be available at the resource level (e.g. for a VM or DB). The type of resource for which the workflow will be available is defined by the `resource-types` field. Only resources that match the specified resource types will have access to these workflows. This allows for more granular control and customization of workflows based on specific resource types.
 
 ### `resource-types`
 
-When scoping a the workflow to an `env_resource`, the `resource-types` field allow to attach that workflow to the specified resource types.
+When scoping a workflow to an `env_resource`, the `resource-types` field allow to attach that workflow to the specified resource types.
 
 In this example, we scope this workflow only AWS EC2 instances resources: