mintlify · mintlify · Apr 9, 2026
diff --git a/agent/workflows.mdx b/agent/workflows.mdx
@@ -73,7 +73,7 @@

 Review all changes since the last changelog update. Draft a new changelog post with any new features, bug fixes, or breaking changes.

 Include information about what changed and how it affects users.

 Do not include any internal-only information or minor changes like bumping package versions or updating documentation.

@@ -213,9 +213,9 @@

 ## Manage workflows

 If you create a workflow in the dashboard, edit or delete it from the dashboard.

 If you create a workflow from a file in your repository, edit or delete it with a pull request modifying the file.

 ### Trigger a workflow manually

@@ -236,7 +236,7 @@
 2. Click **View Workflows**.
 3. Click the toggle next to the workflow you want to disable or enable.
 
-When you re-enable a cron-based workflow, its next run time is recalculated from the current time.
+When you re-enable a cron-based workflow, the system recalculates the next run time from the current time.
 
 ## Prompts
 

diff --git a/api-playground/troubleshooting.mdx b/api-playground/troubleshooting.mdx
@@ -65,7 +65,7 @@ If your API pages aren't displaying correctly, check these common configuration
   <Accordion title="Requests from the API Playground don't work">
     If you have a custom domain configured, this could be an issue with your reverse proxy. By
     default, requests made via the API Playground start with a `POST` request to the
-    `/_mintlify/api/request` path on the docs site. If your reverse proxy is configured to only allow `GET`
+    `/_mintlify/api/request` path on the docs site. If you configure your reverse proxy to only allow `GET`
     requests, then all of these requests fail. To fix this, configure your reverse proxy to
     allow `POST` requests to the `/_mintlify/api/request` path.
 

diff --git a/cli/commands.mdx b/cli/commands.mdx
@@ -141,7 +141,7 @@
 | --- | --- |
 | `--page` | Filter conversations that reference a specific page in sources. |

 #### `mint analytics conversation view <conversation-id>`

 View a single conversation by ID. Use `mint analytics conversation list` to get IDs.

@@ -157,7 +157,7 @@
 mint analytics conversation buckets list
 ```

 #### `mint analytics conversation buckets view <bucket-id>`

 View conversations in a category bucket. Use `mint analytics conversation buckets list` to get IDs.

@@ -175,7 +175,7 @@
 mint config <subcommand> <key> [value]
 ```
 
-| Subcommand | Description |
+| subcommand | Description |
 | --- | --- |
 | `set <key> <value>` | Set a configuration value. |
 | `get <key>` | Display a configuration value. |
@@ -241,7 +241,7 @@
 | `--local-schema` | Allow validation of locally hosted OpenAPI files served over HTTP. Only supports HTTPS in production. |
 
 <Note>
-  The standalone `mint openapi-check` command is deprecated. Use `mint validate` instead.
+  Mintlify deprecated the standalone `mint openapi-check` command. Use `mint validate` instead.
 </Note>
 
 ---
@@ -327,7 +327,7 @@

 ## Telemetry

 The CLI collects anonymous usage telemetry to help improve Mintlify. Telemetry data includes the command name, CLI version, operating system, and architecture. Mintlify does **not** collect personally identifiable information, project content, or file paths.

 By default, the CLI collects telemetry data. You can opt out at any time using the `--telemetry` flag:


