Agent Skill Creation.

You are a senior QA engineer and AI agent-skills author. Generate a complete, production-quality SKILL.md file for the QA workflow described below.

WORKFLOW: {{WORKFLOW}}
PURPOSE: {{PURPOSE}}
TARGET_AGENT: {{TARGET_AGENT}}
TESTING_STACK: {{TESTING_STACK}}
REPOSITORY_CONTEXT: {{REPOSITORY_CONTEXT}}
TEAM_STANDARDS: {{TEAM_STANDARDS}}

Generate a SKILL.md with the following structure. Output ONLY the SKILL.md content — no explanatory prose outside the file.

```
---
name: <kebab-case-name>
description: |
  <2–5 sentence description that answers: what this skill does, when the agent should use it (specific trigger phrases), and when the agent should NOT use it (explicit exclusions). This field is the activation trigger — make it precise.>
version: "1.0.0"
metadata:
  author: <team or author name>
  tags: [<comma-separated tags>]
  last-reviewed: "<YYYY-MM>"
---

## When to use
- <Specific user request pattern 1 that triggers this skill>
- <Specific user request pattern 2>
- <Specific user request pattern 3 if applicable>

## When NOT to use
- <Explicit exclusion 1 — prevents false positives>
- <Explicit exclusion 2>

## Inputs
- <Input 1: what the user must provide, e.g. feature description, spec file path, route>
- <Input 2>
- <Input 3 if applicable>

## Instructions
1. <Step 1 — specific and atomic>
2. <Step 2>
3. <Step 3>
4. <Step 4>
5. <Step 5 if applicable>

## Output format
<Describe the expected output: file name, structure, any required sections, any follow-up summary>

## Examples
<One short worked example showing the ideal output format or a key decision point>

## Anti-patterns
- <Common mistake 1 the agent must avoid>
- <Common mistake 2>

## Safety
- Do not include credentials, tokens, API keys, or personal data in the skill or its outputs.
- Generated code is a draft — review before committing or running in a non-test environment.
- <Any workflow-specific safety constraint>
```

After generating, provide a brief review checklist (5 items) a QA engineer should use to verify this skill before committing it.

You are a senior QA engineer specialising in Playwright and agent-skills authoring. Generate a production-quality SKILL.md for Playwright TypeScript end-to-end test generation, adapted to the project details below.

PROJECT_NAME: {{PROJECT_NAME}}
FIXTURE_PATH: {{FIXTURE_PATH}}
PAGE_OBJECT_PATH: {{PAGE_OBJECT_PATH}}
AUTH_STRATEGY: {{AUTH_STRATEGY}}
ADDITIONAL_CONVENTIONS: {{ADDITIONAL_CONVENTIONS}}

Output ONLY the SKILL.md content inside a fenced code block, ready to save.

```
---
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 for {{PROJECT_NAME}} using Playwright.
  Do NOT use for unit tests, component tests, API-level tests, or test frameworks
  other than Playwright.
version: "1.0.0"
metadata:
  author: QA Team
  tags: [playwright, e2e, test-generation, typescript, page-object-model]
  last-reviewed: "<YYYY-MM>"
---

## When to use
- User provides a feature description, acceptance criteria, or user story and asks for Playwright 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

## When NOT to use
- Unit tests, component tests, or API tests — use the appropriate dedicated skill
- Frameworks other than Playwright (Cypress, WebdriverIO, Selenium)
- Generating tests without any feature context or specification

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

## Instructions
1. Parse the spec and identify: the primary happy path, top 3 edge cases, and at least one error state.
2. Create the Page Object class at {{PAGE_OBJECT_PATH}}/<feature-name>.page.ts.
   - Expose locators as readonly properties
   - Expose actions as async methods with clear names
3. Create the spec file at tests/<feature-name>.spec.ts.
   - Import from {{FIXTURE_PATH}} if a fixtures file exists
   - Auth strategy: {{AUTH_STRATEGY}}
4. Each test must:
   - Have a descriptive name starting with "should"
   - Use auto-waiting assertions only (expect(locator).toBeVisible(), toHaveText(), etc.)
   - Never use page.waitForTimeout()
   - Be independent — no shared state between tests
5. Add a JSDoc comment above each describe block explaining the scenario group.
6. After the code, list: assumptions made, AC ambiguities, any missing test data.

## Output format
Return two code blocks:
1. Page Object ({{PAGE_OBJECT_PATH}}/<feature-name>.page.ts)
2. Spec file (tests/<feature-name>.spec.ts)
Then a brief table: Test | Scenario | Priority (P1/P2/P3) | Coverage note.

## Anti-patterns
- Never use page.waitForTimeout() — always use auto-waiting assertions
- Never hard-code test data; use variables, fixtures, or faker
- Never embed credentials in test code; read from process.env or auth fixtures
- Never share state between test files

## Safety
- Do not include credentials, tokens, or PII in the generated code
- Generated tests are a draft — review before committing or running in CI
- Flag any test that requires access to a real external service or production environment
```

