fixup

Author: emily-shen

src/content/docs/workers/configuration/environment-variables.mdx

@@ -49,8 +49,8 @@ export default {
 
 ### Configuring different environments in Wrangler
 
-You can set up [environments in Wrangler](/workers/wrangler/environments), and specify different values for your environment variables in each environment.
-`vars` is a non-inheritable key. [Non-inheritable keys](/workers/wrangler/configuration/#non-inheritable-keys) are configurable at the top-level, but cannot be inherited by environments and must be specified for each environment.
+[Environments in Wrangler](/workers/wrangler/environments) let you specify different configurations for the same worker, including different values for `vars` in each environment.
+As `vars` is a [non-inheritable key](/workers/wrangler/configuration/#non-inheritable-keys), they are not inherited by environments and must be specified for each environment.
 
 The example below sets up two environments, `staging` and `production`, with different values for `API_HOST` and `API_ACCOUNT_ID`.
 
@@ -62,17 +62,15 @@ name = "my-worker-dev"
 [env.staging.vars]
 API_HOST = "staging.example.com"
 API_ACCOUNT_ID = "staging_example_user"
-SERVICE_X_DATA = { URL = "service-x-api.dev.example", MY_ID = 123 }
 
 [env.production.vars]
 API_HOST = "production.example.com"
 API_ACCOUNT_ID = "production_example_user"
-SERVICE_X_DATA = { URL = "service-x-api.prod.example", MY_ID = 456 }
 ```
 
 </WranglerConfig>
 
-To run Wrangler commands in specific environments, you can pass in the `--env` or `-e` flag. For example, you can develop the Worker in the `dev` environment by running `npx wrangler dev -e=staging`, and deploy it with `npx wrangler deploy -e=production`.
+To run Wrangler commands in specific environments, you can pass in the `--env` or `-e` flag. For example, you can develop the Worker in an environment called `staging` by running `npx wrangler dev --env=staging`, and deploy it with `npx wrangler deploy --env=staging`.
 
 Learn about [environments in Wrangler](/workers/wrangler/environments).
 

src/content/docs/workers/wrangler/configuration.mdx

@@ -867,6 +867,7 @@ To bind other Workers to your Worker, assign an array of the below object to the
 - `service` <Type text="string" /> <MetaInfo text="required" />
 
   - The name of the Worker.
+  - To bind to a Worker in a specific [environment](/workers/wrangler/environments), you need to append the environment name to the Worker name. This should be in the format `<worker-name>-<environment-name>`. For example, to bind to a Worker called `worker-name` in its `staging` environment, `service` should be set to `worker-name-staging`.
 
 - `entrypoint` <Type text="string" /> <MetaInfo text="optional" />
 

src/content/docs/workers/wrangler/environments.mdx

@@ -8,10 +8,11 @@ description: Use environments to create different configurations for the same Wo
 import { WranglerConfig } from "~/components";
 
 Wrangler allows you to use environments to create different configurations for the same Worker application. Environments are configured in the Worker's [Wrangler configuration file](/workers/wrangler/configuration/).
+There is a default (top-level) environment and you can create named environments that provide environment-specific configuration.
 
 Review the following environments flow:
 
-1. You have created a Worker, named `my-worker` for example.
+1. Create a Worker, named `my-worker` for example.
 2. Create an environment, for example `dev`, in the Worker's [Wrangler configuration file](/workers/wrangler/configuration/), by adding a `[env.<ENV_NAME>]` section.
 
 <WranglerConfig>
@@ -55,7 +56,7 @@ Cloudflare effectively creates a new Worker for you when you create a Worker wit
 
 [Non-inheritable keys](/workers/wrangler/configuration/#non-inheritable-keys) are configurable at the top-level, but cannot be inherited by environments and must be specified for each environment.
 
-[Bindings](/workers/runtime-apis/bindings/) and [environment variables](/workers/configuration/environment-variables/) must be specified per each [environment](/workers/wrangler/environments/) in your [Wrangler configuration file](/workers/wrangler/configuration/).
+For example, [bindings](/workers/runtime-apis/bindings/) and [environment variables](/workers/configuration/environment-variables/) are non-inheritable, and must be specified per [environment](/workers/wrangler/environments/) in your [Wrangler configuration file](/workers/wrangler/configuration/).
 
 Review the following example Wrangler file:
 
@@ -83,8 +84,8 @@ kv_namespaces = [
 
 ### Service bindings
 
-To use a [service binding](/workers/wrangler/configuration/#service-bindings) that targets a Worker in a specific environment, you need to include the environment in `service` field. This should be in the format `<worker-name>-<environment-name>`.
-In the example below, we have two Workers, both with a `staging` environment. `worker-b` has a service binding to `worker-a`. Note how the service binding in the `staging` environment points to `worker-a-staging`, whereas the top-level service binding points to `worker-a`.
+To use a [service binding](/workers/wrangler/configuration/#service-bindings) that targets a Worker in a specific environment, you need to append the environment name to the target Worker name in the `service` field. This should be in the format `<worker-name>-<environment-name>`.
+In the example below, we have two Workers, both with a `staging` environment. `worker-b` has a service binding to `worker-a`. Note how the `service` field in the `staging` environment points to `worker-a-staging`, whereas the top-level service binding points to `worker-a`.
 
 <WranglerConfig>