testeiya 0.3.9 → 0.3.14

package/skills/testomatio/test-management/qa-e2e-tests-reporting/references/TESTOMATIO_REPORTERS_CONFIG.md

@@ -0,0 +1,118 @@
+# Testomat.io Reporters Configuration
+
+## Installation
+
+```bash
+npm install @testomatio/reporter --save-dev
+# or pnpm install @testomatio/reporter --save-dev
+# or yarn add @testomatio/reporter --dev
+```
+
+## Environment Variables
+
+| Variable | Description | Required |
+|----------|-------------|----------|
+| `TESTOMATIO` | API key (format: `tstmt_xxxxx`) | Yes (for sync) |
+| `TESTOMATIO_WORKDIR` | Working directory for relative paths | No |
+
+## Configuration File (Recommended)
+
+Create `.env` file in project root to store credentials securely:
+
+```env
+TESTOMATIO=tstmt_xxx
+...
+```
+
+> **Best Practice:** Use `.env` file instead of passing `TESTOMATIO` token as command variable. Keep `.env` in `.gitignore`.
+
+## Framework Configuration
+
+### Playwright
+
+**Config:**
+```js
+reporter: [
+  ['@testomatio/reporter/playwright'],
+],
+```
+
+**Run:**
+- `npx playwright test` (if token configured in .env).
+- `TESTOMATIO={API_KEY} npx playwright test` (if no token configured in .env).
+
+### CodeceptJS
+
+**Config:**
+```js
+plugins: {
+  testomatio: {
+    enabled: true,
+    require: '@testomatio/reporter/codecept',
+  }
+}
+```
+
+**Run:** 
+- `npx codeceptjs run` (if token configured in .env).
+- `TESTOMATIO={API_KEY} npx codeceptjs run` (if no token configured in .env).
+
+### Mocha
+
+**Run:**
+```bash
+mocha --reporter @testomatio/reporter/mocha --reporter-options apiKey=tstmt_xxx
+```
+
+### WebdriverIO
+
+**Config (wdio.conf.js):**
+```js
+const testomatio = require('@testomatio/reporter/webdriver');
+// or
+// const testomatio = require('@testomatio/reporter/wdio');
+
+exports.config = {
+  // ...
+  reporters: [
+    [
+      testomatio,
+      {
+        apiKey: process.env.TESTOMATIO,
+      },
+    ],
+  ],
+};
+```
+
+**Run:** `npx @testomatio/reporter run 'npx wdio wdio.conf.js'`
+
+### Jest
+
+**Config (jest.config.js):**
+```js
+reporters: ['default', ['@testomatio/reporter/jest', { apiKey: process.env.TESTOMATIO }]],
+```
+
+**Run:** `npx jest`
+
+## Import Tests to TMS
+
+```bash
+npx check-tests <framework> "<glob-pattern>"
+```
+
+Examples:
+```bash
+npx check-tests playwright "tests/**/*.spec.js"
+npx check-tests playwright "tests/**/*.spec.ts" --typescript --update-ids
+npx check-tests jest "tests/**/*.test.js" --require-ids
+npx check-tests mocha "test/**/*_test.js"
+npx check-tests codeceptjs "tests/**_test.js"
+```
+
+Example using the `TESTOMATIO` token in the exec command:
+```bash
+# Not recommended, but can be used for testing
+TESTOMATIO=tstmt_xxx npx check-tests playwright "tests/**/*.spec.js"
+```

package/skills/testomatio/test-management/qa-pr-requirements-analyzer/SKILL.md