You are a senior QA engineer and agent-skills author. Generate a production-quality SKILL.md for API test authoring, adapted to the project details below.

API_FRAMEWORK: {{API_FRAMEWORK}}
SPEC_FORMAT: {{SPEC_FORMAT}}
BASE_URL_ENV_VAR: {{BASE_URL_ENV_VAR}}
AUTH_MECHANISM: {{AUTH_MECHANISM}}
ADDITIONAL_CONVENTIONS: {{ADDITIONAL_CONVENTIONS}}

Output ONLY the SKILL.md content inside a fenced code block.

```
---
name: api-test-generator
description: |
  Generates HTTP/REST API tests from an OpenAPI spec, Postman collection, or
  endpoint description using {{API_FRAMEWORK}}. Use when asked to write or generate
  API tests, endpoint tests, or REST 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, {{API_FRAMEWORK}}, {{SPEC_FORMAT}}]
  last-reviewed: "<YYYY-MM>"
---

## When to use
- User provides a {{SPEC_FORMAT}} file, route definition, or endpoint description
- User asks to "write API tests", "test this endpoint", or "generate REST tests"
- User shares a Postman/Hoppscotch collection and asks for automated equivalents

## When NOT to use
- Browser or UI tests — use the Playwright skill
- GraphQL or gRPC — requires a separate dedicated skill
- Contract/consumer-driven tests (Pact) — use a separate contract-testing skill

## Inputs
- API spec file path, URL, or endpoint description (required)
- Base URL (use {{BASE_URL_ENV_VAR}} from environment)
- Auth: {{AUTH_MECHANISM}}
- Expected response schemas and documented error codes

## Instructions
1. Parse the spec and list all distinct endpoints and 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 credentials → 401/403)
3. Use {{API_FRAMEWORK}} for all requests.
4. Organise tests by resource path (e.g. GET /users → tests/api/users.api.spec.ts).
5. Each test must assert: HTTP status code, Content-Type header, and response body shape.
6. After the code, produce a coverage summary table: Endpoint | Method | Cases | Gaps.

## Output format
Full test file(s) in code blocks, then a Markdown coverage table.
Flag any spec ambiguities as assumptions.

## Anti-patterns
- Never embed API keys or secrets — use process.env variables
- Never use hard-coded base URLs — read from {{BASE_URL_ENV_VAR}}
- Never call live production endpoints during test generation
- Never skip the auth-error test case for authenticated endpoints

## Safety
- Do not include real credentials or tokens in the skill or generated tests
- Flag endpoints that perform writes (POST/PUT/DELETE/PATCH) — confirm test environment before running
- Generated tests are a draft — review before running in any shared environment
```

You are a senior QA engineer and agent-skills author. Generate a production-quality SKILL.md for a bug-report-improver skill, adapted to the details below.

TICKET_SYSTEM: {{TICKET_SYSTEM}}
SEVERITY_SCALE: {{SEVERITY_SCALE}}
REQUIRED_FIELDS: {{REQUIRED_FIELDS}}
TEAM_CONVENTIONS: {{TEAM_CONVENTIONS}}

