How-To Guides

Start with Purpose — it drives everything else

The Purpose selector sets defaults for Role, Output Format, Reasoning Mode, and Coverage. In most cases you only need to pick a Purpose and paste your content; the defaults are calibrated.

The quickest way to pick the right Purpose: what deliverable do I need at the end of this prompt?

Map your current work to a Role

The Role selector sets the AI’s default instincts — vocabulary, standards, and what it naturally checks for. Think of it as which lens does this task need?

Add a second Role when the task crosses two failure layers

The Role selector is multi-select. The first selected Role sets the primary lens; the second adds an additional instinct to the same output. Only add a second Role when you can name a specific reason.

• Test Case Author + Data Validation Specialist — feature involves data correctness (types, ranges, nulls)
• Test Case Author + Security Test Engineer — feature handles auth, tokens, or PII
• API Engineer + Data Validation Specialist — endpoint whose response shape correctness matters
• Playwright Engineer + Flake Triage — writing a new spec while diagnosing why an existing spec is intermittent

Load a built-in preset for the five most common daily workflows

Open Presets ▾ in the left panel header. Loading a preset configures Purpose, Role, Output Format, Reasoning Mode, Coverage, and Guards in one click — you only need to paste your content.

Match what you paste to the Purpose

Different purposes need different raw material. Pasting the wrong thing — even well-written input — causes generic or off-target output.

Use the Additional Sources fields for evidence and schemas

Below the main textarea are two optional source fields. Keep evidence separate from the task description.

The Composer wraps these in typed XML blocks so the model treats them as evidence, not as instructions. This is what the assembled prompt looks like internally:

<context>
  Role: Bug Reporter / Defect Analyst
  Environment: Staging build 4821
</context>

<task>
  [Your main textarea content]
</task>

<data>
  [Your Logs / Evidence field content]
</data>

<schema>
  [Your Schema / API Spec field content]
</schema>

<constraints>
  [Output format, guards, reasoning mode, coverage]
</constraints>

Paste a House-Style Example to lock your team’s format

The House-Style Example context field is one of the highest-leverage things you can fill in. Paste one complete example output — a test case, a bug report, a table row — in your team’s preferred format. The model mirrors its structure, columns, and tone exactly.

Use Custom Instructions for one-off steers, not format changes

The Custom Instructions field is a free-text addition appended to the end of the prompt. Use it for situational adjustments that don’t warrant a selector change. Do not use it to change format or output type — use the Output Format selector instead.

Pick the right output format

Define Constant and Varying fields

Constant fields are identical across every record (e.g. tenant_id=1001, region=EU). Varying fields must be unique per record. At least one Varying field is required.

Set the Seed value for reproducible output (Faker.js only)

Identical seed + identical field configuration = byte-identical output every time. Use when the dataset is used in a regression test, a data migration, or you need team-wide reproducibility.

import { faker } from '@faker-js/faker';

type UserStatus = 'active' | 'trial' | 'expired' | 'locked';

export function buildUser(overrides = {}): User {
  return {
    id:        faker.string.uuid(),
    firstName: faker.person.firstName(),
    email:     faker.internet.email({ provider: 'example.com' }),
    status:    faker.helpers.arrayElement([
                 'active', 'trial', 'expired', 'locked'
               ] as const),
    ...overrides,
  };
}

export function buildUserSeeded(seed: number, overrides = {}): User {
  faker.seed(seed);
  return buildUser(overrides);
}

Run Automation Strategy on your batch of cases first

Paste your list of manual test cases. The prompt produces a decision for each case:

• Automate now — clear ROI, stable, deterministic, has a programmatic oracle
• Automate later — worth automating but blocked (feature in flux, missing selectors)
• Keep manual — one-off, visual, cognitive, or exploratory

Run Automation (Playwright) for each approved case

Switch Purpose to Automation (Playwright). Paste one manual test case (numbered steps + expected result). The prompt produces a runnable TypeScript spec using Arrange-Act-Assert structure.

• State seeded via API, not UI — no brittle multi-step login setup
• Role-based locators (getByRole, getByLabel, getByTestId) — never CSS class names
• Web-first assertions (toBeVisible(), toHaveText()) — never waitForTimeout()

import { test, expect } from '@playwright/test';

test('dealer adds a vehicle to active inventory', async ({ page }) => {

  // Arrange: seed state via API
  const apiResponse = await page.request.post('/api/dealers/123/session', {
    data: { username: 'qa_dealer@example.com', role: 'dealer_admin' },
  });
  await expect(apiResponse).toBeOK();

  // Act: role/label/testid locators
  await page.goto('/inventory');
  await page.getByRole('button', { name: 'Add Vehicle' }).click();
  await page.getByLabel('VIN').fill('1HGBH41JXMN109186');
  await page.getByRole('button', { name: 'Save Vehicle' }).click();

  // Assert: web-first auto-retrying assertions
  await expect(page.getByRole('alert'))
    .toContainText('Vehicle added successfully');
});

Verify the spec before committing it to CI