testdriverai 5.6.3 → 5.6.5

package/docs/{guide/lifecycle.mdx → action/pre-post-scripts.mdx}

@@ -5,66 +5,69 @@ description: "How to handle pre and post test tasks."
 icon: "hammer"
 ---
 
-## Pre-run Configuration
-
-If a file is found at `testdriver/lifecycle/prerun.yaml`, it's executed before the test begins. This file works like any other TestDriver file and is commonly used to perform tasks such as opening a browser, navigating to a specific page, or resetting the application state.
-
-For example, the `prerun.yaml` file can be used to open the Chrome browser and navigate to a page, similar to the example provided above. This ensures that the test environment is properly set up before the test starts.
-
-### Example
-
-Here is an example of a `prerun.yaml` file:
-
-```yaml
-version: 5.1.1
-steps:
-  - prompt: launch chrome
-    commands:
-      - command: exec
-        lang: shell
-        linux: |
-          jumpapp google-chrome --disable-fre --no-default-browser-check --no-first-run "${TD_WEBSITE}" &
-          exit
-        mac: |
-          open -na "Google Chrome" --args --disable-fre --no-default-browser-check --no-first-run --disable-features=PasswordManagerEnabled "${TD_WEBSITE}" &
-          exit
-        windows:
-          Start-Process "C:/Program Files/Google/Chrome/Application/chrome.exe" -ArgumentList "--start-maximized", "${TD_WEBSITE}"
-          exit
-      - command: wait-for-text
-        text: "Google Chrome"
-        timeout: 30000
-```
+## Overview
+Prerun scripts are commands executed on a TestDriver virtual machine (VM) before each test in a CI/CD pipeline. They are used to prepare the environment by provisioning the VM, installing dependencies, configuring settings, or building the application. This ensures a consistent and reproducible environment for every test execution.
 
+By using prerun scripts, you can:
+- Speed up test setup.
+- Prevent test failures caused by inconsistent environments.
+- Promote reproducible builds for reliable test results.
 
-### Notes
+---
 
-- Currently, there is no teardown task implemented. However, when running on GitHub Actions, the virtual machine (VM) is ephemeral, meaning everything is destroyed after the test run.
+## Use cases
+Prerun scripts are ideal for:
+- Installing necessary dependencies (for example, browsers, libraries, or tools).
+- Building your application or running setup scripts.
+- Configuring the VM to match specific test requirements.
+- Preparing staging environments or accessing private resources.
 
+---
 
-## Advanced Configuration
-If you need to perform more complex setup or teardown tasks, you can use the `lifecycle` folder in your repository. This folder can contain multiple files, each with a specific purpose.
+## Example: Installing Arc Browser
+The following example demonstrates how to use a prerun script within the GitHub Actions workflow folder to download and install the Arc Browser on a Windows VM before running tests. 
 
-## Workflow Overview
+<Warning>Note this will be deprecated in favor of [lifecycle prerun scripts](/guide/lifecycle-prerun) from `v5` onward.</Warning>
 
-1. **Setup Tasks**:
-   - Use a dedicated action **before** the TestDriver action to prepare the environment (e.g., create a test user via an API).
-   - Pass the created user credentials to the TestDriver action using environment variables.
+```yaml ./github/workflows/testdriver.yaml
+# Permissions and other setup here
 
-2. **Run Tests**:
-   - Execute the tests using TestDriver, leveraging the setup data (e.g., the test user).
-
-3. **Teardown Tasks**:
-   - Use a dedicated action **after** the TestDriver action to clean up (e.g., delete the test user).
-   - Ensure the teardown step runs **no matter the result** of the TestDriver action.
+jobs:
+  test:
+    name: "TestDriver"
+    runs-on: ubuntu-latest
+    steps:
+      # Use the TestDriver GitHub Action
+      - uses: testdriverai/action@main
+        with:
+          prerun: |
+            # Get the IPv6 address of the VM
+            Get-NetIPAddress -AddressFamily IPv6
+            # URL for the Arc browser installer
+            $installerUrl = "https://releases.arc.net/windows/ArcInstaller.exe"
+            # Location to save the installer
+            $installerPath = "$env:USERPROFILE\Downloads\ArcInstaller.exe"
+            # Download the Arc browser installer
+            Write-Host "Downloading Arc browser installer..."
+            Invoke-WebRequest -Uri $installerUrl -OutFile $installerPath
+            # Check if the download was successful
+            if (Test-Path $installerPath) {
+                Write-Host "Download successful. Running the installer..."
+                Start-Process -FilePath $installerPath -ArgumentList '/silent' -Wait
+                Start-Sleep -Seconds 10
+            } else {
+                Write-Host "Failed to download the Arc browser installer."
+            }
+```
 
 ---
 
