docs: update styles

docs/source/apollo-cli.mdx

@@ -3,9 +3,13 @@ title: The Apollo CLI
 description: ⚠️ Partially deprecated ⚠️
 ---
 
-> ⚠️ **Important:** All `apollo service:*` commands are now **deprecated** in favor of commands in the [Rover CLI](/rover/).
+<Caution>
 
-The **Apollo CLI** provides commands for interacting with different components of the Apollo platform, including Apollo Client, Apollo Server, and GraphOS.
+All `apollo service:*` commands are now deprecated in favor of commands in the [Rover CLI](/rover/).
+
+</Caution>
+
+The _Apollo CLI_ provides commands for interacting with different components of the Apollo platform, including Apollo Client, Apollo Server, and GraphOS.
 
 ## Download and install
 
@@ -47,13 +51,22 @@ apollo client:check --graph=MyGraph --key=service:docs-example-graph:NYKgCqwfCyY
 
 Most of the Apollo CLI's commands are in the following namespaces:
 
-- `client` (such as `apollo client:codegen`) for interactions involving Apollo Client and Apollo Studio
-- `service` (such as `apollo service:check`) for interactions involving Apollo Server and Apollo Studio
-  - ⚠️ **Important:** All `apollo service:*` commands are now **deprecated** in favor of commands in the [Rover CLI](/rover/).
+- `client` (such as `apollo client:codegen`) for interactions involving Apollo Client and GraphOS Studio
+- `service` (such as `apollo service:check`) for interactions involving Apollo Server and GraphOS Studio
+
+  <Caution>
+
+  All `apollo service:*` commands are now deprecated in favor of commands in the [Rover CLI](/rover/).
+
+  </Caution>
 
 For a full list of commands in a particular namespace, use the `apollo help` command:
 