@@ -0,0 +1,149 @@
+---
+name: qa-pr-requirements-analyzer
+description: Analyze a pull request's context - title, description, comments, linked issues, attached schemas/images — to understand the original intent, verify scope against the linked ticket, surface ambiguities and edge cases, and produce a structured requirements summary with testable acceptance criteria. Use this skill when the user wants to understand WHAT a PR is supposed to do (not just what code changed), check whether the PR matches its linked ticket/task or generate acceptance criteria from PR/ticket context rather than from code.
+license: MIT
+metadata:
+  author: Testomat.io
+  version: 1.1.0
+---
+
+# QA PR Requirements Analyzer
+
+Reviews a pull request's human-written context — title, description, comments, linked tickets, attached images — to extract the original requirements, verify scope, and produce a requirements summary that downstream skills (`qa-write-test-cases`) can consume.
+
+Complement of `pull-request-diff-analyzer`:
+
+| Skill | Input | Output | Focus |
+|-------|-------|--------|-------|
+| `pull-request-diff-analyzer` | git diff, changed files | AC from code changes | "what the code does" |
+| `qa-pr-requirements-analyzer` | PR title, description, comments, linked issue | summary of requirements with scope verification, AC | "what the PR is supposed to do" |
+
+- Use them together for a full picture.
+- If the user only wants to know what code changed, use `pull-request-diff-analyzer` instead.
+
+## Step 1: Detect PR Context
+
+Accept, in priority order:
+1. A PR number or URL from the user prompt (e.g. `https://github.com/org/repo/pull/1234`).
+2. The open PR for the current branch: `gh pr view --json number,title,baseRefName,headRefName,url`.
+3. A ticket key only (Jira `PRJ-123`, Linear, etc) — analyze the ticket, then check for any open PR referencing it.
+
+- If none are detectable, ask the user for a PR number/URL, branch name, or ticket key.
+- If the branch exists only locally, ask the user to push it or provide the PR details directly.
+
+## Step 2: Read PR Context
+
+Collect what the developer and team wrote — not the code. Detect available MCP/CLI tools and pull:
+- PR metadata (title, description, comments, labels, milestone, assignees) — via Jira/Linear/GitHub MCP if enabled, else `gh` CLI.
+- Embedded images/diagrams in the body — read them (vision-capable agent or `fetch` + describe); they often capture UI changes, error states, or flows that text misses.
+- Linked tickets — parse the PR body and branch name for ticket references.
+
+**Do not fabricate ticket content or add incorrect information.**
+
+## Step 3: Resolve Linked Tickets
+
+The PR description is often a thin summary; the ticket has the real requirements. Use the first available tool:
+
+1. Jira/Linear MCP if enabled — fetch issue summary, description, AC, comments, linked issues, attachments.
+2. GitHub MCP if enabled — fetch the linked issue.
+3. `gh` CLI fallback — `gh issue view {N} --json title,body,comments,labels`. For Jira/Linear without an MCP, ask the user to paste the issue content.
+4. No access — note the gap explicitly in the output and continue with what you have.
+
+## Step 4: Verify Scope and Detect Ambiguities
+
+Compare what the PR does against what the ticket asked for. These are questions to raise, not assertions that the code is wrong.
+
+Scope verification — build three lists:
+- In scope — ticket requirements addressed by the PR (description or code, see Step 5).
+- Out of scope — ticket requirements with no corresponding PR change. These are the most valuable output of this skill.
+- Extra (not in ticket) — PR changes not mentioned in the ticket. Flag for review (intentional or accidental?).
+
+Ambiguities, edge cases, open questions — surface only issues supported by the available context. **Do not invent new requirements** or assume the product should handle a scenario unless the ticket, PR description, comments, or surrounding context suggest it is relevant. Look for:
+- Underspecified behavior — the ticket describes a capability but omits important details (e.g. export is required, but format, naming, permissions, or empty-state behavior are not defined).
+- Unanswered comments — questions in PR or ticket comments with no visible resolution.
+- Conflicting requirements — different parts of the ticket, comments, or PR description disagree.
+- Potentially relevant edge cases — scenarios related to the stated requirements whose expected behavior is not specified. Present these as questions, not requirements.
+  - **Never report an edge case solely because it is a common software concern.**
+  - Only raise an edge case when the ticket, PR description, affected domain, or discussion suggests it may be relevant.
+
+## Step 5: Identify Affected Files
+
+Do not do a deep code review — that is `pull-request-diff-analyzer`. Prefer files mentioned in the PR description or ticket; cross-check with `git diff {base}...HEAD --name-only` only if the description doesn't enumerate them.
+
+**Short-circuit (no source behavior):** if every changed file is non-source (`*.md`, `docs/**`, `tests/**`, configs, CI, deps, lock files):
+- Do not invent AC. Do not invoke `pull-request-diff-analyzer`.
+- Produce a short summary: PR title, type (`docs`/`chore`/`ci`/`deps`), one-sentence `Changes`, full file list.
+- Add the note `> No source code behavior changed. Acceptance criteria generation is not applicable for this PR.`
+- Stop here.
+
+**Empty PR description:** if there is no body and the branch name doesn't encode intent:
+- Pull `git log {base}..HEAD --pretty=format:"%s%n%b"`.
+- Combine with changed files and branch name into a tentative one-sentence `Changes`.
+- Mark `> PR description was empty. Summary derived from branch name, commits, and changed files only.`
+- If a linked ticket exists, prefer the ticket as source of truth and note the empty body under "Ambiguities".
+
+## Step 6: Generate the Requirements Summary
+
+**Save to a `.md` file only if the original prompt explicitly requests saving.** Write it to the user-specified folder.
+
+Filename: slugify the PR title (lowercase, dashes, no special chars, max 40 chars), append the PR number. Example: `Add user export to CSV` → `add-user-export-to-csv-pr-1234.md`.
+
+Output template (filled example: [summary-example.md](./references/summary-example.md)):
+
+```md
+## PR Requirements Summary
+
+**PR:** {title}
+**Branch:** {headRefName} → {baseRefName}
+**Type:** {feature | bugfix | refactor | deps}
+**Linked Tickets:** ... (only if any exist)
+
+**Source of Truth:**
+- PR description: {present | empty — derived from commits/branch}
+- Jira/GitHub ticket: {resolved | not resolved — no MCP available}
+- Most reliable source: {PR description | ticket | commits}
+
+**Changes Overview:** ... (1-2 sentences — intent, not implementation)
+
+**Impacted Areas:**
+- Payment processing (6 source files)
+- Billing configuration (2 config files)
+- ... (bullet list, only meaningful business/technical impact; omit if empty)
+
+**High Level Key files (up to 5):**
+- `path/to/file.ts` — source
+- ... (categorized: source | config | test | docs | migration | deps)
+
+**Scope Verification:**
+- ✅ In scope: {ticket requirement → where in PR it is addressed}
+- ⚠️ Out of scope: {ticket requirement not addressed in PR}
+- ➕ Extra (not in ticket): {change present in PR but not in ticket}
+
+**Ambiguities, Edge Cases & Open Questions:**
+- ... (underspecified behavior / unanswered comment / conflicting requirement / missing edge case)
+- ... (empty input / permissions / error path / performance / backward compatibility / ...)
+- ...
+
+**Acceptance Criteria:**
+- {action to perform} → {expected result}
+- ...
+```
+
+Summary rules:
+- Concise, high-level, requirements-not-implementation — this is a requirements document, not a code review.
+- `Changes Overview` is 1-2 sentences.
+- `Impacted Areas` — meaningful bullets; omit the section if empty.
+- `Source of Truth` is required — tells downstream skills what to trust when sources disagree.
+- `Acceptance Criteria` — testable, user-oriented, written as "action → expected result". If no source-code behavior changed, replace this section with the explicit "not applicable" note from Step 5.
+- Omit empty sections instead of writing `None`/`N/A` — except the "no source code changed" note, which must be explicit.
+- Avoid generic statements like "code cleanup", "minor fixes", "various improvements" — name what changed or omit it.
+
+## References
+
+| Description | File |
+|-------------|------|
+| Filled example of the output summary | [summary-example.md](./references/summary-example.md) |
+| `.testeiya/` directory convention | `../scan-automation-project/SKILL.md` |
+| Code-focused PR analysis (companion skill) | `../pull-request-diff-analyzer/SKILL.md` |
+| Downstream: generate test cases from requirements | `../qa-write-test-cases/SKILL.md` |
+| Downstream: sync generated cases to Testomat.io | `../sync-test-cases-with-tms/SKILL.md` |