-## Example Workflow with Advanced Setup and Teardown
 
-### Workflow File: `.github/workflows/testdriver-setup-teardown.yml`
+## Example workflow with advanced setup and teardown
+
+### Workflow file
 
-```yaml
+```yaml .github/workflows/testdriver-setup-teardown.yaml  [expandable]
 name: TestDriver with Setup and Teardown
 
 on:
@@ -83,7 +86,7 @@ jobs:
       - name: Check out repository
         uses: actions/checkout@v2
 
-      # Step 2: Setup - Create a test user via API
+      # Step 2: Setup - create a test user via API
       - name: Setup Test User
         id: setup-user
         run: |
@@ -95,7 +98,7 @@ jobs:
         env:
           API_KEY: ${{ secrets.API_KEY }}
 
-      # Step 3: Run Tests with TestDriver
+      # Step 3: Run tests with TestDriver
       - name: Run Tests with TestDriver
         uses: testdriverai/action@main
         with:
@@ -113,7 +116,7 @@ jobs:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           FORCE_COLOR: "3"
 
-      # Step 4: Teardown - Delete the test user
+      # Step 4: Teardown - delete the test user
       - name: Teardown Test User
         if: always()
         run: |
@@ -127,9 +130,23 @@ jobs:
 
 ---
 
-## Workflow Steps Explained
+## Workflow overview
 
-### 1. **Setup Test User**
+1. **Setup Tasks**:
+   - Use a dedicated action **before** the TestDriver action to prepare the environment (for example, create a test user via an API).
+   - Pass the created user credentials to the TestDriver action using environment variables.
+
+2. **Run Tests**:
+   - Execute the tests using TestDriver, leveraging the setup data (for example, the test user).
+
+3. **Teardown Tasks**:
+   - Use a dedicated action **after** the TestDriver action to clean up (for example, delete the test user).
+   - Ensure the teardown step runs **no matter the result** of the TestDriver action.
+
+### Workflow steps explained
+
+<Steps>
+<Step title="Setup test user">
 - **Purpose**: Create a test user via an API before running the tests.
 - **How It Works**:
   - The `Setup Test User` step sends a `POST` request to the API to create a new user.
@@ -138,35 +155,32 @@ jobs:
   - `USER_ID`: `12345`
   - `USER_EMAIL`: `test@example.com`
   - `USER_PASSWORD`: `password123`
-
----
-
-### 2. **Run Tests with TestDriver**
+</Step>
+<Step title="Run tests with TestDriver">
 - **Purpose**: Execute tests using the TestDriver action.
 - **How It Works**:
   - The `USER_EMAIL` and `USER_PASSWORD` environment variables are passed to the `prerun` script.
   - The test prompts use these credentials to log in and perform actions.
-
----
-
-### 3. **Teardown Test User**
+</Step>
+<Step title="Teardown test user">
 - **Purpose**: Delete the test user via an API after the tests are complete.
 - **How It Works**:
   - The `Teardown Test User` step sends a `DELETE` request to the API to remove the test user.
   - The `if: always()` condition ensures this step runs even if the TestDriver action fails.
-
+</Step>
+</Steps>
 ---
 
