Prompts that turn a Session ID into working code

Before writing any code, inspect this repo's existing Playwright setup — playwright.config.ts, tests/, pages/, and any fixtures/ or helpers/ — and identify the conventions already in use: locator strategy, fixture setup, naming, and file structure. Then, using AIR session {sessionId}, generate a Playwright test in TypeScript for the recorded flow that follows those conventions exactly. Loop through each recorded step and, for each one, first check whether an existing Page Object method, fixture, or locator already covers it — reuse it instead of writing new code. Only add new locators or methods for steps that aren't covered yet, using getByRole / getByLabel as the default style unless the codebase already favors something else. Place the file in tests/checkout.spec.ts, matching the imports and structure of the other files in tests/. If no existing framework or pattern is found, tell me before generating anything.

Before writing any code, review the existing Selenium project structure — pages/, base test/page classes, conftest.py or config, and how waits and selectors are handled — and learn the conventions already established. Then, using AIR session {sessionId}, generate a Selenium WebDriver test in Python that reuses the Page Object pattern already defined in pages/BasePage.py. Loop through each recorded interaction one at a time: if an equivalent page-object method already exists, call it; only add a new method when the step isn't covered yet, following the same naming and structure as the existing methods. Prefer stable CSS selectors over XPath, matching the selector style already used elsewhere in the codebase. If the existing pattern is unclear, ask before inventing one.

Before writing any code, inspect the existing Cypress project — cypress.config.ts, cypress/e2e/, cypress/support/, and any custom commands — and identify the conventions already in use for selectors, commands, and file naming. Then, using AIR session {sessionId}, generate a Cypress test that follows the recorded flow using those conventions. Loop through each recorded step and check whether an existing custom command or selector helper already covers it before writing new selector code. Use data-cy attributes where AIR detected test IDs and the project already relies on them, and fall back to accessible role selectors otherwise — but match whatever selector strategy is dominant in cypress/e2e/ first.

Before creating anything new, search pages/ (or src/pages/) for a Page Object that already represents this page or flow. If one exists, extend it rather than duplicating it. Using AIR session {sessionId}, create or extend a Page Object for the "Checkout" page following the exact pattern in pages/BasePage.ts — same constructor style, locator declarations, and method naming. Loop through the recorded interactions one by one and, for each, check whether an equivalent method already exists on the class before adding a new one. Expose one method per unique interaction rather than raw locators, and keep the method names consistent with the verbs already used elsewhere in the page objects (e.g. clickX, fillY).

First, check the codebase for an existing locator strategy or helper — a getByTestId wrapper, a shared locators.ts/selectors.ts file, or custom selector utilities — so any suggestions match the established convention rather than introducing a new style. Then, from AIR session {sessionId}, list the locators AIR resolved for each step, ranked by stability. Loop through the list and flag any locator that either fell back to a structural/XPath selector or doesn't match the project's existing selector convention, so I can review it manually.

Before adding assertions, check how assertions are structured elsewhere in the test suite — custom matchers, an assertion helper file, or a particular expect wrapper — and match that style rather than introducing a new one. Using AIR session {sessionId}, loop through each state-changing step in the recording and add an assertion after it — confirm the cart total, the URL, and any success toast that appeared — using the same assertion pattern already used in the rest of the project.

Here is my existing test: tests/checkout.spec.ts. It's failing at the payment step. Before making any changes, review the file's current structure, imports, locators, and helper usage so your edit matches it exactly — don't restyle or restructure anything that isn't broken. Using AIR session {sessionId} (a fresh recording of the same flow), loop through the recorded steps and compare each one against the corresponding step in the current test. Update only the steps that changed, keep everything else — locator strategy, structure, assertions, helper calls — exactly as-is, and tell me which steps you changed and why.