package/skills/testomatio/test-management/qa-pr-requirements-analyzer/references/summary-example.md

@@ -0,0 +1,54 @@
+# PR Requirements Summary — Example
+
+A filled-in example of the artifact produced by the `qa-pr-requirements-analyzer` skill.
+
+---
+
+## PR Requirements Summary
+
+**PR:** Add user export to CSV
+**Branch:** feature/PRJ-789-user-export → main
+**Type:** feature
+**Linked Tickets:** PRJ-789
+
+**Source of Truth:**
+- PR description: present (detailed, includes AC checklist and screenshot of the export modal)
+- Jira/GitHub ticket: resolved (PRJ-789)
+- Most reliable source: PR description + ticket (consistent, no conflicts)
+
+**Changes Overview:** Adds a CSV export action on the user list page that streams all currently filtered users to a downloadable file, with an email notification when exports exceed 10k rows.
+
+**Impacted Areas:**
+- User list page UI (new "Export" action).
+- User data export pipeline (CSV generation, streaming, email delivery).
+- Permission checks for export (admin-only).
+
+**High Level Key files (up to 5):**
+- `src/pages/UserList.tsx` — source
+- `src/services/ExportService.ts` — source
+- `src/api/export.ts` — source
+- `src/components/ExportModal.tsx` — source
+- `i18n/en.json` — config
+
+**Scope Verification:**
+- ✅ In scope: PRJ-789 AC1 (export button on the user list) — addressed in `src/pages/UserList.tsx` and `src/components/ExportModal.tsx`
+- ✅ In scope: PRJ-789 AC2 (admin-only) — addressed in `ExportService.ts` permission check
+- ⚠️ Out of scope: PRJ-789 AC3 (email notification for >10k exports) — no implementation found
+- ➕ Extra (not in ticket): i18n strings for German locale (`i18n/de.json`) — ticket only mentioned English
+
+**Ambiguities, Edge Cases & Open Questions:**
+- CSV column order not specified — needs product confirmation.
+- Concurrent exports by the same admin — no rate limiting or deduplication specified.
+- 50k+ user export (memory/timeout) — no performance budget in the ticket.
+- CSV date/time localization (UTC vs. user locale) — not specified.
+- Backward compatibility with existing scheduled exports (if any) — not addressed.
+
+**Acceptance Criteria:**
+- Admin opens user list with filters and clicks "Export" → modal appears with row count estimate
+- Admin starts export with <10k matching users → CSV downloads with columns `id, name, email, created_at` in that order
+- Non-admin opens user list → "Export" action is hidden (or returns 403 via API)
+- Admin triggers >10k user export → export is queued, email sent when ready *(NOT IMPLEMENTED — see Scope Verification)*
+- User without email is included → email field is empty string in CSV
+- Empty filtered list → button disabled OR empty CSV with header only
+- 50k+ user export completes without server timeout or OOM
+- German admin sees the export modal translated

