qa-skills 3.0.0 → 3.1.0

package/skills/qa-browser-data-collector/references/playwright-mcp-patterns.md

@@ -1,113 +0,0 @@
-# Playwright MCP Patterns for Data Collection
-
-Common patterns for using Playwright MCP to collect browser data. Adapt tool names to the specific Playwright MCP server in use (e.g., `@playwright/mcp`, cursor-ide-browser).
-
-## Navigation
-
-| Goal | Pattern |
-|------|---------|
-| Open URL | `browser_navigate` or `playwright_navigate` with target URL |
-| New tab | Use `newTab: true` or equivalent when opening a new context |
-| Back/forward | `browser_navigate_back`, `browser_navigate_forward` |
-| Reload | `browser_reload` after state changes |
-
-**Best practice:** Lock the browser before a sequence of actions; unlock when done to avoid user interference.
-
-## Snapshots
-
-| Goal | Pattern |
-|------|---------|
-| Page structure | `browser_snapshot` — returns accessibility tree (headings, landmarks, interactive elements) |
-| Interactive only | Use `interactive: true` to filter to clickable/focusable elements |
-| Scoped snapshot | Use `selector` to snapshot a subtree (e.g., a form or modal) |
-| Compact output | Use `compact: true` for smaller payloads |
-
-**Best practice:** Take a snapshot after each navigation and after modals open. Use snapshots as the primary source for form fields, links, and buttons.
-
-## Waiting
-
-| Goal | Pattern |
-|------|---------|
-| Fixed delay | `browser_wait_for` with `time` (seconds) |
-| Text appears | `browser_wait_for` with `text` and optional `timeout` |
-| Text disappears | `browser_wait_for` with `textGone` |
-
-**Best practice:** Prefer short incremental waits (1–3 seconds) with snapshot checks rather than one long wait. Proceed as soon as content is ready.
-
-## Form Inspection
-
-| Goal | Pattern |
-|------|---------|
-| Read input value | `browser_get_input_value` with element ref from snapshot |
-| Check checkbox/radio | `browser_is_checked` |
-| List options | Use snapshot with `selector` on `<select>` to see options |
-| Trigger validation | `browser_click` submit with empty/invalid data; capture error text from snapshot |
-
-**Best practice:** Do not submit forms with real data. Use placeholders or leave empty to trigger validation only.
-
-## Network Interception
-
-| Goal | Pattern |
-|------|---------|
-| List requests | `browser_network_requests` — returns requests since page load |
-| Filter by type | Inspect returned list for XHR, fetch, document |
-| Capture timing | Note request/response timing if available |
-
-**Best practice:** Start network capture (or ensure it's active) before navigating. Re-navigate if needed to get a clean request list.
-
-## Screenshots
-
-| Goal | Pattern |
-|------|---------|
-| Viewport | `browser_take_screenshot` |
-| Full page | Use `fullPage: true` if supported |
-| Element | Use `ref` or `selector` for element-specific screenshots |
-
-**Best practice:** Take screenshots after key state changes (e.g., after login, after modal open).
-
-## Element Interaction (Read-Only)
-
-| Goal | Pattern |
-|------|---------|
-| Click (e.g., open modal) | `browser_click` with ref from snapshot |
-| Hover | `browser_hover` to reveal tooltips or dropdowns |
-| Scroll into view | `browser_scroll` with `scrollIntoView: true` before interacting |
-| Read attribute | `browser_get_attribute` for href, aria-*, data-* |
-
-**Best practice:** Use interactions only to reveal data (open modals, expand sections). Do not submit forms or change persistent data.
-
-## Lock/Unlock Workflow
-
-1. Navigate to the page (or use existing tab).
-2. Call `browser_lock` before a sequence of automated actions.
-3. Perform snapshot, network capture, form inspection, screenshots.
-4. Call `browser_unlock` when done.
-
-## Typical Collection Sequence
-
-```
-1. browser_navigate(url)
-2. browser_wait_for(time: 2)
-3. browser_snapshot()
-4. browser_network_requests()
-5. [For each form] Inspect snapshot for fields; optionally trigger validation
-6. [For modals] browser_click(trigger) → wait → snapshot
-7. browser_take_screenshot()
-8. browser_unlock()
-```
-
-## Tool Name Mapping
-
-If using a different Playwright MCP implementation, map concepts:
-
-| Concept | cursor-ide-browser | @playwright/mcp (typical) |
-|---------|--------------------|---------------------------|
-| Navigate | browser_navigate | playwright_navigate / goto |
-| Snapshot | browser_snapshot | accessibility_snapshot / getTree |
-| Wait | browser_wait_for | wait_for_selector / wait |
-| Network | browser_network_requests | network_requests / har |
-| Screenshot | browser_take_screenshot | screenshot |
-| Click | browser_click | click |
-| Lock | browser_lock | (session-scoped) |
-
-Refer to your MCP server's documentation for exact tool names and parameters.

package/skills/qa-bug-ticket-creator/SKILL.md

@@ -1,148 +0,0 @@
----
-name: qa-bug-ticket-creator
-description: Generate structured bug reports from test failures with expected/actual results, reproduction steps, evidence, severity/priority, and auto-create GitHub Issues via GitHub MCP with duplicate detection.
-output_dir: docs/bug-tickets
-dependencies:
-  recommended:
-    - qa-task-creator
-    - qa-github-issues-enhanced
----
-
-# QA Bug Ticket Creator
-
-## Purpose
-
-Create structured bug reports from test failures, manual findings, or defect descriptions. Transform raw failure data into ISO 29119-3 compliant incident reports and auto-create GitHub Issues via GitHub MCP with duplicate detection and smart assignment.
-
-## Primary Target
-
-**GitHub Issues** via GitHub MCP. Extensible to Jira, Linear, Azure DevOps via adapters (see `references/` for future patterns).
-
-## Bug Report Template
-
-Every bug report includes:
-
-| Field | Description |
-| ----- | ----------- |
-| **Title** | Concise, actionable summary (e.g., "Login fails when password contains special chars") |
-| **Expected Result** | What should happen per spec/requirements |
-| **Actual Result** | What actually happens |
-| **Steps to Reproduce** | Numbered, minimal steps |
-| **Environment** | OS, browser, app version, test framework |
-| **Evidence** | Screenshots, logs, stack traces, HAR files |
-| **Severity** | Blocker / Critical / Major / Minor / Trivial |
-| **Priority** | P1–P5 or equivalent |
-| **Component/Module** | Affected area (e.g., auth, checkout, API) |
-
-See `references/bug-report-format.md` for detailed format and examples.
-
-## Auto-Assignment
-
-When creating GitHub Issues, auto-assign based on component:
-
-- **Labels** — Map component to labels (e.g., `auth`, `frontend`, `api`)
-- **Milestones** — Map to sprint/release milestone when provided
-- **Assignees** — Map component to team member when mapping is configured
-
-## Duplicate Detection
-
-Before creating a new issue:
-
-1. **Search** existing open issues via GitHub MCP (search by title keywords, component, error message)
-2. **Compare** — If similar issue exists (same failure, same component, same root cause), link to it instead of creating duplicate
-3. **Create** — Only create new issue when no suitable duplicate found
-
-## ISO 29119-3 Compliance
-
-Structure aligns with ISO/IEC/IEEE 29119-3 incident report:
-
-- Incident identifier
-- Summary and description
-- Expected vs actual results
-- Steps to reproduce
-- Severity and priority
-- Status and lifecycle
-- Related test cases / requirements
-
-## Pairing with qa-task-creator
-
-When a bug is created, optionally auto-create a linked **fix task** via qa-task-creator:
-
-- Bug → Fix task (development)
-- Bug → Verification task (QA re-test)
-
-See `references/linking-patterns.md` in qa-task-creator for patterns.
-
-## Trigger Phrases
-
-- "Create bug report from [test failure / JUnit output / error log]"
-- "File a GitHub issue for this failure"
-- "Generate bug ticket from Playwright/pytest/Jest failure"
-- "Incident report for [defect description]"
-- "Check for duplicate before creating bug"
-- "Bug report with severity and priority"
-
-## Workflow
-
-1. **Input** — Test failure (JUnit, Playwright, pytest output), manual description, or error log
-2. **Parse** — Extract test name, failure message, stack trace, environment
-3. **Structure** — Map to bug report template; assign severity/priority per `references/severity-guide.md`
-4. **Duplicate check** — Search GitHub Issues for similar open issues
-5. **Create or link** — Create new issue or comment on duplicate with additional context
-6. **Optional** — Invoke qa-task-creator for linked fix task
-
-## Integrations
-
-| Integration | Use |
-| ----------- | --- |
-| **GitHub MCP** | Create issues, search for duplicates, add labels/milestones/assignees |
-| **qa-task-creator** | Create linked fix/verification tasks |
-| **qa-test-reporter** | Consume failure data from aggregated reports |
-
-## Scope
-
-**Can do (autonomous):**
-- Parse test failures from JUnit XML, Playwright JSON, pytest output, or free-text description
-- Generate structured bug reports per template
-- Search GitHub for duplicate issues before creating
-- Create GitHub Issues with full body, labels, milestones
-- Assign severity/priority per `references/severity-guide.md`
-- Invoke qa-task-creator for linked fix tasks when requested
-
-**Cannot do (requires confirmation):**
-- Create issues in repos without write access
-- Override user-specified severity/priority
-- Assign assignees without configured mapping
-
-**Will not do (out of scope):**
-- Modify production code or test code
-- Close or resolve issues (user/stakeholder responsibility)
-- Create issues in Jira/Linear/Azure DevOps (future adapter; use references)
-
-## Quality Checklist
-
-- [ ] Bug report includes all template fields (title, expected/actual, steps, environment, evidence)
-- [ ] Severity and priority assigned per `references/severity-guide.md`
-- [ ] Duplicate search performed before creating new issue
-- [ ] GitHub Issue body formatted for readability (headers, code blocks, lists)
-- [ ] Labels and component correctly mapped
-- [ ] No hardcoded secrets; repo/org from user input or env
-- [ ] ISO 29119-3 incident structure present where applicable
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-| ------- | ------------ | --- |
-| GitHub MCP create fails | Token missing, no repo access | Check `GITHUB_PERSONAL_ACCESS_TOKEN`; verify repo permissions |
-| Duplicate not detected | Search query too narrow | Broaden keywords; search by component + error snippet |
-| Severity wrong | Default mapping doesn't fit project | Use project-specific severity guide; ask user to confirm |
-| Missing stack trace | Parser doesn't support format | Add parser for framework; request raw output from user |
-| Issue body truncated | GitHub body length limit | Split evidence into comments or attach as file |
-| Wrong labels applied | Component mapping missing | Add component→label mapping; ask user for mapping |
-
-## Reference Files
-
-| Topic | File |
-| ----- | ---- |
-| Bug report format with examples | `references/bug-report-format.md` |
-| Severity and priority classification | `references/severity-guide.md` |

package/skills/qa-bug-ticket-creator/references/bug-report-format.md

@@ -1,149 +0,0 @@
-# Bug Report Format Reference
-
-*Detailed format for structured bug reports per ISO 29119-3 incident report structure.*
-
----
-
-## Template Structure
-
-### 1. Title
-
-- **Format:** `[Component] Brief description of the failure`
-- **Example:** `[Auth] Login fails when password contains special characters`
-- **Rules:** Concise, actionable, no jargon; include component when known
-
-### 2. Expected Result
-
-- What **should** happen per specification, requirements, or design
-- Reference requirement/spec ID when available
-- **Example:** "User should be able to log in with a password containing `!@#$%^&*()` per REQ-AUTH-001"
-
-### 3. Actual Result
-
-- What **actually** happens
-- Include error messages, HTTP status codes, UI state
-- **Example:** "Login returns 500 Internal Server Error; UI shows 'Something went wrong'"
-
-### 4. Steps to Reproduce
-
-- Numbered, minimal steps
-- Include test data (e.g., username, input values) when relevant
-- **Example:**
-  1. Navigate to /login
-  2. Enter username `test@example.com`
-  3. Enter password `P@ssw0rd!`
-  4. Click "Sign In"
-
-### 5. Environment
-
-| Field | Example |
-| ----- | ------- |
-| OS | Windows 11, macOS 14, Ubuntu 22.04 |
-| Browser/App | Chrome 120, Firefox 121, Safari 17 |
-| App Version | 2.3.1 |
-| Test Framework | Playwright 1.40, pytest 7.4 |
-
-### 6. Evidence
-
-- **Screenshots** — UI state, error dialogs
-- **Logs** — Application logs, test runner output
-- **Stack traces** — Full trace for exceptions
-- **HAR / Network** — When API or network-related
-
-Use code blocks for logs and stack traces:
-
-```text
-AssertionError: Expected status 200, got 500
-  at LoginPage.submit (login.spec.ts:42)
-  at test (login.spec.ts:38)
-```
-
-### 7. Severity
-
-See `references/severity-guide.md` for classification.
-
-### 8. Priority
-
-P1 (Critical) through P5 (Low) or equivalent.
-
-### 9. Component/Module
-
-- Affected area: `auth`, `checkout`, `api`, `frontend`, `backend`, etc.
-- Used for labels, routing, and duplicate search
-
----
-
-## Example: Full Bug Report (Markdown)
-
-```markdown
-## [Auth] Login fails when password contains special characters
-
-### Expected Result
-User should be able to log in with a password containing special characters `!@#$%^&*()` per REQ-AUTH-001.
-
-### Actual Result
-Login returns HTTP 500; UI displays "Something went wrong". No error details shown to user.
-
-### Steps to Reproduce
-1. Navigate to https://app.example.com/login
-2. Enter username: `test@example.com`
-3. Enter password: `P@ssw0rd!`
-4. Click "Sign In"
-
-### Environment
-- OS: Windows 11
-- Browser: Chrome 120
-- App Version: 2.3.1
-- Test: Playwright 1.40
-
-### Evidence
-```
-POST /api/auth/login → 500 Internal Server Error
-Response: {"error":"Internal server error"}
-
-Stack trace:
-  at AuthService.login (auth.service.ts:45)
-  at LoginController.handle (login.controller.ts:22)
-```
-
-### Severity
-**Major** — Core functionality affected; workaround exists (avoid special chars)
-
-### Priority
-P2
-
-### Component
-auth
-```
-
----
-
-## Mapping from Test Failure Formats
-
-### JUnit XML
-
-| JUnit Field | Bug Report Field |
-| ----------- | ---------------- |
-| `testcase.name` | Title (sanitized) |
-| `testcase.classname` | Component (derived) |
-| `failure.message` | Actual result |
-| `failure` (text) | Evidence (stack trace) |
-| `testsuite.name` | Component / Module |
-
-### Playwright JSON
-
-| Playwright Field | Bug Report Field |
-| ---------------- | ---------------- |
-| `test.title` | Title |
-| `test.file` | Component (from path) |
-| `result.error.message` | Actual result |
-| `result.error.stack` | Evidence |
-| `attachments` | Evidence (screenshots, traces) |
-
-### pytest
-
-| pytest Field | Bug Report Field |
-| ------------ | ---------------- |
-| `nodeid` | Title, Component |
-| `longrepr` | Actual result, Evidence |
-| `call` (traceback) | Evidence |

package/skills/qa-bug-ticket-creator/references/severity-guide.md

@@ -1,81 +0,0 @@
-# Severity and Priority Classification Guide
-
-*Reference for assigning severity and priority to bug reports.*
-
----
-
-## Severity (Impact)
-
-Severity reflects the **impact** of the defect on the system or user.
-
-| Severity | Definition | Examples |
-| -------- | ---------- | -------- |
-| **Blocker** | System unusable; blocks testing or deployment | App crashes on launch, login completely broken, data loss |
-| **Critical** | Major feature broken; no workaround | Checkout fails for all users, API returns 500 for core endpoint |
-| **Major** | Significant feature impaired; workaround exists | Login fails with special chars, search returns wrong results |
-| **Minor** | Small defect; limited impact | Typo, minor UI misalignment, non-critical validation |
-| **Trivial** | Cosmetic or negligible | Font size off by 1px, redundant message |
-
-### Severity Decision Tree
-
-1. **Blocks deployment or testing?** → Blocker
-2. **Core feature completely broken?** → Critical
-3. **Core feature impaired with workaround?** → Major
-4. **Non-core feature affected?** → Minor
-5. **Cosmetic only?** → Trivial
-
----
-
-## Priority (Urgency)
-
-Priority reflects **when** the defect should be fixed (business/urgency).
-
-| Priority | Definition | Typical Use |
-| -------- | ---------- | ----------- |
-| **P1** | Fix immediately | Production down, security vulnerability |
-| **P2** | Fix in current sprint | Critical for release |
-| **P3** | Fix in next sprint | Important but not blocking |
-| **P4** | Fix when possible | Low impact |
-| **P5** | Backlog / wishlist | Trivial, nice-to-have |
-
-### Priority vs Severity
-
-- **High severity** usually implies **high priority**, but not always
-  - Example: Blocker in deprecated feature → P3
-- **Low severity** can be **high priority**
-  - Example: Legal/compliance typo → P1
-
----
-
-## Default Mapping (Test Failures)
-
-When deriving from test failures without explicit user input:
-
-| Failure Type | Default Severity | Default Priority |
-| ------------ | ---------------- | ----------------- |
-| E2E test failure (core flow) | Major | P2 |
-| E2E test failure (edge flow) | Minor | P3 |
-| Unit test failure | Major | P2 |
-| API test failure (4xx/5xx) | Critical if 5xx, Major if 4xx | P2 |
-| Visual regression | Minor | P3 |
-| Accessibility failure | Major (WCAG) | P2 |
-| Performance threshold breach | Major | P2 |
-
-Override when user provides explicit severity/priority.
-
----
-
-## Component → Label Mapping (GitHub)
-
-Suggested label mapping by component:
-
-| Component | Labels |
-| --------- | ------ |
-| auth | `bug`, `auth`, `security` |
-| api | `bug`, `api`, `backend` |
-| frontend | `bug`, `frontend`, `ui` |
-| checkout | `bug`, `checkout`, `critical` |
-| search | `bug`, `search` |
-| mobile | `bug`, `mobile` |
-
-Customize per project; store in skill config or user input.

package/skills/qa-bug-ticket-creator/templates/bug-ticket-template.md

@@ -1,39 +0,0 @@
-# Bug Report
-
-## [BUG-{ID}] {Title}
-
-**Severity:** {Blocker | Critical | Major | Minor | Trivial}
-**Priority:** {P1 | P2 | P3 | P4 | P5}
-**Component:** {component name}
-**Environment:** {browser, OS, version, URL}
-**Reporter:** {name}
-**Assignee:** {name or unassigned}
-**Date:** {YYYY-MM-DD}
-
-## Description
-{Brief description of the bug}
-
-## Steps to Reproduce
-1. {Step 1}
-2. {Step 2}
-3. {Step 3}
-
-## Expected Result
-{What should happen}
-
-## Actual Result
-{What actually happens}
-
-## Evidence
-- Screenshots: {attach or path}
-- Logs: {relevant log output}
-- Video: {link if available}
-
-## Additional Context
-- Related requirement: [REQ-{ID}]
-- Related test case: [TC-{ID}]
-- Regression: {Yes/No}
-- Frequency: {Always | Sometimes | Rarely | Once}
-
-## Labels
-`type/bug` `priority/{level}` `component/{name}`

package/skills/qa-changelog-analyzer/SKILL.md

@@ -1,134 +0,0 @@
----
-name: qa-changelog-analyzer
-description: Analyze git diff and commit history to recommend which tests to add, update, or run based on code changes.
-output_dir: reports/changelog
----
-
-# QA Changelog Analyzer
-
-## Purpose
-
-Analyze code changes (git diff, commit history, branch comparisons) to determine testing impact. Map changed files to modules/components, identify affected tests, and produce actionable recommendations: **tests to run** (regression scope), **tests to update** (if source changed), and **tests to add** (if new code uncovered).
-
-## Trigger Phrases
-
-- "What tests should I run for this PR?"
-- "Analyze git diff for test impact"
-- "Changelog analysis" / "Change impact report"
-- "Which tests are affected by [branch/commit]?"
-- "Recommend regression scope for [changes]"
-- "Tests to add/update for recent commits"
-
-## Workflow
-
-1. **Read git diff** — Staged (`git diff --cached`), committed (`git diff HEAD~1..HEAD`), or between branches (`git diff base..HEAD`)
-2. **Map changed files to modules** — Use directory structure, package/import conventions, or config (see `references/git-analysis-patterns.md`)
-3. **Identify affected test files** — Coverage-based, path-based, or import-based mapping
-4. **Recommend:**
-   - **Tests to run** — Regression scope (must run, should run, optional)
-   - **Tests to update** — If source changed and tests may be outdated
-   - **Tests to add** — If new code has no coverage
-
-## Change Analysis
-
-| Change Type | Action | Recommendation |
-|-------------|--------|-----------------|
-| **New files** | Need new tests | Add unit/integration tests; flag for qa-task-creator |
-| **Modified files** | Check existing coverage | Run existing tests; update if assertions/source diverged |
-| **Deleted files** | Remove/update related tests | Remove obsolete tests; update imports in remaining tests |
-| **Renamed/moved files** | Update imports in tests | Fix import paths; run affected tests |
-| **Config changes** | Validate environment | Run env-specific/smoke tests; verify config loading |
-
-See `references/impact-mapping.md` for mapping strategies.
-
-## Output Deliverables
-
-1. **Change Impact Report** — Summary of changed files, modules affected, and impact level
-2. **Recommended Regression Scope** — Must run / Should run / Optional test lists
-3. **Task Suggestions for qa-task-creator** — Add tests, update tests, remove obsolete tests
-
-### Change Impact Report Template
-
-```markdown
-# Change Impact Report — [Branch/PR/Commit]
-
-## Summary
-| Change Type | Count | Modules Affected |
-|-------------|-------|------------------|
-| Added | N | [list] |
-| Modified | N | [list] |
-| Deleted | N | [list] |
-
-## Regression Scope
-
-### Must Run (High Impact)
-- [test file paths]
-
-### Should Run (Medium Impact)
-- [test file paths]
-
-### Optional (Low Impact)
-- [test file paths]
-
-## Task Suggestions
-- **Add:** [new modules/files needing tests]
-- **Update:** [tests that may need assertion/import updates]
-- **Remove:** [obsolete tests for deleted code]
-```
-
-## Integration with Other Skills
-
-| Need | Skill | Usage |
-|------|-------|-------|
-| Create tasks from recommendations | qa-task-creator | Pass task suggestions for add/update/remove |
-| Coverage data for mapping | qa-coverage-analyzer | Which tests cover changed files |
-| Risk prioritization | qa-risk-analyzer | Combine with risk scores for regression order |
-| Git diff patterns | — | `references/git-analysis-patterns.md` |
-| Impact mapping | — | `references/impact-mapping.md` |
-
-## Scope
-
-**Can do (autonomous):**
-- Parse git diff (staged, committed, between branches)
-- Map changed files to modules/components
-- Identify affected test files (path, import, or coverage-based)
-- Produce change impact report and regression scope
-- Generate task suggestions for qa-task-creator
-
-**Cannot do (requires confirmation):**
-- Run tests or generate coverage (consume existing data)
-- Modify source or test code
-- Exclude files from analysis without justification
-
-**Will not do (out of scope):**
-- Execute tests or deployments
-- Modify git history or branches
-- Override project-specific mapping without config
-
-## Quality Checklist
-
-- [ ] Git diff correctly parsed (staged/committed/branch)
-- [ ] Changed files mapped to modules
-- [ ] Affected tests identified (path, import, or coverage)
-- [ ] Regression scope categorized (must/should/optional)
-- [ ] Task suggestions actionable for qa-task-creator
-- [ ] No hardcoded paths; respect project structure
-- [ ] Config changes flagged for env validation
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-|---------|--------------|-----|
-| No changed files | Wrong diff range or branch | Verify `git diff` range; check branch names |
-| Module mapping empty | Unclear structure | Use directory convention; add `impact-mapping` config |
-| Too many tests in scope | Broad imports or coverage | Narrow to direct tests first; use risk prioritization |
-| Missing coverage data | qa-coverage-analyzer not run | Use path/import mapping as fallback |
-| Renamed files not detected | Git rename detection off | Use `git diff -M` or `--find-renames` |
-| Config changes missed | Only tracking source files | Include config paths in analysis (e.g. `.env`, `config/`) |
-
-## Reference Files
-
-| Topic | Reference |
-|-------|-----------|
-| Git diff parsing, file-to-module mapping | `references/git-analysis-patterns.md` |
-| Mapping code changes to test recommendations | `references/impact-mapping.md` |