QA Agent Skills Examples.

---
name: playwright-test-generator
description: |
  Generates Playwright TypeScript end-to-end tests from a feature description,
  acceptance criteria, or user story. Use when asked to write, scaffold, or
  generate end-to-end or browser-level tests using Playwright. Do NOT use for
  unit tests, API-level tests, component tests, or test frameworks other than
  Playwright.
version: "1.0.0"
metadata:
  author: QA Team
  tags: [playwright, e2e, test-generation, typescript]
---

## When to use
- User provides a feature description, AC, or user story and asks for tests
- User asks to "write a Playwright test", "generate e2e coverage", or "scaffold specs"
- User provides a URL or route and asks for browser-level test coverage

## Inputs
- Feature description, acceptance criteria, or user story text
- Route or URL under test (if known)
- Auth state required: logged-in / logged-out / both
- Any known constraints (viewport, locale, API mocks needed)

## Instructions
1. Read the provided spec and identify: the happy path, top 3 edge cases,
   and any error states (validation errors, empty states, network failures).
2. Scaffold a *.spec.ts file using the Page Object Model pattern.
   - Page class goes in tests/pages/<feature-name>.page.ts
   - Spec file goes in tests/<feature-name>.spec.ts
3. Use @playwright/test; import from ../fixtures if a fixtures file exists
   in the project.
4. Each test block must:
   - Have a descriptive name ("should show error when…")
   - Use auto-waiting assertions (expect(locator).toBeVisible()) not
     page.waitForTimeout()
   - Assert on both visible UI state and network response where relevant
5. Add a JSDoc comment above each describe block explaining what it covers.
6. After the code, list any assumptions made and flag any AC ambiguities.

## Output format
Return two code blocks:
1. The Page Object class (tests/pages/<name>.page.ts)
2. The spec file (tests/<name>.spec.ts)
Then a brief summary: test count, scenarios covered, assumptions, open questions.

## Anti-patterns
- Never use page.waitForTimeout() — use auto-waiting assertions instead
- Never hard-code test data; use variables, fixtures, or faker
- Never embed credentials — read from process.env or use auth fixtures
- Never write files directly to disk without user confirmation

## Safety
- Flag any test that requires network access to a real external service
- Do not generate tests that call destructive production endpoints

---
name: api-test-generator
description: |
  Generates HTTP/REST API tests from an OpenAPI spec, Postman collection,
  Hoppscotch export, or endpoint description. Use when asked to write or
  generate API tests, endpoint tests, or HTTP client test suites. Do NOT use
  for browser/UI tests, gRPC, GraphQL, or contract tests (Pact/Prism).
version: "1.0.0"
metadata:
  author: QA Platform Team
  tags: [api-testing, playwright, supertest, openapi]
---

## When to use
- User provides an OpenAPI spec file, route definition, or endpoint description
- User asks to "write API tests", "test this endpoint", or "generate REST tests"
- User shares a Postman collection and asks for equivalent automated tests

## Inputs
- API spec file path or endpoint description (method, URL, request body, auth)
- Base URL (or placeholder if unknown)
- Auth mechanism: bearer token, API key header, session cookie, or none
- Expected response schemas and error codes

## Instructions
1. Parse the spec and list all distinct endpoints and their HTTP methods.
2. For each endpoint generate at minimum:
   - Happy path (valid inputs → expected 2xx response)
   - Validation error (invalid/missing required fields → 4xx)
   - Auth error (missing or invalid token → 401/403)
3. Default framework: Playwright APIRequestContext.
   Switch to Supertest if user specifies Node/Express; raw fetch if specified.
4. Organise tests by resource path:
   - GET /users → tests/api/users.api.spec.ts
5. Each test must assert: HTTP status code, Content-Type header, and response
   body shape (use expect.objectContaining for partial matches).
6. Produce a coverage summary table after the code blocks.

## Output format
Full test file(s) in code blocks, then:
| Endpoint | Method | Cases | Gaps / Assumptions |
|----------|--------|-------|-------------------|

## Anti-patterns
- Never embed API keys or secrets — use process.env.API_KEY
- Never use hard-coded base URLs — use process.env.BASE_URL
- Never make calls to live production APIs during test generation

## Safety
- Validate all inputs before running generated scripts
- Flag endpoints that perform writes (POST/PUT/DELETE) — confirm before running

---
name: bug-report-structurer
description: |
  Converts rough bug notes, observations, or a brief description into a
  structured, developer-ready bug report. Use when asked to "write a bug
  report", "structure this bug", or "turn these notes into a ticket".
  Do NOT use for feature requests, performance investigations, or security
  vulnerability disclosure.
version: "1.0.0"
metadata:
  author: QA Team
  tags: [bug-report, defect, jira, documentation]
---

## When to use
- User provides raw observations about a bug and asks for a structured report
- User has reproduction steps but needs them formatted as a ticket
- User asks to "clean up" or "structure" informal bug notes

## Inputs
- Raw bug observation or description
- Browser, OS, and app version (or "unknown")
- Reproduction steps (even if informal)
- Expected vs. actual behaviour (if user knows)
- Any error messages, screenshots, or logs mentioned

## Instructions
1. Analyse the raw input and identify: the failure mode, reproduction
   conditions, environment, and any stated or implied root cause.