package/skills/testomatio/test-management/qa-requirement-reviewer/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: qa-requirement-reviewer
+description: Review requirements before development. Identify ambiguity, missing information, contradictions, unclear acceptance criteria, logical gaps, edge cases, and testability issues. Determine whether the requirements are sufficiently clear for development and QA. Use this skill when a user provides requirements (BRD, user story, use case, feature ticket, specification, or prose) and asks for feedback, validation, review, or readiness assessment before implementation.
+license: MIT
+metadata:
+  author: Testomat.io
+  version: 1.0.0
+---
+
+# QA Requirement Reviewer
+
+Review requirements as written. Report issues, gaps, risks, and open questions so stakeholders can decide whether the requirements are ready for development and testing.
+
+Rules:
+- **Work with the input as-is — do not rewrite it.**
+- **Do not make assumptions or silently fill in missing information.**
+- Suggest improved wording or acceptance criteria where useful.
+- **Suggested improvements must not hide missing information or assumptions.**
+- Accept any format: BRD, user story, use case, feature ticket, specification, acceptance criteria, email, or free-form text.
+
+## Review Criteria
+
+Evaluate each requirement against:
+
+| Criterion      | What it means             | Failure signals |
+| -------------- | ------------------------- | --------------- |
+| **Atomic**     | Describes a single behavior, rule, or capability | Multiple behaviors combined in one requirement; difficult to verify independently           |
+| **Clear**      | Meaning is understandable and specific           | Vague language, undefined terms, subjective wording, multiple possible interpretations      |
+| **Complete**   | Contains enough information for implementation and testing | Missing business rules, acceptance criteria, inputs, outputs, error handling, or edge cases |
+| **Consistent** | Does not conflict with related requirements      | Contradictory behavior, terminology, workflows, rules, or constraints                       |
+| **Testable**   | Can be objectively verified                      | No measurable outcome, unclear success criteria, impossible to determine pass or fail       |
+
+## Workflow
+
+### Step 1: Gather Requirements
+
+Accept requirements as:
+- A document or file.
+- A directory, repository, or collection of documents and files.
+- Raw text provided in the conversation.
+
+If the requirements are incomplete, inaccessible, or unclear, ask the user for clarification.
+
+### Step 2: Identify Requirements
+
+- Identify individual requirements, rules, behaviors, and acceptance criteria.
+- Assign identifiers where helpful (`R1`, `R2`, ...), or reuse existing IDs.
+- Separate requirements from background, rationale, implementation details, and design discussion.
+
+### Step 3: Review Each Requirement
+
+Evaluate each requirement against the review criteria. For each issue found:
+1. Identify the affected requirement.
+2. Explain the issue and its consequence.
+3. Classify it (clarity, completeness, consistency, testability, etc.).
+4. Ask the clarification question needed to resolve it.
+5. Optionally suggest improved wording.
+
+### Step 4: Review the Requirement Set
+
+Evaluate the requirements as a whole for:
+- Missing requirements, scenarios, or business rules.
+- Missing acceptance criteria or expected outcomes.
+- Missing actors, roles, states, dependencies, or constraints.
+- Missing edge cases, alternative flows, or error conditions.
+- Contradictions, overlaps, or inconsistencies between requirements.
+
+### Step 5: Produce the Review Report
+
+Use this exact structure:
+
+```markdown
+## Requirements Review
+
+### Readiness Assessment
+
+**Decision:** ✅ Ready for Development | ⚠️ Needs Clarification | ❌ Not Ready
+
+**Summary:** ... (Brief assessment of overall requirement quality and readiness. 1-3 sentence verdict)
+
+### Key Findings
+
+| Requirement | Issue Type   | Finding | Question / Recommendation |
+| ----------- | ------------ | ------- | ------------------------- |
+| R1          | Completeness | ...     | ...                       |
+| R2          | Clarity      | ...     | ...                       |
+
+(**Consolidation "Key Findings" table rule:** When multiple findings share the same "Issue Type" for one requirement, use numbered lists within Finding and Question/Recommendation columns to match issues by number (e.g., `1. Finding 1 2. Finding 2 | 1. Question 1 2. Question 2`). This avoids duplicate rows and keeps the table compact while preserving 1:1 correspondence)
+
+### Ambiguities & Open Questions
+
+* ...
+* ...
+
+(Bullet list of Questions that should be answered before approval, implementation, or testing)
+
+### Gaps & Issues
+
+* ...
+* ...
+
+(Missing information, scenarios, business rules, constraints, dependencies, edge cases, or error conditions)
+
+### Acceptance Criteria Review (optional)
+
+* Assess whether acceptance criteria are clear, complete, and testable.
+* Identify missing acceptance criteria where needed.
+
+(Include **only if acceptance criteria exist** or are expected)
+
+### Risks & Impact
+
+* ...
+* ...
+
+(Potential consequences of proceeding without clarification).
+
+### Recommendation
+
+... (Recommended next action before approval or implementation)
+
+```
+
+## Examples
+
+See `references/requirements_reviewer_examples.md` for two worked examples: a flawed draft BRD and a set of user stories, each with input and review output.