diff --git a/cli/preview.mdx b/cli/preview.mdx
@@ -34,7 +34,7 @@ You must authenticate the CLI with your Mintlify account to enable search and th
 mint login
 ```
 
-After you authenticate with the `mint login` command, the CLI stores your credentials in `~/.config/mintlify/config.json` so you stay logged in across sessions. The CLI also prompts you to select a default project, which is used for commands like `mint analytics`.
+After you authenticate with the `mint login` command, the CLI stores your credentials in `~/.config/mintlify/config.json` so you stay logged in across sessions. The CLI also prompts you to select a default project, which commands like `mint analytics` use.
 
 Once logged in, run `mint dev` to start the local preview with search and the assistant enabled. The assistant uses the same indexed content as your deployed documentation site.
 

diff --git a/components/fields.mdx b/components/fields.mdx
@@ -8,7 +8,7 @@ Use fields to document API parameters and responses. There are two types of fiel
 
 ## Parameter field
 
-The `<ParamField>` component is used to define parameters for your APIs or SDKs. Adding a `ParamField` automatically adds an [API Playground](/api-playground/overview).
+Use the `<ParamField>` component to define parameters for your APIs or SDKs. Adding a `ParamField` automatically adds an [API Playground](/api-playground/overview).
 
 <ParamField path="param" type="string" required>
   An example of a parameter field
@@ -32,16 +32,16 @@ The `<ParamField>` component is used to define parameters for your APIs or SDKs.
 
   Supports `number`, `string`, `boolean`, `object`.
 
-Arrays can be defined using the `[]` suffix. For example `string[]`.
+Define arrays using the `[]` suffix. For example `string[]`.
 
 </ParamField>
 
 <ParamField body="required" type="boolean">
-  Indicate whether the parameter is required.
+  Indicate whether you require the parameter.
 </ParamField>
 
 <ParamField body="deprecated" type="boolean">
-  Indicate whether the parameter is deprecated.
+  Indicate whether you have deprecated the parameter.
 </ParamField>
 
 <ParamField body="default" type="any">
@@ -85,17 +85,17 @@ The `<ResponseField>` component defines the return values of an API.
 </ResponseField>
 
 <ResponseField name="required" type="boolean">
-  Indicate whether the response is required.
+  Indicate whether you require the response.
 </ResponseField>
 
 <ResponseField name="deprecated" type="boolean">
-  Whether a field is deprecated.
+  Whether you have deprecated a field.
 </ResponseField>
 
 <ResponseField name="pre" type="string[]">
-  Labels that are shown before the name of the field.
+  Labels that appear before the name of the field.
 </ResponseField>
 
 <ResponseField name="post" type="string[]">
-  Labels that are shown after the name of the field.
+  Labels that appear after the name of the field.
 </ResponseField>
diff --git a/components/responses.mdx b/components/responses.mdx
@@ -35,15 +35,15 @@ Use the `<ResponseField>` component to define the return values of an API. Many
 </ResponseField>
 
 <ResponseField name="deprecated" type="boolean">
-  Whether a field is deprecated or not.
+  Whether you have deprecated a field or not.
 </ResponseField>
 
 <ResponseField name="pre" type="string[]">
-  Labels that are shown before the name of the field
+  Labels that appear before the name of the field
 </ResponseField>
 
 <ResponseField name="post" type="string[]">
-  Labels that are shown after the name of the field
+  Labels that appear after the name of the field
 </ResponseField>
 
 <RequestExample>

diff --git a/components/tooltips.mdx b/components/tooltips.mdx
@@ -19,7 +19,7 @@ Use tooltips to provide additional context or definitions when a user hovers ove
 </ResponseField>
 
 <ResponseField name="headline" type="string">
-  Text displayed above the `tip` text.
+  Text displayed preceding the `tip` text.
 </ResponseField>
 
 <ResponseField name="cta" type="string">

diff --git a/deploy/ci.mdx b/deploy/ci.mdx
@@ -15,7 +15,7 @@ Use CI checks to lint your docs for errors and provide warnings before you deplo
 To begin, follow the steps on the [GitHub](/deploy/github) page.
 
 <Tip>
-  Only access to the repository where your documentation content exists is required, so it is highly recommended to only grant access to that repository. 
+  You only need access to the repository where your documentation content exists, so we highly recommend granting access to that repository only. 
 </Tip>
 
 ## Configuration
@@ -357,8 +357,8 @@ toc
 
 To add your own vocabulary for the default configuration, create a `styles/config/vocabularies/Mintlify` directory with `accept.txt` and `reject.txt` files.
 
-- `accept.txt`: Words that should be ignored by the Vale linter. For example, product names or uncommon terms.
-- `reject.txt`: Words that should be flagged as errors. For example, jargon or words that are not appropriate for the tone of your documentation.
+- `accept.txt`: Words that the Vale linter should ignore. For example, product names or uncommon terms.
+- `reject.txt`: Words that the Vale linter should flag as errors. For example, jargon or words that are not appropriate for the tone of your documentation.
 
 ```text Example Vale file structure
 /your-project
@@ -396,7 +396,7 @@ Use relative paths and include the `stylesPath` in your repository.
 </Note>
 
 #### Packages
