Link Manual Test Cases to Playwright and Robot Specs

Most teams already keep Playwright or Robot Framework specs next to the product. Manual cases often live somewhere else — a spreadsheet, a cloud TMS, or a wiki page nobody updates after the first release. That is why automation coverage is usually a quarterly guess: the catalog and the specs never share an id. Put both in the same Git repo, give every manual case a stable id, and linking becomes a text match. Any IDE agent can do that if the cases are files it can already see — no custom AI product inside a test tool. One repo, two layers of the same suite Manual cases are YAML files under .gitoza-lite/test/cases/ (VS Code / Cursor extension) or .gitoza/test/cases/ (Desktop app). The filename without .yaml is the case id. Automated tests live wherever your team already puts them — tests/, e2e/, robot/ — in the same repository. Traceability is a shared id: put that case id on the automation side as a tag (or name), and on the YAML side as automated: true plus a params pointer. A PR can change the case, the Playwright spec, and the link in one review. Step 1 — Draft manual cases in the IDE Open the repo in Cursor or VS Code. Point the agent at a few existing case files so it learns your title style, tags, and step length. Then feed it a user story, a ticket, or a screenshot. Ask for several cases at once, not one shallow step. A useful prompt looks like: Read .gitoza-lite/test/cases/shopflow/auth/ for format. From ticket SHOP-184, draft three YAML cases (happy path, invalid password, locked account). Filename = case id. Use tags auth and smoke where it fits. Save the files under the suite folder. Then open the Gitoza Lite Test Repository tab to browse, edit, and — when you are ready — run them as a manual suite with Pass / Fail / Skip. The extension does not ship its own model. It keeps cases as plain YAML so whatever assistant you already use can read and write them. A minimal case: --- title: Login with valid credentials priority: high tags: [smoke, auth] status: active --- ## Steps 1. Open the login page 2. Enter valid credentials ## Expected result User is redirected to the dashboard. Enter fullscreen mode Exit fullscreen mode If the file is AUTH-001.yaml, the case id is AUTH-001. That string is the join key for everything below. Step 2 — Put the case id on the automation side Before coverage can be marked, automation needs a handle that matches the YAML filename. Playwright — tags must start with @ (or include the id in the test title): import { test, expect } from "@playwright/test"; test("login with valid credentials", { tag: ["@AUTH-001", "@smoke"], }, async ({ page }) => { // ... }); Enter fullscreen mode Exit fullscreen mode Robot Framework — use [Tags]: *** Test Cases *** Login With Valid Credentials [Tags] AUTH-001 smoke Open Login Page Submit Valid Credentials Dashboard Should Be Visible Enter fullscreen mode Exit fullscreen mode Same idea for other runners: one stable token that equals the case id. Prefer the id over a free-text title match — titles drift; filenames should not. When matching Playwright tags to YAML, strip the leading @ so @AUTH-001 maps to AUTH-001.yaml. Step 3 — Flip automated and fill params Once specs carry the case id, close the loop on the YAML side — with Cursor or a small script: Scan tests/ for Playwright tags matching case ids under .gitoza-lite/test/cases/. For each hit, set automated: true on the YAML case and add params.playwright with the relative spec path. If a case id appears in tags but not in YAML, list the gaps. Do not set automated: true unless the tag and filename match after stripping @. You end up with something like: --- title: Login with valid credentials tags: [smoke, auth] automated: true params: playwright: tests/auth/login.spec.ts --- ## Steps 1. Open the login page 2. Enter valid credentials ## Expected result User is redirected to the dashboard. Enter fullscreen mode Exit fullscreen mode For Robot, the same field under params might be robot: tests/auth/login.robot. Teams often add a custom key as well — auto_tag: AUTH-001 or suite: 01_user_authentication — so filters and scripts stay boring. params is a free key-value map; agree on a small schema in the repo README and stick to it. automated: true is the coverage flag. params is the pointer. Tags on the YAML side stay useful for smoke, priority, and feature filters — they do not have to duplicate the automation path. Treat agent output like any other PR: review git diff before merge. A wrong tag match that flips automated: true is worse than a missing link — catch it in review, or run the same rules in CI so chat is optional. Why Git beats a TMS link field In a vendor database, linking is usually a URL paste or a fragile title search. Agents cannot see the catalog unless you build API glue. In Git, the agent (or a script) reads cases and specs in one workspace, and git diff shows exactly which cases flipped to automated. Coverage is "scan tags ↔ case ids," not "update the spreadsheet after the sprint." A concrete loop Feature lands on a branch. Agent drafts or updates manual YAML under .gitoza-lite/test/cases/…/{CASE-ID}.yaml. Automation engineer (or the same agent) implements Playwright / Robot and tags the test with {CASE-ID}. Agent or script sets automated: true and params on the matching case. Manual testers execute what is still unautomated; Desktop dashboards can show automation rate when you use the full app. Start with one suite. Do not try to backfill five years of TestRail in a weekend. Ship the next feature with case + spec + link in the same PR. Try it (free VS Code extension): Gitoza on Marketplace Full post: gitoza.com/blog/ai-link-manual-automated-test-cases