-> Omit `npx` from the example commands below if you [installed the Apollo CLI globally](#global-installation).
+<Note>
+
+Omit `npx` from the example commands below if you [installed the Apollo CLI globally](#global-installation).
+
+</Note>
 
 ```
 $ npx apollo help client

docs/source/ci-cd.mdx

@@ -12,7 +12,7 @@ Rover's installation is similar to many other CLI tools, but the recommended met
 * [Jenkins](#jenkins)
 * [Gitlab CI/CD](#gitlab-cicd)
 
-> If you're using Rover with a CI/CD provider not listed here, we'd love for you to share the steps by opening an [issue](https://github.com/apollographql/rover/issues/new/choose) or [pull request](https://github.com/apollographql/rover/compare)!
+If you're using Rover with a CI/CD provider not listed here, we'd love for you to share the steps by opening an [issue](https://github.com/apollographql/rover/issues/new/choose) or [pull request](https://github.com/apollographql/rover/compare).
 
 ## CircleCI
 
@@ -28,7 +28,11 @@ echo 'export PATH=$HOME/.rover/bin:$PATH' >> $BASH_ENV
 
 After you install Rover and modify the `$BASH_ENV` as shown, Rover should work like normal.
 
-> **Important:** Because the `rover config auth` command is interactive, you need to [authenticate using an environment variable](./configuring#with-an-environment-variable) in your project settings.
+<Note>
+
+Because the `rover config auth` command is interactive, you need to [authenticate using an environment variable](./configuring#with-an-environment-variable) in your project settings.
+
+</Note>
 
 #### Full example
 
@@ -75,9 +79,13 @@ To fix this, you can append Rover's location to the [`$GITHUB_PATH`](https://doc
 echo "$HOME/.rover/bin" >> $GITHUB_PATH
 ```
 
-> **Important:** Because the `rover config auth` command is interactive, you need to [authenticate using an environment variable](./configuring#with-an-environment-variable) in your project settings.
->
-> GitHub actions uses [project environments](https://docs.github.com/en/actions/reference/environments) to set up secret environment variables. In your action, you choose a `build.environment` by name and set `build.env` variables using the saved secrets.
+<Note>
+
+Because the `rover config auth` command is interactive, you need to [authenticate using an environment variable](./configuring#with-an-environment-variable) in your project settings.
+
+GitHub actions uses [project environments](https://docs.github.com/en/actions/reference/environments) to set up secret environment variables. In your action, you choose a `build.environment` by name and set `build.env` variables using the saved secrets.
+
+</Note>
 
 The following is a full example script, showing how to choose an `apollo` environment and set an `APOLLO_KEY` variable:
 
@@ -300,7 +308,11 @@ If you're running in a Node.js workflow, it might be easier to use the [NPM dist
 
 You can use Rover by adding it to your `package.json` dependencies using [these instructions](./getting-started#npm-installer) and then execute it using npm scripts, similar to other workflows you might already have. If you don't want to install Rover as a dependency, you can run it with `npx` by using the `-p` flag:
 
-> **Note:** Only run this command with the `--background` flag if you have the Apollo Studio GitHub integration enabled on your repository.
+<Note>
+
+Only run this command with the `--background` flag if you have the Apollo Studio GitHub integration enabled on your repository.
+
+</Note>
 
 ```bash
 npx -p @apollo/rover rover graph check my-graph@prod --schema=./schema.graphql --background

docs/source/commands/config.mdx

@@ -3,7 +3,7 @@ title: Rover config commands
 description: Create and manage configuration profiles
 ---
 
-Rover enables you to create multiple **configuration profiles**, each of which corresponds to a different GraphOS identity. Each configuration profile has an associated [API key](/graphos/api-keys), which determines its permissions. You manage your configuration profiles with the `rover config` set of commands.
+Rover enables you to create multiple _configuration profiles_, each of which corresponds to a different GraphOS identity. Each configuration profile has an associated [API key](/graphos/api-keys), which determines its permissions. You manage your configuration profiles with the `rover config` set of commands.
 
 ## Displaying configuration profiles
 
@@ -68,7 +68,7 @@ Successfully deleted profile "sso"
 
 ### `config clear`
 
-The `config clear` command deletes **all** of your stored configuration profiles:
+The `config clear` command deletes all of your stored configuration profiles:
 
 ```
 rover config clear

docs/source/commands/contracts.mdx

@@ -67,7 +67,7 @@ Options include:
 
 The name of the [source variant](/graphos/delivery/contracts/#2-fed1-enable-variant-support-for-tag) to use for supergraph schema filtering.
 
-The source variant must belong to the same graph as the contract variant. It must also be a federated variant with subgraphs. If your graph uses Federation 1, you must enable its support for the `@tag` directive in Apollo Studio.
+The source variant must belong to the same graph as the contract variant. It must also be a federated variant with subgraphs. If your graph uses Federation 1, you must enable its support for the `@tag` directive in GraphOS Studio.
 
 **Required** the first time you publish a contract.
 
@@ -89,7 +89,7 @@ A tag name to [include](/graphos/delivery/contracts/#contract-filters) when filt
 --include-tag foo --include-tag bar
 ```
 
-To specify an _empty_ include list, provide`--no-include-tags` instead of this option.
+To specify an empty include list, provide`--no-include-tags` instead of this option.
 
 Every tag name **must**:
 
@@ -129,7 +129,7 @@ A tag name to [exclude](/graphos/delivery/contracts/#contract-filters) when filt
 --exclude-tag foo --exclude-tag bar
 ```
 
-To specify an _empty_ exclude list, provide`--no-exclude-tags` instead of this option.
+To specify an empty exclude list, provide`--no-exclude-tags` instead of this option.
 
 Every tag name **must**:
 
@@ -177,7 +177,7 @@ One of `--hide-unreachable-types` or `--no-hide-unreachable-types` is **required
 </td>
 <td>
 
-If provided, the contract does _not_ automatically hide types that are unreachable from the contract schema's root fields.
+If provided, the contract doesn't automatically hide types that are unreachable from the contract schema's root fields.
 
 One of `--hide-unreachable-types` or `--no-hide-unreachable-types` is **required**.
 

docs/source/commands/dev.mdx

@@ -3,9 +3,7 @@ title: The Rover dev command
 description: Run your supergraph in your local dev environment
 ---
 
-> ⚠️ **Do not run `rover dev` in production!** This command is for local development _only_.
-
-A **supergraph** is an architecture consisting of multiple GraphQL APIs (**subgraphs**) and a **graph router** that runs in front of them:
+A _supergraph_ is an architecture consisting of multiple GraphQL APIs (_subgraphs_) and a _graph router_ that runs in front of them:
 
 ```mermaid
 graph LR;
@@ -22,6 +20,12 @@ graph LR;
 
 While you're making local changes to an individual subgraph, you can use the `rover dev` command to start a local router instance and test out the effects of those changes on your entire supergraph.
 
+<Caution>
+
+Don't run `rover dev` in production. It's for local development only.
+
+</Caution>
+
 Whenever you add, modify, or remove a subgraph from your local supergraph, Rover automatically re-composes your individual subgraph schemas into a unified supergraph schema, which your local router session automatically begins using.
 
 ## Starting a router session
@@ -34,20 +38,24 @@ Here's an example `rover dev` command that points to a locally running subgraph
 rover dev --name products --schema ./products.graphql --url http://localhost:4000
 ```
 
-> **You don't have to provide a _locally running_ subgraph!** You can point to _any_ GraphQL endpoint that your local environment can reach. You can even mix and match local and remote subgraphs, which is helpful for testing local changes against your staging subgraphs.
+<Note>
 
-**When you start your first `rover dev` process:**
+You don't have to provide a locally running subgraph. You can point to any GraphQL endpoint that your local environment can reach. You can even mix and match local and remote subgraphs, which is helpful for testing local changes against your staging subgraphs.
+
+</Note>
+
+When you start your first `rover dev` process:
 
 1. Rover obtains the subgraph schema you provide (via either introspection or file path).
 2. Rover composes a [supergraph schema](/federation/federated-types/overview/#supergraph-schema) from the subgraph schema.
 3. Rover starts a locally running [router](/router) session and provides it the supergraph schema.
 4. Rover starts watching the provided subgraph schema for changes (via either introspection or file), and it recomposes the supergraph schema whenever it detects a change. This automatically reloads the router.
 
-After you start a local router session with your first `rover dev` process, you can run _additional_ `rover dev` processes to [add subgraphs to the session.](#adding-a-subgraph-to-a-session)
+After you start a local router session with your first `rover dev` process, you can run additional `rover dev` processes to [add subgraphs to the session.](#adding-a-subgraph-to-a-session)
 
 ### Starting a session with multiple subgraphs
 
-If you have a standard set of subgraphs that you're always developing with, you can create a [supergraph config file](./supergraphs#yaml-configuration-file) to add _all_ of them to your local router session with a single `rover dev` command.
+If you have a standard set of subgraphs that you're always developing with, you can create a [supergraph config file](./supergraphs#yaml-configuration-file) to add all of them to your local router session with a single `rover dev` command.
 
 For example, this `supergraph.yaml` file provides the necessary details for two subgraphs:
 
@@ -74,35 +82,39 @@ You provide this file to `rover dev` like so:
 rover dev --supergraph-config supergraph.yaml
 ```
 
-If you do, a router session starts with _one_ of the subgraphs listed, then adds the remaining subgraphs one at a time (order is undefined). Because of this, you might observe composition errors during intermediate steps.
+If you do, a router session starts with one of the subgraphs listed, then adds the remaining subgraphs one at a time (order is undefined). Because of this, you might observe composition errors during intermediate steps.
 
-> Providing a `supergraph.yaml` file also enables you to take advantage of [other config options](./supergraphs#yaml-configuration-file), such as `introspection_headers`.
+Providing a `supergraph.yaml` file also enables you to take advantage of [other config options](./supergraphs#yaml-configuration-file), such as `introspection_headers`.
 
-If you start your session with a config file, you can still [add other subgraphs individually](#adding-a-subgraph-to-a-session). However, you _can't_ provide another config file.
+If you start your session with a config file, you can still [add other subgraphs individually](#adding-a-subgraph-to-a-session). However, you can't provide another config file.
 
 ## Adding a subgraph to a session
 
-After you start a router session with your first `rover dev` command, you can then add _other_ subgraphs to that same session.
+After you start a router session with your first `rover dev` command, you can then add other subgraphs to that same session.
 
-To add a subgraph, open a new terminal window and run `rover dev` _again_, this time providing the details of the subgraph to add. For example, this command adds a `users` subgraph:
+To add a subgraph, open a new terminal window and run `rover dev` again, this time providing the details of the subgraph to add. For example, this command adds a `users` subgraph:
 
 ```bash
 rover dev --name users --url http://localhost:4002
 ```
 
-Rover detects your _existing_ session and attaches this new process to it.
+Rover detects your existing session and attaches this new process to it.
+
+When you add a new subgraph to a session, Rover recomposes the supergraph schema and updates the router so you can query all added subgraphs via the single router endpoint.
+
+<Note>
 
-When you add a new subgraph to a session, Rover recomposes the supergraph schema and updates the router so you can query _all_ added subgraphs via the single router endpoint.
+Rover uses the port of the running router to identify an existing session. If you specify a custom port via `--supergraph-port` or `--router-config`, make sure to specify the same port for all `rover dev` processes that you want to attach to the same session.
 
-> ⚠️ **Rover uses the port of the running router to identify an existing session.** If you specify a custom port via `--supergraph-port` or `--router-config`, make sure to specify the _same_ port for all `rover dev` processes that you want to attach to the same session.
+</Note>
 
 ## Stopping a session
 
-If you stop your _initial_ `rover dev` process (by pressing `CTRL+C`), it shuts down the local router session. This also shuts down any _secondary_ `rover dev` processes attached to that same session.
+If you stop your initial `rover dev` process (by pressing `CTRL+C`), it shuts down the local router session. This also shuts down any secondary `rover dev` processes attached to that same session.
 
 ## Removing a subgraph
 
-If you stop a _secondary_ `rover dev` process (by pressing `CTRL+C`), its associated router session recomposes its supergraph schema _without_ the corresponding subgraph and reloads the router.
+If you stop a secondary `rover dev` process (by pressing `CTRL+C`), its associated router session recomposes its supergraph schema without the corresponding subgraph and reloads the router.
 
 ## Health check
 
@@ -116,7 +128,7 @@ Note that only the main `rover dev` process uses this router configuration file
 
 ### Enterprise features
 
-If you want to use [enterprise router features](/router/enterprise-features/), you _must_ provide both:
+If you want to use [enterprise router features](/router/enterprise-features/), you must provide both:
 
 1. A graph ref via the `APOLLO_GRAPH_REF` environment variable.
 2. A [**graph** API key](/graphos/api-keys/#graph-api-keys) either via the `APOLLO_KEY` environment or by [configuring credentials](./config#creating-configuration-profiles) in Rover.

docs/source/commands/explain.mdx

@@ -20,4 +20,4 @@ You can use the `rover explain` command to output the description for a particul
 rover explain E029
 ```
 
-Descriptions for _all_ Rover error codes are also available in [this article](../errors/).
+Descriptions for all Rover error codes are also available in [this article](../errors/).