Output ONLY the SKILL.md content inside a fenced code block.

```
---
name: bug-report-improver
description: |
  Converts rough bug notes, observations, or informal descriptions into a
  structured, developer-ready bug report formatted for {{TICKET_SYSTEM}}.
  Use when asked to "write a bug report", "structure this bug", "clean up
  these notes", or "turn this observation into a ticket". Do NOT use for
  feature requests, performance profiling reports, or security vulnerability
  disclosure.
version: "1.0.0"
metadata:
  author: QA Team
  tags: [bug-report, defect, {{TICKET_SYSTEM}}, documentation]
  last-reviewed: "<YYYY-MM>"
---

## When to use
- User provides raw bug observations 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

## When NOT to use
- Feature requests or enhancement suggestions
- Performance investigation reports (different format and audience)
- Security vulnerability disclosure (requires different responsible disclosure format)

## Inputs
- Raw bug observation or description (required)
- Browser, OS, and app version (or "unknown")
- Reproduction steps (even if informal)
- Expected vs. actual behaviour (if known)
- Any error messages, logs, or screenshots mentioned (paste excerpts only — no credentials or PII)

## Instructions
1. Analyse the raw input: identify the failure mode, reproduction conditions, environment, and any stated root cause.
2. Write a structured bug report with these exact sections:
   **Summary** — one sentence: "[Component] [does/shows] [X] when [condition]"
   **Severity** — {{SEVERITY_SCALE}} (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**
   **Actual result**
   **Root cause hypothesis** — if inferable; mark clearly as "Hypothesis:"
   **Areas to investigate** — 2–4 specific code areas or system components
   **Required fields** — {{REQUIRED_FIELDS}}
3. Mark all hypotheses with "Hypothesis:" — never state unconfirmed causes as facts.
4. Add an "Open questions" section when inputs are ambiguous.

## Output format
Markdown bug report, ready to paste into {{TICKET_SYSTEM}}.

## 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 data or real credentials from logs in the output

## Safety
- Redact any credentials, tokens, or PII that appear in the raw notes
- Note explicitly when redactions have been made
- Do not invent facts, error messages, or behaviour not present in the input
```

You are a senior QA engineer and agent-skills author. Generate a production-quality SKILL.md for test case generation from acceptance criteria, adapted to the details below.

TEST_CASE_FORMAT: {{TEST_CASE_FORMAT}}
PRIORITY_SCALE: {{PRIORITY_SCALE}}
INCLUDE_BDD: {{INCLUDE_BDD}}
TEAM_CONVENTIONS: {{TEAM_CONVENTIONS}}

Output ONLY the SKILL.md content inside a fenced code block.

```
---
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 for X".
  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, {{TEST_CASE_FORMAT}}]
  last-reviewed: "<YYYY-MM>"
---

## 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

## When NOT to use
- User wants executable test code (Playwright, Selenium, etc.) — use the appropriate framework skill
- User asks for a test strategy or test plan (different output scope)
- User asks for performance or security test cases specifically (use dedicated skills)

## 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 ACs and identify: primary actor(s), success conditions (happy path), boundary conditions, stated error conditions, and any missing or 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 where applicable)
   - Negative cases (invalid inputs, missing required fields)
   - Edge cases (empty state, concurrent actions, timeout)
3. Format as {{TEST_CASE_FORMAT}}.
4. Assign each test: Test ID | Scenario | Input / Precondition | Expected Result | Priority ({{PRIORITY_SCALE}}).
5. After the table, list: AC ambiguities that need clarification, assumptions made.
6. {{INCLUDE_BDD}}

## Output format
{{TEST_CASE_FORMAT}} table, then:
**Assumptions:** …
**Open questions / AC ambiguities:** …

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

## Safety
- AI-generated test cases are a starting point — review for completeness before sign-off
- Flag any AC that is ambiguous rather than making assumptions silently
```