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 idtests/
, 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 tagsauth
andsmoke
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.
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):
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, setautomated: true
on the YAML case and addparams.playwright
with the relative spec path. If a case id appears in tags but not in YAML, list the gaps. Do not setautomated: 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
Full post: gitoza.com/blog/ai-link-manual-automated-test-cases