Fix typos and grammar

changelog/2026-06-29-browser-extension-0-13-0.mdx

@@ -1,9 +1,9 @@
 ---
-title: "Browser Extension : Performance and bug fixes"
+title: "Browser Extension: Performance and bug fixes"
 description: "The Trunk browser extension 0.13.0 ships performance improvements and bug fixes."
-date: "null"
-category: "Browser Extension"
-type: "update"
+date: 2026-06-29
+category: Browser Extension
+type: update
 ---
 
 **Version 0.13.0 of the Trunk browser extension is now available with performance improvements and bug fixes.**

docs.json

@@ -624,7 +624,7 @@
               {
                 "group": "June",
                 "pages": [
-                  "changelog/2026-06-29-browser-extension-0-13-0.mdx",
+                  "changelog/2026-06-29-browser-extension-0-13-0",
                   "changelog/2026-06-18-merge-queue-stale-tab-refresh-fix",
                   "changelog/2026-06-17-flaky-tests-browser-extension-failure-details",
                   "changelog/2026-06-17-merge-queue-metrics-and-extension-updates",

flaky-tests/get-started/ci-providers/github-actions.mdx

@@ -132,7 +132,7 @@ You can quarantine flaky tests by wrapping the test command or as a follow-up st
 <Tabs>
 <Tab title="GitHub Actions Workflow">
 <Note>
-Using the Trunk Analytics Uploader Action in your GitHub Actions Workflow files, may need modifications to your workflow files to support quarantining.
+Using the Trunk Analytics Uploader Action in your GitHub Actions Workflow files may need modifications to your workflow files to support quarantining.
 
 If you upload your test results as a second step after you run your tests, **you need to add** `continue-on-error: true` **on your test step so your CI** job will continue even on failures.
 </Note>

flaky-tests/management/managing-detected-flaky-tests.mdx

@@ -44,7 +44,7 @@ Creating Linear or Jira tickets for detected flaky tests helps to integrate flak
 
 ### Step 3: Broadcast flakes
 
-It is important to keep the team informed on all status changes for flaky tests . This allows for fast follow-up when a test is marked as flaky.
+It is important to keep the team informed on all status changes for flaky tests. This allows for fast follow-up when a test is marked as flaky.
 
 * Use the [built-in Slack or Microsoft Teams webhook integrations](../webhooks/) to transform webhook payloads into messages.
 * Trunk's built-in templates help you get started and test the connection.

merge-queue/getting-started/configure-branch-protection.mdx

@@ -42,7 +42,7 @@ When a pull request enters the queue, Trunk creates a draft pull request to test
 Things to look out for:
 
 * This mode also creates a `trunk-merge/` branch
-* Trunk automatically closes the draft PRs and merge the original PRs
+* Trunk automatically closes the draft PRs and merges the original PRs
 
 **When to use a different approach:** If you have expensive preview deployments, review-only workflows, or security scans that you don't want running during merge queue testing, consider Push-triggered mode instead.
 

merge-queue/reference/common-problems.mdx

@@ -136,7 +136,7 @@ og:title: "Trunk Merge Queue FAQ"
   </Accordion>
 
   <Accordion title="Why do Dependabot and Renovate pull requests keep getting kicked from the queue?">
-    By default, both [dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates#changing-the-rebase-strategy-for-dependabot-pull-requests) and [renovate](https://docs.renovatebot.com/updating-rebasing/#updating-and-rebasing-branches) both will rebase their PRs whenever other PRs merge into their base branch. If that rebase happens when those PRs are in the queue, they will get kicked since they were updated. There are two ways to mitigate this:
+    By default, both [dependabot](https://docs.github.com/en/code-security/dependabot/working-with-dependabot/managing-pull-requests-for-dependency-updates#changing-the-rebase-strategy-for-dependabot-pull-requests) and [renovate](https://docs.renovatebot.com/updating-rebasing/#updating-and-rebasing-branches) will rebase their PRs whenever other PRs merge into their base branch. If that rebase happens when those PRs are in the queue, they will get kicked since they were updated. There are two ways to mitigate this:
 
     1. Both dependabot and renovate can be configured to not automatically rebase, while renovate can specifically be configured to only rebase if there's a merge conflict ([dependabot](https://docs.github.com/en/code-security/dependabot/dependabot-version-updates/configuration-options-for-the-dependabot.yml-file#rebase-strategy), [renovate](https://docs.renovatebot.com/configuration-options/#rebasewhen))
     2. Their PRs can be manually merged, and anything currently in the merge queue will restart with those merged changes