-## Best Practices for Setup and Teardown
+## Best practices for setup and teardown
 
 1. **Use APIs for Setup and Teardown**:
    - Use APIs to create and delete test data dynamically, ensuring a clean environment for each test run.
 
 2. **Pass Data via Environment Variables**:
-   - Store setup data (e.g., user credentials) in environment variables and pass them to the TestDriver action.
+   - Store setup data (for example, user credentials) in environment variables and pass them to the TestDriver action.
 
 3. **Ensure Teardown Always Runs**:
-   - Use `if: always()` to ensure teardown tasks are executed regardless of the test results.
+   - Use [`if: always()`](https://docs.github.com/en/actions/writing-workflows/choosing-what-your-workflow-does/evaluate-expressions-in-workflows-and-actions) to ensure teardown tasks are executed regardless of the test results.
 
 4. **Log Setup and Teardown Steps**:
    - Add `echo` statements to log the progress of setup and teardown tasks for easier debugging.
@@ -176,20 +190,24 @@ jobs:
 
 ---
 
-## Example Use Cases
+## Advanced configuration
+If you need to perform more complex setup or teardown tasks, you can use the [`lifecycle`](/guide/lifecycle-prerun) folder in your repository. This folder can contain multiple files, each with a specific purpose.
+
+## Example use cases
 
-### 1. **User Management**
+### 1. **User management**
 - Create a test user during setup.
 - Delete the test user during teardown.
 
-### 2. **Database Operations**
+### 2. **Database operations**
 - Insert test data into a database during setup.
 - Remove the test data during teardown.
 
-### 3. **Mock Services**
+### 3. **Mock services**
 - Start a mock API server during setup.
 - Stop the mock server during teardown.
 
 ---
 
-By structuring your workflow to handle **setup** before the TestDriver action and **teardown** after it, you can ensure a clean and reliable test environment for every run. This approach also ensures that teardown tasks are executed regardless of the test results, maintaining a consistent state for subsequent runs.
+## Conclusion
+By structuring your GitHub Actions workflow to handle **setup** before the TestDriver action and **teardown** after it, you can ensure a clean and reliable test environment for every run. This approach also ensures that teardown tasks are executed regardless of the test results, maintaining a consistent state for subsequent runs.

package/docs/action/secrets.mdx

@@ -10,17 +10,17 @@ When using TestDriver to test your application, you may need to securely store a
 
 ---
 
-## Why Use Secrets?
+## Why use secrets?
 - **Security**: Secrets are encrypted and stored securely in your GitHub repository.
 - **Masking**: TestDriver automatically masks secrets in all test output, including debugging logs.
 - **Reusability**: Secrets can be reused across multiple workflows and test files.
 
 ---
 
-## Step 1: Replace Hardcoded Secrets in Test Files
+## Step 1: Replace hardcoded secrets in test files
 To securely use secrets in your TestDriver test files, replace hardcoded values with placeholders in the format `${TD_YOUR_SECRET}`. TestDriver will parse and mask any secrets that begin with `TD_`.
 
-### Example Test File
+### Example test file
 ```yaml
 version: 4.1.35
 steps:
@@ -48,21 +48,21 @@ steps:
 
 ---
 
-## Step 2: Add Secrets to Your GitHub Repository
+## Step 2: Add secrets to Your GitHub repository
 1. Navigate to your GitHub repository.
 2. Go to **Settings** > **Secrets and variables** > **Actions**.
 3. Click **New repository secret**.
-4. Add your secrets (e.g., `TD_USERNAME`, `TD_PASSWORD`, `TD_API_KEY`).
+4. Add your secrets (for example, `TD_USERNAME`, `TD_PASSWORD`, `TD_API_KEY`).
 
 For detailed instructions, refer to the [GitHub Docs on using secrets](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
 
 ---
 
-## Step 3: Supply Secrets to GitHub Actions
+## Step 3: Supply secrets to GitHub Actions
 When running TestDriver tests via GitHub Actions, supply your secrets in the `env` section of the workflow file.
 
-### Example Workflow
-```yaml
+### Example workflow
+```yaml .github/workflows/testdriver.yaml
 name: TestDriver Test
 
 permissions:
@@ -80,7 +80,7 @@ jobs:
         with:
           key: ${{ secrets.TD_API_KEY }}
           prompt: | 
-            1. /run tests/signin.yml
+            1. /run tests/signin.yaml
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           TD_USERNAME: ${{ secrets.TD_USERNAME }}
@@ -89,8 +89,8 @@ jobs:
 
 ---
 
-## Best Practices
-- **Use Descriptive Names**: Name your secrets clearly (e.g., `TD_USERNAME`, `TD_PASSWORD`) to make them easy to identify.
+## Best practices
+- **Use Descriptive Names**: Name your secrets clearly (for example, `TD_USERNAME`, `TD_PASSWORD`) to make them easy to identify.
 - **Rotate Secrets Regularly**: Update your secrets periodically to enhance security.
 - **Limit Access**: Only provide access to secrets for workflows and team members that require them.
 - **Mask Secrets**: Ensure all secrets are masked in logs by using the `TD_` prefix.

package/docs/action/setup.mdx

@@ -17,7 +17,7 @@ TestDriver Cloud Testing is performed via the TestDriver GitHub Action. You can
 
 ---
 
-## Step 2: Get Your API Key
+## Step 2: Get Your API key
 To execute TestDriver actions on our virtual machines, you'll need an API key. Follow these steps to retrieve and configure your API key:
 
 1. **Upgrade Your Account**: Ensure you have a paid TestDriver account.
@@ -29,8 +29,8 @@ To execute TestDriver actions on our virtual machines, you'll need an API key. F
 
 ---
 
-## Step 3: Create Your Workflow
-Now it's time to create your first TestDriver workflow. Add the following configuration to `.github/workflows/testdriver.yml`:
+## Step 3: Create your workflow
+Now it's time to create your first TestDriver workflow. Add the following configuration to `.github/workflows/testdriver.yaml`:
 
 ```yaml
 name: TestDriver
@@ -67,14 +67,14 @@ jobs:
           FORCE_COLOR: "3"
 ```
 
-### Key Points:
-- **Trigger Conditions**: The `on` section defines when the workflow runs (e.g., pull requests, scheduled events, or manual triggers).
+### Key points:
+- **Trigger Conditions**: The `on` section defines when the workflow runs (for example, pull requests, scheduled events, or manual triggers).
 - **API Key**: The `key` field uses the `TD_API_KEY` secret for authentication.
 - **Prompt**: The `prompt` field specifies the commands to execute. In this example, the `/run` command is used to execute a test file from the repository.
 
 ---
 
-## Step 4: Deploy the Workflow
+## Step 4: Deploy the workflow
 Save the workflow file, create a new branch, and push it to your repository. Then, create a pull request to trigger the workflow.
 
 ```bash
@@ -86,7 +86,7 @@ gh pr create --web
 
 ---
 
-## How It Works
+## How it works
 1. **Trigger**: The GitHub Action is triggered based on the conditions defined in the `on` section.
 2. **Authentication**: The `key` value authenticates your account.
 3. **VM Setup**: An ephemeral virtual machine is spawned on TestDriver's infrastructure.
@@ -99,7 +99,7 @@ gh pr create --web
 
 ---
 
-## Additional Features
+## Additional features
 - **Dynamic Prompts**: You can use commands like `/explore`, supply variables, or dynamically generate prompts from earlier steps.
 - **Staging Workflows**: A common workflow involves waiting for staging to deploy before executing tests.
 

package/docs/apps/chrome-extensions.mdx

@@ -1,5 +1,5 @@
 ---
-title: Testing Chrome Extensions with TestDriver
+title: Using TestDriver with Chrome Extensions
 sidebarTitle: "Chrome Extensions"
 description: "Test Chrome extensions with TestDriver"
 icon: "puzzle-piece"
@@ -7,17 +7,17 @@ icon: "puzzle-piece"
 
 import TestPrereqs from '/snippets/test-prereqs.mdx'
 
-# Testing Chrome Extensions with TestDriver
+# Testing Chrome extensions with TestDriver
 TestDriver can be used to test Chrome extensions. This guide provides an overview of how to set up and run tests for your Chrome extension using TestDriver.
 
 <TestPrereqs />
 
-## How Do I Test Chrome Extensions?
+## How do I test Chrome extensions?
 TestDriver provides a powerful solution for testing Chrome extensions. With our platform, you can easily create and run tests to ensure your extension functions as expected across different browsers and operating systems.
-## Getting Started
-You can test a preinstalled extension or test by installing an extension. If the extension is in developemt mode, turn this on by checking the "Developer mode" checkbox in the Chrome extensions page. From there you can load the unpacked extension by selecting the folder where your extension is located. To download the files onto the VM if you are performing a test on cloud hosted runners, see the [Lifecycle](/guide/lifecycle) or [Prerun](/action/prerun) docs.
+## Getting started
+You can test a preinstalled extension or test by installing an extension. If the extension is in development mode, turn this on by checking the "Developer mode" checkbox in the Chrome extensions page. From there you can load the unpacked extension by selecting the folder where your extension is located. To download the files onto the VM if you are performing a test on cloud hosted runners, see the [Lifecycle](/guide/lifecycle-prerun) and [Prerun](/action/pre-post-scripts) docs.
 
-## Sample Test Steps
+## Sample test steps
 1. Load a the Chrome Web Store.
 2. Search for the extension you want to test.
 3. Click on the extension to open its details page.
@@ -26,7 +26,7 @@ You can test a preinstalled extension or test by installing an extension. If the
 6. Click the 'puzzle piece' icon to pin the extension to the toolbar.
 7. Click on the extension icon to open it.
 
-## TestDriver in Action
+## TestDriver in action
 <iframe
   width="560"
   height="315"
@@ -37,5 +37,5 @@ You can test a preinstalled extension or test by installing an extension. If the
   allowfullscreen
 ></iframe>
 
-## Now What?
-Once you have insstalled your extension, simply create a TestDriver test to test any functionality a user would use. 
+## Now what?
+Once you have installed your extension, simply create a TestDriver test to test any functionality a user would use. 

package/docs/apps/desktop-apps.mdx

@@ -11,9 +11,9 @@ TestDriver is designed to work with any desktop application, including Electron,
 
 <TestPrereqs />
 
-## Sample Test Steps
+## Sample test steps
 
-## TestDriver in Action
+## TestDriver in action
 <iframe
   width="560"
   height="315"
@@ -24,7 +24,7 @@ TestDriver is designed to work with any desktop application, including Electron,
   allowfullscreen
 ></iframe>
 
-## Supported Desktop Applications
+## Supported desktop applications
 TestDriver supports a wide range of desktop applications, including:
 - Electron apps
 - Java apps
@@ -33,11 +33,13 @@ TestDriver supports a wide range of desktop applications, including:
 - Native Mac applications
 - Native Linux applications
 - Any other desktop application that can be run on Windows, Mac, or Linux
+
+---
+
 ## Installation
 To use TestDriver with desktop applications, no special setup is needed. Simply run the local agent to interact with applications on your local machine, or add instructions to `prerun.yaml` to tell the runner to launch or install the application. Here is an example that performs a calculation on a calculator app:
 ```yaml
 version: 5.5.5
-session: 67f00511acbd9ccac373edf7
 steps:
   - prompt: launch a calculator
     commands:
@@ -61,7 +63,6 @@ steps:
 A `calculator_test.yaml` file might look like this:
 ```yaml
 version: 5.5.5
-session: 6810141e0e064b42739922f2
 steps:
   - prompt: /try performing the operation 2 + 2 = on the calculator that is opened
     commands:

package/docs/apps/mobile-apps.mdx

@@ -4,16 +4,16 @@ sidebarTitle: "Mobile Apps"
 description: "Test mobile apps with TestDriver"
 icon: "mobile"
 ---
-# Testing Mobile Apps with TestDriver
+# Testing mobile apps with TestDriver
 
-## How Do I Test Mobile Apps?
+## How do I test mobile apps?
 TestDriver provides a powerful solution for testing mobile apps. With our platform, you can easily create and run tests to ensure your mobile app functions as expected across different devices and operating systems.
 
 
 
 <Tip>You will need to install a mobile emulator for your deployed tests or use a device farm to test your mobile app.</Tip>
 
-## 
+## Gettins started
 To get started with testing mobile apps using TestDriver, follow these steps:
 1. **Follow our [quick start guide](/overview/quickstart) to set up your TestDriver account.**
 2. **Create a new test project** in your TestDriver dashboard.

package/docs/apps/static-websites.mdx

@@ -6,7 +6,7 @@ icon: "browser"
 ---
 TestDriver provides a powerful solution for testing static websites. With our platform, you can easily create and run tests to ensure your static website functions as expected across different browsers and devices.
 
-## TestDriver in Action
+## TestDriver in action
 <iframe
   width="560"
   height="315"
@@ -17,7 +17,7 @@ TestDriver provides a powerful solution for testing static websites. With our pl
   allowfullscreen
 ></iframe>
 
-## Getting Started
+## Getting started
 To get started with testing static websites using TestDriver, follow these steps:
 1. **Follow our [quick start guide](/getting-started/setup) to set up your TestDriver account.**
 2. **Create a new test project** in your TestDriver dashboard.
@@ -26,7 +26,6 @@ It looks like this in the `prerun.yaml` file:
 
 ```yaml
 version: 5.1.1
-session: 67f00511acbd9ccac373edf7
 steps:
   - prompt: launch chrome
     commands:

package/docs/bugs/jira.mdx

@@ -5,13 +5,13 @@ description: "Step-by-step instructions to integrate TestDriver with Jira for au
 icon: "jira"
 ---
 
-# Automating Jira Ticket Creation for Test Failures Using TestDriver and Jira GitHub Actions
+# Automating Jira ticket creation for test failures using TestDriver and Jira GitHub Actions
 
 This guide explains how to integrate the **TestDriver GitHub Action** with the **Jira GitHub Action** to automatically create a Jira ticket whenever a TestDriver test fails. This workflow ensures that test failures are tracked in Jira, enabling teams to address issues promptly.
 
 ---
 
-## Workflow Overview
+## Workflow overview
 
 <Steps>
 <Step title="Run Tests with TestDriver">Use the TestDriver GitHub Action to execute your test suite.</Step>
@@ -22,19 +22,19 @@ This guide explains how to integrate the **TestDriver GitHub Action** with the *
 
 ## Prerequisites
 
-1. **TestDriver API Key**: Store your API key as a GitHub secret (e.g., `TD_API_KEY`).
-2. **Jira API Token**: Generate an API token from your Jira account and store it as a GitHub secret (e.g., `JIRA_API_TOKEN`).
-3. **Jira Base URL**: Your Jira instance URL (e.g., `https://yourcompany.atlassian.net`).
-4. **Jira Project Key**: The key of the Jira project where tickets will be created (e.g., `TEST`).
+1. **TestDriver API Key**: Store your API key as a GitHub secret (for example, `TD_API_KEY`).
+2. **Jira API Token**: Generate an API token from your Jira account and store it as a GitHub secret (for example, `JIRA_API_TOKEN`).
+3. **Jira Base URL**: Your Jira instance URL (for example, `https://yourcompany.atlassian.net`).
+4. **Jira Project Key**: The key of the Jira project where tickets will be created (for example, `TEST`).
 
 ---
 
-## GitHub Actions Workflow
+## GitHub Actions workflow
 
 Here's a complete workflow that integrates TestDriver and Jira:
 
-### Workflow File: `.github/workflows/testdriver-jira.yml`
-```yaml
+### Workflow File: `.github/workflows/testdriver-jira.yaml`
+```yaml [expandable]
 name: TestDriver with Jira Integration
 
 on:
@@ -104,7 +104,7 @@ jobs:
 
 ---
 
-## Workflow Steps Explained
+## Workflow steps explained
 
 ### 1. **Run Tests with TestDriver**
 The `testdriverai/action@main` step runs your TestDriver tests and captures the results. The `outputs.success` variable indicates whether the tests passed or failed.
@@ -124,7 +124,7 @@ The `testdriverai/action@main` step runs your TestDriver tests and captures the
 
 ---
 
-### 2. **Check for Test Failures**
+### 2. **Check for test failures**
 This step checks the `outputs.success` variable from the TestDriver action. If the tests failed, it sets an environment variable (`failure=true`) to trigger the Jira ticket creation step.
 ```yaml
 - name: Check for Test Failures
@@ -142,7 +142,7 @@ This step checks the `outputs.success` variable from the TestDriver action. If t
 
 ---
 
-### 3. **Create a Jira Ticket**
+### 3. **Create a Jira ticket**
 If any tests failed, the `create-jira-ticket` job uses the `atlassian/gajira-create` action to create a new Jira ticket. The ticket includes:
 - **Summary**: A brief description of the failure.
 - **Description**: Detailed information about the failure, including the test summary and markdown output from TestDriver.
@@ -171,17 +171,17 @@ If any tests failed, the `create-jira-ticket` job uses the `atlassian/gajira-cre
 
 ---
 
-## Secrets Configuration
+## Secrets configuration
 
 Add the following secrets to your GitHub repository:
 1. **`TD_API_KEY`**: Your TestDriver API key.
 2. **`JIRA_API_TOKEN`**: Your Jira API token.
-3. **`JIRA_BASE_URL`**: Your Jira instance URL (e.g., `https://yourcompany.atlassian.net`).
+3. **`JIRA_BASE_URL`**: Your Jira instance URL (for example, `https://yourcompany.atlassian.net`).
 4. **`JIRA_USERNAME`**: Your Jira account email.
 
 ---
 
-## Example Jira Ticket
+## Example Jira ticket
 
 ### Summary:
 `Test Failure: Login Test Failed`
@@ -204,7 +204,7 @@ Please investigate the issue and resolve it promptly.
 ```
 ---
 
-## Benefits of This Workflow
+## Benefits of this workflow
 
 1. **Automated Issue Tracking**: Automatically creates Jira tickets for test failures, ensuring no issues are overlooked.
 2. **Detailed Context**: Includes test summaries and failure details in the Jira ticket for easier debugging.

package/docs/cli/overview.mdx

@@ -12,7 +12,7 @@ The `testdriverai` CLI is the primary interface for running, managing, and debug
 testdriverai <command> [options]
 ```
 
-## Available Commands
+## Available commands
 | Command       | Description                                                                 |
 |---------------|-----------------------------------------------------------------------------|
 | `run`         | Executes a TestDriver script.                                           |
@@ -21,33 +21,33 @@ testdriverai <command> [options]
 | `version`     | Displays the current version of the TestDriver CLI.                     |
 | `help`        | Displays help information for the CLI or a specific command.               |
 
-## Example Usage
+## Example usage
 
-### Running a Test Script
+### Running a test script
 ```bash
 testdriverai run path/to/testdriver.yaml
 ```
 This command runs the specified TestDriver script, executing all steps defined in the file.
 
-### Validating a Script
+### Validating a script
 ```bash
 testdriverai validate path/to/testdriver.yaml
 ```
-This command checks the syntax and structure of the script to ensure it is valid before execution.
+This command checks the syntax and structure of the script to ensure it's valid before execution.
 
-### Initializing a New Project
+### Initializing a new project
 ```bash
 testdriverai init
 ```
 This command sets up a new TestDriver project in the current directory, creating the necessary folder structure and configuration files.
 
-### Checking the Version
+### Checking the version
 ```bash
 testdriverai version
 ```
 This command displays the installed version of the TestDriver CLI.
 
-### Getting Help
+### Getting help
 ```bash
 testdriverai help
 ```