-Vale supports a range of [packages](https://vale.sh/docs/keys/packages), which can be used to check for spelling and style errors. Any packages you include in your repository under the correct `stylesPath` are automatically installed and used in your Vale configuration.
+Vale supports a range of [packages](https://vale.sh/docs/keys/packages) that check for spelling and style errors. Any packages you include in your repository under the correct `stylesPath` automatically install and run with your Vale configuration.
 
 For packages not included in your repository, you may specify any packages from the [Vale package registry](https://vale.sh/explorer), and they're automatically downloaded and used in your Vale configuration.
 
@@ -415,12 +415,12 @@ To use Vale's in-document comments in MDX files, use MDX-style comments `{/* ...
 ```mdx
 {/* vale off */}
 
-This text is ignored by Vale
+Vale ignores this text
 
 {/* vale on */}
 ```
 
-Vale automatically recognizes and respects these comments in MDX files without additional configuration. Use comments to skip lines or sections that should be ignored by the linter.
+Vale automatically recognizes and respects these comments in MDX files without additional configuration. Use comments to skip lines or sections that you want the linter to ignore.
 
 <Warning>
   Do not place `{/* vale off */}` or similar MDX expression comments as direct children of a JSX component between sibling elements. For example, between two `<Step>` elements inside a `<Steps>` component.

diff --git a/guides/configure-automerge.mdx b/guides/configure-automerge.mdx
@@ -5,7 +5,7 @@
 keywords: ["automerge", "ruleset", "branch protection", "bypass"]
 ---
 
-Add the Mintlify GitHub App to a ruleset's bypass list so that the app can create and merge pull requests without being blocked by review and status check requirements. This allows you to configure [workflows](/guides/automate-agent) to automatically merge changes to `main`.
+Add the Mintlify GitHub App to a ruleset's bypass list so that the app can create and merge pull requests without review and status check requirements blocking it. This allows you to configure [workflows](/guides/automate-agent) to automatically merge changes to `main`.
 
 <Note>
   The Mintlify GitHub App must have bypass permissions on **every** ruleset that targets your deploy branch, including rulesets defined at the organization level and the repository level. If any ruleset is missing the bypass entry, the workflow creates a PR, but does not merge it.
@@ -23,8 +23,8 @@

 <Steps>
  <Step title="Navigate to rulesets">
    - **Repository rulesets**: On GitHub, go to your repository's **Settings** -> **Rules** -> **Rulesets**.
    - **Organization rulesets**: Go to your organization's **Settings** -> **Rules** -> **Rulesets**.
  </Step>
  <Step title="Select the ruleset">
    Click a ruleset that targets your deploy branch, which is usually `main`.
@@ -44,5 +44,5 @@
 
 ## Verify the setup
 
-1. **For contributors**: Open a PR targeting `main`. Confirm that it still requires approval and passing status checks before the merge button is enabled.
+1. **For contributors**: Open a PR targeting `main`. Confirm that it still requires approval and passing status checks before you can merge.
 2. **For workflows**: Trigger a workflow with automerge enabled. Confirm that the workflow runs and successfully merges a PR.
diff --git a/organize/navigation.mdx b/organize/navigation.mdx
@@ -1,6 +1,6 @@
 ---
 title: "Navigation"
 description: "Configure your documentation site navigation with groups, pages, dropdowns, tabs, and anchors in docs.json to build a sidebar structure."
 keywords: ["navigation structure", "sidebar configuration", "page organization", "navigation groups"]
 ---

@@ -120,11 +120,11 @@
 
 Use the `expanded` property to control the default state of a nested group in the navigation sidebar.
 
-- `expanded: true`: Group is expanded by default.
-- `expanded: false` or omitted: Group is collapsed by default.
+- `expanded: true`: Expands the group by default.
+- `expanded: false` or omitted: Collapses the group by default.
 
 <Note>
-  The `expanded` property only affects nested groups--groups within groups. Top-level groups are always expanded and cannot be collapsed.
+  The `expanded` property only affects nested groups--groups within groups. Top-level groups always expand and you cannot collapse them.
 </Note>
 
 ```json
@@ -380,9 +380,9 @@
 }
 ```

 ## Dropdowns

 Dropdowns are an expandable menu at the top of your sidebar navigation. Each item in a dropdown directs to a section of your documentation.

 <img
  className="block dark:hidden pointer-events-none"
@@ -951,9 +951,9 @@

 </CodeGroup>

 ## Breadcrumbs

 Breadcrumbs display the full navigation path at the top of pages. Some themes have breadcrumbs enabled by default and others do not. You can control whether breadcrumbs display on your site using the `styling` property in your `docs.json`.

 <CodeGroup>


diff --git a/status.mdx b/status.mdx
@@ -17,7 +17,7 @@ The status page displays the operational status of:
 
 ## Subscribing to updates
 
-Subscribe to receive notifications when incidents are detected, incidents are resolved, and when scheduled maintenance is planned.
+Subscribe to receive notifications when we detect incidents, resolve incidents, and plan scheduled maintenance.
 
 1. Navigate to [status.mintlify.com](https://status.mintlify.com).
 2. Click **Subscribe to updates**.