workflows: Apply suggestions from code review

Co-authored-by: Jun Lee <[email protected]>

Author: elithrar

src/content/docs/workflows/get-started/guide.mdx

@@ -31,11 +31,7 @@ At the end of this guide, you should be able to author, deploy and debug your ow
 
 ## Prerequisites
 
-To continue:
-
-1. Sign up for a [Cloudflare account](https://dash.cloudflare.com/sign-up/workers-and-pages) if you have not already.
-2. Install [`npm`](https://docs.npmjs.com/getting-started).
-3. Install [`Node.js`](https://nodejs.org/en/). Use a Node version manager like [Volta](https://volta.sh/) or [nvm](https://github.com/nvm-sh/nvm) to avoid permission issues and change Node.js versions. [Wrangler](/workers/wrangler/install-and-update/) requires a Node version of `16.17.0` or later.
+<Render file="prereqs" product="workers" />
 
 ## 1. Define your Workflow
 
@@ -83,7 +79,7 @@ A Workflow definition:
 2. Has at least one or more calls to `step.do` that encapsulates the logic of your Workflow.
 3. Allows steps to return (optional) state, allowing a Workflow to continue execution even if subsequent steps fail, without having to re-run all previous steps.
 
-A single Worker application can contain multiple Workflow definitions, as long as each Workflow has a unique class name. This can be useful for code re-use or to define Workflows are related to each other conceptually.
+A single Worker application can contain multiple Workflow definitions, as long as each Workflow has a unique class name. This can be useful for code re-use or to define Workflows which are related to each other conceptually.
 
 Each Workflow is otherwise entirely independent: a Worker that defines multiple Workflows is no different from a set of Workers that define one Workflow each.
 
@@ -93,11 +89,11 @@ Each `step` in a Workflow is an independently retriable function.
 
 A `step` is what makes a Workflow powerful, as you can encapsulate errors and persist state as your Workflow progresses from step to step, avoiding your application from having to start from scratch on failure and ultimately build more reliable applications.
 
-* A step can execute code (`step.do`) or sleep a Workflow (`step.sleep`)
+* A step can execute code (`step.do`) or sleep a Workflow (`step.sleep`).
 * If a step fails (throws an exception), it will be automatically be retried based on your retry logic.
-* Ia step succeeds, any state it returns will be persisted within the Workflow.
+* If a step succeeds, any state it returns will be persisted within the Workflow.
 
-At it's most basic, a step looks like this:
+At its most basic, a step looks like this:
 
 ```ts title="src/index.ts"
 // Import the Workflow definition
@@ -123,7 +119,7 @@ Each call to `step.do` accepts three arguments:
 
 1. (Required) A step name, which identifies the step in logs and telemetry
 2. (Required) A callback function that contains the code to run for your step, and any state you want the Workflow to persist
-3. (Optional) A `StepConfig` that defines the retry configuration (max retries, delay, and backoff algorithm) for the step.
+3. (Optional) A `StepConfig` that defines the retry configuration (max retries, delay, and backoff algorithm) for the step
 
 When trying to decide whether to break code up into more than one step, a good rule of thumb is to ask "do I want _all_ of this code to run again if just one part of it fails?". In many cases, you do _not_ want to repeatedly call an API if the following data processing stage fails, or if you get an error when attempting to send a completion or welcome email.
 
@@ -134,13 +130,13 @@ For example, each of the below tasks is ideally encapsulated in its own step, so
 * Querying a D1 database or a database via [Hyperdrive](/hyperdrive/)
 * Calling a third-party API
 
-If a subsequent step fails, your Workflow can retry from that step, using any state returned from a previous step. This can also help you avoid unnecessarily querying a database or calling an paid API repeatedly for data you've already fetched.
+If a subsequent step fails, your Workflow can retry from that step, using any state returned from a previous step. This can also help you avoid unnecessarily querying a database or calling an paid API repeatedly for data you have already fetched.
 
 :::note
 
 The term "Durable Execution" is widely used to describe this programming model.
 
-"Durable" describes the ability of the program (application) to implicitly persist state without you having to write to an external store or serialize program state manual
+"Durable" describes the ability of the program (application) to implicitly persist state without you having to manually write to an external store or serialize program state.
 
 :::
 
@@ -170,7 +166,7 @@ script_name = "workflows-starter"
 
 :::note
 
-If you have changed the name of the Workflow in your wrangler commands, the JavaScript class name, or the name of the project you created, ensure that you update the values above to match.
+If you have changed the name of the Workflow in your Wrangler commands, the JavaScript class name, or the name of the project you created, ensure that you update the values above to match the changes.
 
 :::
 
@@ -336,7 +332,7 @@ Deployed workflows-starter triggers (1.12 sec)
   workflow: workflows-starter
 ```
 
-A Worker with a valid Workflow definition will be automatically registered by Workflows. You can list your current Workflows using wrangler:
+A Worker with a valid Workflow definition will be automatically registered by Workflows. You can list your current Workflows using Wrangler:
 
 ```sh
 npx wrangler workflows list
@@ -355,16 +351,16 @@ Showing last 1 workflow:
 With your Workflow deployed, you can now run it.
 
 1. A Workflow can run in parallel: each unique invocation of a Workflow is an _instance_ of that Workflow.
-2. An instance will run to completion (success or failure)
+2. An instance will run to completion (success or failure).
 3. Deploying newer versions of a Workflow will cause all instances after that point to run the newest Workflow code.
 
 :::note
 
-Because Workflows can be long running, it's possible to have running instances that represent different versions of your Workflow code over time.
+Because Workflows can be long running, it is possible to have running instances that represent different versions of your Workflow code over time.
 
 :::
 
-To trigger our Workflow, we will use the `wrangler` CLI and pass in an optional `--payload`. The `payload` will be passed to your Workflow's `run` method handler as an `Event`
+To trigger our Workflow, we will use the `wrangler` CLI and pass in an optional `--payload`. The `payload` will be passed to your Workflow's `run` method handler as an `Event`.
 
 ```sh
 npx wrangler workflows trigger workflows-starter '{"hello":"world"}'
@@ -447,7 +443,7 @@ From the output above, we can inspect:
 * The status (success, failure, running) of each step
 * Any state emitted by the step
 * Any `sleep` state, including when the Workflow will wake up
-* Retries associated with each step.
+* Retries associated with each step
 * Errors, including exception messages
 
 :::note
@@ -480,8 +476,8 @@ Re-deploying the Workers script containing your Workflow code will re-create the
 
 ## Next steps
 
-* Learn more about [how events are passed to a Workflow](/workflows/build/events-and-parameters/)
-* Binding to and triggering Workflow instances using the [Workers API](/workflows/build/workers-api/)
-* The [Rules of Workflows](/workflows/build/rules-of-workflows/) and best practices for building applications using Workflows.
+* Learn more about [how events are passed to a Workflow](/workflows/build/events-and-parameters/).
+* Learn more about binding to and triggering Workflow instances using the [Workers API](/workflows/build/workers-api/).
+* Learn more about the [Rules of Workflows](/workflows/build/rules-of-workflows/) and best practices for building applications using Workflows.
 
 If you have any feature requests or notice any bugs, share your feedback directly with the Cloudflare team by joining the [Cloudflare Developers community on Discord](https://discord.cloudflare.com).