# Link Manual Test Cases to Playwright and Robot Specs > Source: > Published: 2026-07-22 15:44:09+00:00 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. `.gitoza-lite/test/cases/` (VS Code / Cursor extension) or `.gitoza/test/cases/` (Desktop app). The `.yaml` is the case id`tests/` , `e2e/` , `robot/` — in the same repository.`automated: true` plus a `params` pointer.A PR can change the case, the Playwright spec, and the link in one review. 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](https://marketplace.visualstudio.com/items?itemName=gitoza.gitoza-yaml-test-cases) 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. ``` If the file is `AUTH-001.yaml` , the case id is `AUTH-001` . That string is the join key for everything below. 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): ``` js import { test, expect } from "@playwright/test"; test("login with valid credentials", { tag: ["@AUTH-001", "@smoke"], }, async ({ page }) => { // ... }); ``` **Robot Framework** — use `[Tags]` : ``` *** Test Cases *** Login With Valid Credentials [Tags] AUTH-001 smoke Open Login Page Submit Valid Credentials Dashboard Should Be Visible ``` 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` . `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. ``` 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. 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." `.gitoza-lite/test/cases/…/{CASE-ID}.yaml` .`{CASE-ID}` .`automated: true` and `params` on the matching case.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](https://marketplace.visualstudio.com/items?itemName=gitoza.gitoza-yaml-test-cases) **Full post:** [gitoza.com/blog/ai-link-manual-automated-test-cases](https://gitoza.com/blog/ai-link-manual-automated-test-cases)