package/skills/testomatio/test-management/qa-requirement-reviewer/references/requirements_reviewer_examples.md

@@ -0,0 +1,128 @@
+# Requirements Review — Examples
+
+A small, deliberately flawed draft — the kind of thing that lands in review — turned into a requirements review. The input has loose structure and mixed quality; the review works with it as-is and does not rewrite it.
+
+## Example 1: Draft BRD
+
+### Input (draft BRD excerpt)
+
+```
+Search Feature — Business Requirements (draft)
+
+1. The search must be fast and return relevant results.
+2. Users can search by keyword and filter by date, and results should be exportable.
+3. The system should handle a large number of users.
+4. Search results are stored for reporting.
+```
+
+### Output
+
+```markdown
+## Requirements Review
+
+### Readiness Assessment
+
+**Decision:** ❌ Not Ready
+
+**Summary:** None of the four requirements is testable as written. R1 lacks a measurable threshold, R2 bundles three separate behaviors, and the set has no error-path coverage or acceptance criteria.
+
+### Key Findings
+
+| Requirement | Issue Type   | Finding | Question / Recommendation |
+| ----------- | ------------ | ------- | ------------------------- |
+| R1          | Testability  | "fast" has no measurable threshold | What is the maximum acceptable response time, and at what data volume? |
+| R2          | Atomicity    | Three behaviors combined (search, filter, export) | Split into separate requirements for keyword search, date filter, and export |
+| R3          | Clarity      | "large number of users" is undefined | What concurrent-user count must search support? |
+| R4          | Completeness | Storage scope and retention not defined | What exactly is stored, for how long, and who can see it? |
+
+### Ambiguities & Open Questions
+
+* R1: What is the maximum acceptable response time, and at what data volume?
+* R2: Should this be three separate requirements (keyword search, date filter, export)?
+* R3: What concurrent-user count must search support?
+* R4: What exactly is stored, for how long, and who can see it?
+
+### Gaps & Issues
+
+* R1: No measurable threshold for "fast"
+* R2: Compound requirement — three behaviors cannot pass/fail independently
+* R3: "Large number of users" has no target
+* R4: Storage scope and retention not defined
+* No error-state or empty-state behavior defined across all requirements
+
+### Acceptance Criteria Review
+
+No acceptance criteria found. Suggest:
+- Response time: Search should return results within 1 second for queries under 50 characters
+- Recall: Top results match expected set for known queries
+- Empty state: Display "No results found" message when search returns zero matches
+- Error state: Handle special characters and empty queries gracefully
+
+### Risks & Impact
+
+* Implementation risk: Medium — ambiguous performance targets may lead to rework
+* Testing risk: High — no measurable acceptance criteria blocks test case design
+* Business impact risk: Low — core functionality is defined but not verifiable
+
+### Recommendation
+
+Resolve all open questions before approval. Add measurable acceptance criteria to each requirement. Split compound requirement R2 into atomic requirements.
+```
+
+## Example 2: User Stories
+
+### Input (user stories)
+
+```
+As a user, I want to search for products by name so I can find what I'm looking for.
+As a user, I want to filter search results by category so I can narrow down choices.
+As a user, I want to export search results to PDF so I can share them with others.
+```
+
+### Output
+
+```markdown
+## Requirements Review
+
+### Readiness Assessment
+
+**Decision:** ⚠️ Needs Clarification
+
+**Summary:** Stories are well-structured and pass most criteria. Minor clarification needed on export scope and empty-state behavior before approval.
+
+### Key Findings
+
+| Requirement | Issue Type   | Finding | Question / Recommendation |
+| ----------- | ------------ | ------- | ------------------------- |
+| US1         | Completeness | 1. No empty-state behavior defined | 1. What should the user see when search returns zero results? |
+| US2         | Completeness | 1. No error-state behavior defined | 1. How are invalid filter values handled? |
+| US3         | Clarity      | 1. Export scope and format not fully specified | 1. Should export include current page or full result set? |
+
+### Ambiguities & Open Questions
+
+* Export: Which format(s) — PDF only? What content — current page or full result set?
+* Empty search results: What should the user see?
+* Invalid input (special characters, empty query): How is this handled?
+
+### Gaps & Issues
+
+* No error-state or empty-state behavior defined across all stories
+* Export: scope (page vs all results) and format not specified
+
+### Acceptance Criteria Review
+
+No formal acceptance criteria present. Suggest:
+- Search returns results within 500ms for queries under 50 characters
+- Filter reduces result set to only matching category
+- Export produces valid PDF containing full result set (or specify page vs all)
+
+### Risks & Impact
+
+* Implementation risk: Low — stories are independent and estimable
+* Testing risk: Medium — export scope ambiguity may cause rework
+* Business impact risk: Low — core search value is clear
+
+### Recommendation
+
+Clarify export scope and add empty-state acceptance criteria. Otherwise ready for sprint planning.
+```

