Ghosteken Quality Assurance
Overview
This skill executes verification scenarios against a known expected behaviour (spec, acceptance criteria, or task description) and produces an evidence-backed verdict. It covers browser UI flows, API verification, and regression checks — always starting from a spec anchor, never from the current implementation.
When to Use
Use this skill when:
- Verifying that a new feature works end to end
- Confirming a bug fix resolved the reported issue
- Running a regression check after any code change
- Executing a functional test plan for a feature
- Performing a smoke test before or after deployment
Do not use this skill when:
- Writing new tests or designing test coverage → use
test-driven-development - Isolating a bug's root cause → use
debugging-and-error-recovery - Doing a visual/design audit → use
browser-testing-with-devtools
Core Process
Step 1 — Establish Expected Behaviour (mandatory)
Before executing anything:
- Look for a spec, under the project's external output location (see
references/external-output-paths.md) —specs/<feature-slug>/SPEC.md's Success Criteria section — or a legacy in-repoSPEC.md, task description, acceptance criteria, or issue description - If found — list the specific behaviours to confirm (one per scenario)
- If not found — stop and ask: "What is the expected behaviour for [X]? I need a reference before I can verify."
Never infer expected behaviour from the current implementation. That makes verification circular — you'd confirm the code matches itself, not that it matches intent.
Step 2 — Plan Scenarios
If a Gherkin test-cases.md already exists for the feature, its scenarios are already concrete verification scenarios — execute those directly rather than re-deriving them from the feature spec. Otherwise, map expected behaviours to concrete verification scenarios:
| Type | What to check |
|---|---|
| Happy path | Core flow with valid inputs → expected output |
| Edge cases | Empty state, boundary values, optional fields absent |
| Error handling | Invalid input, network failure → correct error shown |
| Fix confirmation | Specific issue from bug report no longer occurs |
| Regression | Previously passing behaviour still works |
Step 3 — Select Transport
Choose the right execution channel for each scenario. For full auth setup and Playwright MCP guidance, see transport-and-auth.md.
| Scenario | Transport |
|---|---|
| UI behaviour, visual correctness | Headless Playwright MCP (default) |
| API contract, response shape | curl / HTTP tool |
| Requires user's existing browser session (Google SSO) | Bridge mode |
Step 4 — Execute Scenarios
Drive each scenario to completion:
- Use role+name locators for browser interactions, not positional refs
- Seed test state through the same channel as the test (browser state ≠ API session)
- Apply the two-strikes rule: if a step fails twice with the same error, stop and report — do not iterate
Step 5 — Produce Verification Report
## Verification Report
**Feature / Fix:** [Name or issue reference]
**Spec reference:** [Source of expected behaviour]
### Summary
**Overall verdict:** PASS | FAIL | PARTIAL
### Scenario Results
| Scenario | Expected | Observed | Verdict |
|---|---|---|---|
| [Name] | [Spec says] | [What happened] | PASS / FAIL |
### Issues Found
- **[Critical / High / Medium]** — [Description + evidence]
### Regressions
- [Any previously passing behaviour that now fails]
### Evidence
- [Screenshots, response bodies, console output]
Common Rationalizations
| Excuse | Reality |
|---|---|
| "I'll just check it looks right" | Looking right is not a verdict. Run the scenario against the spec. |
| "The fix is obvious, I don't need a spec" | Every obvious fix has a different interpretation. Get the spec first. |
| "I'll try a few things until it works" | Two strikes and stop. Iteration without a baseline is guessing, not verification. |
| "The tests pass so it works" | Passing tests confirm what tests check — not that the feature works. Execute the scenarios. |
| "I can infer the expected behaviour from the code" | That makes verification circular. Spec or ask. |
Red Flags
- Producing a PASS verdict without observable evidence
- Starting execution before identifying expected behaviour
- Skipping regression scenarios because "only one thing changed"
- Using API-seeded state for a browser test (separate sessions)
- Retrying a failing step more than twice without stopping to report
Verification
Exit criteria — all must be met before marking QA complete:
- Expected behaviour source is documented (spec file, issue link, or user confirmation)
- Every planned scenario has a recorded result (PASS / FAIL + evidence)
- Regression scenarios were run (at least the scenarios most likely affected by the change)
- Issues found are categorised by severity with reproduction steps
- Overall verdict (PASS / FAIL / PARTIAL) is stated explicitly