> For the complete documentation index, see [llms.txt](https://help.aximo.autify.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.aximo.autify.com/test-case-creation/writing-prompts.md).

# Write prompts

In Aximo, the AI tester runs tests based on the content entered in the scenario. This page explains the scenario structure that is easy for the AI tester to read and writing patterns to avoid.

## Basic structure

A good prompt includes three elements: **starting point, action steps, and expected result**.

```
{Where to start}
{What to do}
{What to verify}
```

The following example satisfies this structure.

```
Open example.com
On the login screen, enter email address test@example.com and password {{PASSWORD}}
Confirm that the dashboard screen is displayed
```

For Web sessions, use a URL or web service name as the starting point. For mobile sessions, use the app name or the screen where you want to start.

## Writing tips

### Write one action per line

Separate actions with line breaks and write one action per line. Separating action units helps the AI tester read the steps and verification conditions.

```
Open Google Flights
Search for round-trip flights from San Francisco to Tokyo, departing 30 days from today and lasting 4 days
Confirm that the search results include flights arriving at NRT and HND
```

### Specify the starting point

The AI starts each session from a new browser or device environment. Specify which screen or URL the operation should start from. Either specify a start URL or write the URL or screen name directly in the scenario.

For mobile sessions, write the action as launching an app or navigating within an app, not as accessing a website.

### Write the expected result specifically

Instead of "Confirm that it works correctly," write what should be displayed or what state should be reached.

| Vague example                | Specific example                                               |
| ---------------------------- | -------------------------------------------------------------- |
| Confirm that login succeeds  | Confirm that the dashboard screen is displayed                 |
| Confirm that no error occurs | Confirm that no errors are displayed in the JavaScript console |
| Check the dropdown content   | Confirm that the timezone dropdown has 10 options              |

### Specify test data and sensitive values

Write test data such as email addresses and card numbers directly in the scenario. For sensitive values such as passwords and one-time passwords, shared values, and files, use shared memories and reference them with placeholders such as variable `{{PASSWORD}}`, OTP `{{OTP:LOGIN}}`, or file `{{file:INVOICE}}`. Select hostnames and apps in the settings when creating sessions or running cases.

```
Proceed from the cart screen to the payment screen
Enter test card number 4111111111111111 and password {{PASSWORD}}, then complete payment
Confirm that the order confirmation screen is displayed
```

For flows that use verification emails or authentication codes, write the scenario so it tells the AI tester to use the inbox address assigned to that test, wait for the message, and open the link or enter the code.

```
On the sign-up screen, enter the inbox address assigned to this test in the email field and submit
Wait for the verification email to arrive
Open the verification link in the message
Confirm that the dashboard screen is displayed
```

In mobile sessions that run on iOS devices, you cannot insert file shared memories into the scenario. For details, see [About memories](/memories/memory-overview.md).

### Make the test objective clear

Even when operating the same screen, success and failure criteria change depending on the objective. Include wording in the scenario that makes it clear what the test is intended to verify.

| Objective         | Example                                                              |
| ----------------- | -------------------------------------------------------------------- |
| Functional check  | Confirm that the dashboard screen is displayed after login           |
| Bug exploration   | Check whether there are any operational issues on the login screen   |
| Verification step | Confirm that no error message is displayed after submitting the form |

### Keep one session focused on one objective

Group related operations and verifications in one session. If objectives differ, such as login, profile editing, and account cancellation, split them into separate sessions or cases so it is easier to isolate the cause when a failure occurs.

## Writing patterns to avoid

| Avoid                                            | Use instead                                                        | Reason                                                                                                            |
| ------------------------------------------------ | ------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------- |
| Click the `#submit` button                       | Click **Submit**                                                   | The AI tester identifies the operation target from the screen display. You do not need to fix selectors or XPath. |
| Check operation                                  | Confirm that the home screen is displayed                          | If the expected result is vague, it is difficult to determine success or failure.                                 |
| Log in, edit the profile, and cancel the account | Split the session by objective                                     | Mixing unrelated verifications makes it harder to identify the cause when a failure occurs.                       |
| Enter the email address and password             | Enter email address `test@example.com` and password `{{PASSWORD}}` | If input values are missing, the AI tester may be unable to continue the test.                                    |

## Notes for using prompts in cases

When saving and running a prompt as a case, write it so that the scenario alone explains the starting point, input values, and expected result. Because **Interactive mode** is off by default when running from a case, make the scenario self-contained and do not rely on additional user confirmation.

For more information, see [About the Aximo AI Tester](/test-case-creation/ai-tester.md#interaction-with-users) and [Running sessions](/test-case-creation/session-execution.md).

## Advanced operations available on Web

In Web sessions, include DevTools, terminal, HTTP requests, and similar operations in addition to screen operations.

```
Open the login screen
Open DevTools and confirm that no errors are displayed in the JavaScript console
```

```
Run npm run seed in the terminal
Open http://localhost:3000 in the browser and confirm that the initial data is displayed
```

## Input limits and safety

{% hint style="info" %}
Enter a scenario with at least 10 characters and no more than 10,000 characters. Instructions included in web pages or loaded documents do not take priority over the original scenario.
{% endhint %}

## Further reading

* [About the AI Tester](/test-case-creation/ai-tester.md)
* [About sessions and cases](/test-case-creation/test-case-creation-overview.md)
* [Test session](/test-case-creation/create-test-session.md)
* [Create cases](/test-case-creation/create-test-case.md)
* [Running sessions](/test-case-creation/session-execution.md)
* [About memories](/memories/memory-overview.md)