package/skills/testomatio/test-management/qa-split-testing-levels-pyramid/SKILL.md

@@ -0,0 +1,55 @@
+---
+name: qa-split-testing-levels-pyramid
+description: Apply the testing pyramid to a feature — divide test scenarios across levels (unit, integration, e2e), assign each scenario to the cheapest sufficient level, and produce a coverage split per level. Use when asked "unit, integration or e2e?", "what level should this test be?", "how should we test this feature?", "what test coverage do we need?", or to apply the test pyramid to a feature or project.
+license: MIT
+metadata:
+  author: Testomat.io
+  version: 1.0.0
+---
+
+# QA Split Testing Levels — Test Pyramid
+
+Applies the testing pyramid to a feature: each scenario goes to the cheapest level that can still catch its failure.
+Input: a feature description, or risk scenarios from a prior QA analysis.
+
+## Testing levels
+
+Default layers, bottom to top:
+
+- **unit + integration**
+- **e2e**
+- **manual**
+
+A layer can hold several kinds of tests with separate runners: `e2e api` / `e2e web` / `e2e mobile`.
+Other testing layers a project may have instead: component, functional, contract, visual.
+**Take the testing layers and kinds from the project; use the default only when the scan finds nothing.**
+
+## Workflow
+
+1. Inventory existing tests with the `scan-automation-project` skill.
+2. Detect the project's testing layers and the kinds of tests inside them.
+3. Assign each scenario to the lowest layer that catches its failure, and to a kind within it.
+4. Recommend a coverage split per layer and kind.
+
+## Rules
+
+- Do not recommend manual verification for scenarios already covered by automated tests.
+- Explain why a scenario cannot sit at a lower layer when assigning it upward.
+- A kind never covers another kind of the same layer: `e2e web` does not cover `e2e api`.
+- Generalize existing automated scenarios; expand only when the user asks.
+
+## Output
+
+- Section `📐 Testing levels`: the layers and kinds used, when they differ from the default.
+- Section `☑️ What is already tested`: number and scope of existing tests per layer and kind.
+- Section `🧪 Testing plan`: scenario → layer and kind (`e2e / api`), with reasoning.
+- When the environment can render charts, add a pie chart or test pyramid: test count and share per layer and kind. Skip the diagram in plain terminal output.
+- For manual items: how to verify (`action → expected result`).
+
+## Next actions
+
+Offer after the plan:
+
+- Write manual test cases or a checklist → `qa-write-test-cases` skill.
+- Automate manual cases into autotests → `automate-manual-test-cases` skill.
+- Map tests to source files for change-aware runs → `qa-test-code-coverage` skill.