2. Write a structured bug report with these sections:
   **Summary** — one sentence, format: "[Component] [does/shows] [unexpected X] when [condition]"
   **Severity** — Critical / High / Medium / Low (justify in one line)
   **Priority** — P1 / P2 / P3 (justify separately from severity)
   **Environment** — Browser + version, OS + version, App version (use placeholder if unknown)
   **Steps to reproduce** — numbered, specific, with timing if relevant
   **Expected result** — what should happen
   **Actual result** — what actually happens
   **Root cause hypothesis** — if inferable; mark clearly as hypothesis
   **Areas to investigate** — 2-4 specific code areas or system components
   **Attachments** — list any screenshots, logs, or recordings mentioned
3. Clearly mark any hypothesis as "Hypothesis:" — never state unconfirmed
   causes as facts.
4. If the input is ambiguous, add an "Open questions" section.

## Output format
Structured Markdown bug report, ready to paste into Jira, Linear, or GitHub Issues.

## Anti-patterns
- Never state a root cause as confirmed unless the user confirmed it
- Never omit the Open questions section when inputs are ambiguous
- Never include personal opinions about code quality

## Safety
- Do not include any credentials, tokens, or PII that appear in bug notes
- Redact any sensitive data and note that it was redacted

---
name: test-case-generator
description: |
  Generates a structured test case table from acceptance criteria, a user
  story, or a feature specification. Use when asked to "generate test cases",
  "create a test case list", "derive tests from ACs", or "what should I test".
  Do NOT use when the user wants executable test code — use the appropriate
  framework-specific skill instead.
version: "1.0.0"
metadata:
  author: QA Team
  tags: [test-cases, test-planning, acceptance-criteria, bdd]
---

## When to use
- User provides acceptance criteria, a user story, or a feature spec
- User asks "what should I test for X" or "generate test cases for Y"
- User wants a test case list to review before writing automation

## Inputs
- Acceptance criteria or feature description (required)
- Priority guidance: which scenarios are most critical? (optional)
- System context: tech stack, API contract, known constraints (optional)

## Instructions
1. Parse the acceptance criteria and identify:
   - The primary actor(s) and their goals
   - Explicit success conditions (happy path)
   - Implicit boundary conditions (max/min values, empty states)
   - Stated error conditions (validation, auth, network)
   - Missing/ambiguous requirements
2. Generate test cases covering:
   - Happy path (at least one per distinct user goal)
   - Boundary value analysis (min, max, min-1, max+1)
   - Negative cases (invalid inputs, missing required fields)
   - Edge cases (empty state, concurrent actions, timeout)
   - Non-functional hints (accessibility, performance threshold if stated in ACs)
3. Assign each test case:
   - Test ID (TC-001, TC-002…)
   - Scenario name
   - Input / precondition
   - Expected result
   - Priority: P1 (critical path), P2 (important), P3 (nice-to-have)
4. After the table, list:
   - AC ambiguities that need clarification before testing
   - Assumptions made

## Output format
Markdown table:
| Test ID | Scenario | Input / Precondition | Expected Result | Priority |
|---------|----------|---------------------|-----------------|----------|

Followed by:
**Assumptions:** …
**Open questions / AC ambiguities:** …

## Anti-patterns
- Never skip boundary value analysis — it catches most regressions
- Never assign all cases P1 — force a ranking
- Never present assumptions as confirmed facts

---
name: release-readiness-reviewer
description: |
  Produces a structured release readiness checklist and go/no-go assessment
  from a list of changes (PR titles, ticket IDs, or a changelog). Use when
  asked to "review release readiness", "QA sign off", "prepare for deploy",
  or "what do we need to test before release". Do NOT use for individual
  feature reviews or ongoing sprint test planning.
version: "1.0.0"
metadata:
  author: QA Lead
  tags: [release, sign-off, checklist, risk, deployment]
---

## When to use
- Team is preparing for a release and needs a QA gate
- User provides a changelog, list of PRs, or list of tickets
- User asks for a go/no-go recommendation before deployment

## Inputs
- Changelog, PR titles, or ticket IDs for this release (required)
- Known risk areas or previous production incidents (optional)
- Test environment status (optional: staging, UAT, prod-like)
- Open bugs carried forward from previous sprint (optional)

## Instructions
1. Parse the list of changes and categorise each as:
   - Feature: new user-facing functionality
   - Fix: bug fix (note if P1/P2)
   - Refactor: internal change with no intended user impact
   - Infra/Config: deployment, dependency, or configuration change
2. For each category, assess risk level (High / Medium / Low) with a one-line
   rationale.
3. Generate a release readiness checklist:
   □ All P1/P2 bugs for this release verified fixed
   □ Regression suite passed on staging environment
   □ New features have test coverage (automated or manual sign-off noted)
   □ Infra/config changes reviewed by platform team
   □ Rollback plan documented and tested
   □ Monitoring/alerting confirmed active for changed services
   □ Performance baseline checked for high-traffic paths
   □ Accessibility spot-check completed for UI changes
   □ Data migration (if any) dry-run completed and verified
   □ Release notes drafted and reviewed
4. Identify the top 3 risk areas that need manual verification before go-live.
5. Output a go/no-go recommendation: GO / NO-GO / CONDITIONAL-GO (with conditions).

## Output format
### Release: [version or sprint name]
**Risk summary:** High / Medium / Low (with rationale)

**Checklist:**
[checkbox list]

**Top 3 risk areas requiring manual verification:**
1. …
2. …
3. …

**Recommendation:** GO / NO-GO / CONDITIONAL-GO
[One paragraph justifying the recommendation]

## Anti-patterns
- Never recommend GO without explicit confirmation that P1 bugs are resolved
- Never omit the rollback plan item — it is always required
- Do not present risk assessments as guarantees

## Safety
- Do not include internal system hostnames, IP addresses, or credentials
  in the output
- Flag any change that touches auth, payments, or PII as High risk
  regardless of scope