qa-skills 3.0.0 → 3.1.0

package/skills/qa-github-issues-enhanced/references/label-taxonomy.md

@@ -1,130 +0,0 @@
-# Label Taxonomy for QA GitHub Issues
-
-*Complete label taxonomy with naming conventions and color codes for GitHub Issues.*
-
----
-
-## Naming Conventions
-
-- **Prefix format**: `category/value` (e.g., `type/bug`, `priority/high`)
-- **Flat labels**: Use for simple tags without hierarchy (e.g., `needs-triage`, `verified`)
-- **Lowercase**: All labels use lowercase with hyphens
-- **Consistent**: Same prefix for same category across all labels
-
----
-
-## Type Labels (`type/`)
-
-| Label | Color | Description |
-| ----- | ----- | ----------- |
-| `type/bug` | `#d73a4a` (red) | Defect or incorrect behavior |
-| `type/enhancement` | `#a2eeef` (cyan) | New feature or improvement |
-| `type/task` | `#7f8c8d` (gray) | Work item, chore, or maintenance |
-| `type/documentation` | `#0075ca` (blue) | Docs, specs, or README updates |
-| `type/test-coverage-gap` | `#fbca04` (yellow) | Missing or insufficient test coverage |
-| `type/flaky-test` | `#f9d0c4` (light red) | Intermittent or unreliable test |
-| `type/security` | `#ee0701` (dark red) | Security vulnerability or hardening |
-
----
-
-## Priority Labels (`priority/`)
-
-| Label | Color | Description |
-| ----- | ----- | ----------- |
-| `priority/critical` | `#b60205` (dark red) | Fix immediately; blocks release |
-| `priority/high` | `#d93f0b` (orange-red) | Fix in current sprint |
-| `priority/medium` | `#fbca04` (yellow) | Fix in next sprint |
-| `priority/low` | `#0e8a16` (green) | Backlog; fix when possible |
-
----
-
-## Component Labels (`component/`)
-
-| Label | Color | Description |
-| ----- | ----- | ----------- |
-| `component/frontend` | `#1d76db` (blue) | UI, React, Vue, Angular |
-| `component/backend` | `#5319e7` (purple) | Server, services, business logic |
-| `component/api` | `#0052cc` (blue) | REST, GraphQL, gRPC endpoints |
-| `component/auth` | `#c5def5` (light blue) | Login, auth, permissions |
-| `component/database` | `#bfdadc` (light gray) | DB, migrations, queries |
-| `component/integration` | `#c2e0c6` (light green) | Third-party, external services |
-| `component/mobile` | `#bfd4f2` (light blue) | iOS, Android, mobile web |
-| `component/e2e` | `#d4c5f9` (lavender) | End-to-end tests |
-| `component/unit` | `#fef2c0` (light yellow) | Unit tests |
-| `component/performance` | `#f9d0c4` (light red) | Load, stress, performance tests |
-
----
-
-## Status Labels (`status/`)
-
-| Label | Color | Description |
-| ----- | ----- | ----------- |
-| `status/needs-triage` | `#d93f0b` (orange) | New; awaiting review |
-| `status/in-progress` | `#0052cc` (blue) | Being worked on |
-| `status/ready-for-test` | `#0e8a16` (green) | PR merged; QA verification pending |
-| `status/verified` | `#0e8a16` (green) | QA confirmed fix |
-| `status/blocked` | `#b60205` (red) | Waiting on dependency |
-| `status/wontfix` | `#ffffff` (white) | Declined; out of scope |
-
----
-
-## QA-Specific Labels
-
-| Label | Color | Description |
-| ----- | ----- | ----------- |
-| `docs-update` | `#0075ca` (blue) | Documentation change |
-| `spec-drift` | `#fbca04` (yellow) | Spec-auditor finding; spec vs implementation |
-| `regression-risk` | `#f9d0c4` (light red) | Changelog-analyzer flagged |
-| `needs-repro` | `#d93f0b` (orange) | Cannot reproduce; needs more info |
-| `duplicate` | `#cfd3d7` (gray) | Duplicate of another issue |
-
----
-
-## Color Reference (Hex Codes)
-
-| Color Name | Hex | Use |
-| ---------- | --- | --- |
-| Red (critical) | `#d73a4a` | Bugs, critical priority |
-| Dark red | `#b60205` | Blockers, critical |
-| Orange | `#d93f0b` | High priority, needs attention |
-| Yellow | `#fbca04` | Medium priority, warnings |
-| Green | `#0e8a16` | Done, verified, low priority |
-| Blue | `#0052cc` | In progress, API, info |
-| Cyan | `#a2eeef` | Enhancements |
-| Purple | `#5319e7` | Backend, special |
-| Gray | `#7f8c8d` | Tasks, neutral |
-| Light gray | `#cfd3d7` | Duplicates, deprecated |
-
----
-
-## GitHub Label Creation
-
-To create labels via GitHub MCP or API:
-
-```json
-{
-  "name": "type/bug",
-  "color": "d73a4a",
-  "description": "Defect or incorrect behavior"
-}
-```
-
-**Note**: GitHub expects 6-character hex without `#`. Use lowercase.
-
----
-
-## Recommended Label Sets by Repo Type
-
-| Repo Type | Essential Labels |
-| --------- | ----------------- |
-| **QA-focused** | `type/bug`, `type/test-coverage-gap`, `type/flaky-test`, `type/documentation`, `priority/*`, `component/*`, `status/*` |
-| **Full-stack** | All `type/`, `priority/`, `component/`, `status/` |
-| **Minimal** | `type/bug`, `type/enhancement`, `priority/high`, `priority/medium`, `status/needs-triage`, `status/in-progress` |
-
----
-
-## Customization
-
-- Add project-specific components (e.g., `component/checkout`, `component/search`)
-- Add team labels (e.g., `team/qa`, `team/platform`)
-- Add sprint/release labels if not using milestones (e.g., `sprint/24-01`)

package/skills/qa-github-issues-enhanced/references/workflow-patterns.md

@@ -1,188 +0,0 @@
-# Structured Workflow Patterns for QA GitHub Issues
-
-*Workflow patterns: bug lifecycle, coverage gap → task → PR, flaky test → investigation → fix.*
-
----
-
-## 1. Bug Lifecycle Workflow
-
-```
-[Report] → [Triage] → [Fix] → [Verify] → [Close]
-```
-
-### States and Labels
-
-| Stage | Status Label | Actions |
-| ----- | ------------ | ------- |
-| **Report** | `status/needs-triage` | Create issue with `type/bug`; assign severity, component |
-| **Triage** | — | Confirm reproducibility; add `priority/*`; assign |
-| **Fix** | `status/in-progress` | Dev creates PR; link with "Fixes #N" |
-| **Verify** | `status/ready-for-test` | PR merged; QA runs verification tests |
-| **Close** | `status/verified` | QA confirms; close issue |
-
-### Transitions
-
-1. **Report → Triage**: Assignee reviews; adds `priority/critical` or `priority/high` if valid
-2. **Triage → Fix**: Assign to dev; set `status/in-progress`
-3. **Fix → Verify**: PR merged; auto or manual set `status/ready-for-test`
-4. **Verify → Close**: QA passes verification; set `status/verified`; close
-
-### Automation Hints
-
-- **GitHub Actions**: On PR merge with "Fixes #N", add `status/ready-for-test` to linked issue
-- **GitHub MCP**: When creating bug from test failure, auto-assign `type/bug`, `status/needs-triage`, `component/*`
-
----
-
-## 2. Coverage Gap → Task → PR Workflow
-
-```
-[Coverage Analyzer] → [Coverage Gap Issue] → [Fix Task] → [PR] → [Verify]
-```
-
-### Flow
-
-1. **qa-coverage-analyzer** produces gap report (file:line, module, risk)
-2. **qa-github-issues-enhanced** creates `type/test-coverage-gap` issue with:
-   - Location (file:line)
-   - Coverage type (code/requirement/technique)
-   - Rationale (risk, complexity)
-   - Suggested tests
-3. **qa-task-creator** (or this skill) creates linked **fix task**:
-   - Title: "Add tests for [module/function]"
-   - Links to coverage gap issue
-   - Labels: `type/task`, `component/unit` or `component/e2e`
-4. Dev implements tests; opens PR referencing both issues
-5. PR merged; coverage gap and task closed
-
-### Issue Linking
-
-- Coverage gap issue: `#123`
-- Fix task: "Adds tests per #123" or "Closes #123"
-- PR: "Fixes #124" (fix task) — optionally "Addresses #123" (coverage gap)
-
-### Bulk Creation
-
-When coverage analyzer outputs many gaps:
-
-1. Group by component and priority
-2. Create one issue per gap (or batch similar gaps into single issue)
-3. Use bulk-create API; assign same milestone
-4. Optionally create fix tasks in batch via qa-task-creator
-
----
-
-## 3. Flaky Test → Investigation → Fix Workflow
-
-```
-[Flaky Report] → [Investigation] → [Root Cause] → [Fix] → [Verify]
-```
-
-### Flow
-
-1. **qa-flaky-detector** or manual report creates `type/flaky-test` issue
-2. **Investigation**: Assign to dev/QA; add `status/in-progress`
-   - Run test in loop; capture failure pattern
-   - Classify: race-condition, shared-state, time-dependency, external-dependency
-3. **Root cause**: Update issue with findings; create fix task if needed
-4. **Fix**: Dev fixes test or code; PR with "Fixes #N"
-5. **Verify**: Run test 50+ times in CI; confirm stability; close
-
-### Labels by Pattern
-
-| Flaky Pattern | Suggested Labels | Fix Approach |
-| ------------- | ---------------- | ------------ |
-| race-condition | `type/flaky-test`, `component/e2e` | Add explicit waits; fix async ordering |
-| shared-state | `type/flaky-test`, `component/unit` | Isolate state; use fresh fixtures |
-| time-dependency | `type/flaky-test` | Mock time; use deterministic delays |
-| external-dependency | `type/flaky-test`, `component/integration` | Mock external service; retry with backoff |
-
-### Sub-issues
-
-For complex flaky tests, create sub-tasks:
-
-- #201: Investigate flaky login test
-  - #202: Add explicit wait for redirect (child)
-  - #203: Verify stability in CI (child)
-
----
-
-## 4. Spec Drift → Update Workflow
-
-```
-[Spec Auditor] → [Spec Drift Issue] → [Update Task] → [PR] → [Verify]
-```
-
-### Flow
-
-1. **qa-spec-auditor** finds mismatch (requirements vs implementation vs tests)
-2. Create `type/documentation` or `spec-drift` issue:
-   - What is drifted (requirement, spec, API contract)
-   - Current vs expected state
-   - Affected tests
-3. Create update task: update spec, or fix implementation, or update tests
-4. PR; verify spec-auditor passes
-
----
-
-## 5. Bulk Operations Pattern
-
-### Input Sources
-
-| Source | Output |
-| ------ | ------ |
-| qa-coverage-analyzer | Batch of coverage gap issues |
-| qa-spec-auditor | Batch of spec drift issues |
-| qa-flaky-detector | Batch of flaky test issues |
-| qa-changelog-analyzer | Batch of "recommended tests to run" tasks |
-
-### Bulk Create Rules
-
-1. **Deduplicate**: Search existing issues before creating; skip if similar exists
-2. **Batch size**: Create in batches of 10–20 to avoid rate limits
-3. **Milestone**: Assign same milestone to batch when provided
-4. **Labels**: Apply consistent labels per batch type
-5. **Throttle**: Add small delay between API calls if needed
-
----
-
-## 6. Search and Deduplication
-
-### Before Creating Any Issue
-
-1. **Search** via GitHub MCP:
-   - By title keywords (normalize: lowercase, remove punctuation)
-   - By component + type
-   - By error message snippet (for bugs)
-   - By file:line (for coverage gaps)
-2. **Compare**:
-   - Same root cause? → Comment on existing; do not create
-   - Related but distinct? → Create with "Related to #N"
-   - Truly new? → Create
-3. **Report**: If duplicate found, inform user and link to existing issue
-
-### Search Query Examples
-
-```
-# Bugs: similar title + component
-is:open label:type/bug "login" label:component/auth
-
-# Coverage: same file
-is:open label:type/test-coverage-gap "AuthService.ts"
-
-# Flaky: same test path
-is:open label:type/flaky-test "login.spec.ts"
-```
-
----
-
-## Integration Summary
-
-| Skill | Consumes | Produces |
-| ----- | -------- | -------- |
-| qa-github-issues-enhanced | Coverage gaps, spec drift, flaky reports, bug descriptions | Labeled issues, milestones, linked tasks |
-| qa-bug-ticket-creator | Test failures | Bug issues (uses this skill's labels/templates) |
-| qa-task-creator | Bug issues, coverage gaps | Fix/verification tasks |
-| qa-coverage-analyzer | Code, coverage reports | Coverage gap list |
-| qa-spec-auditor | Requirements, implementation, tests | Spec drift list |
-| qa-flaky-detector | CI history, test results | Flaky test list |

package/skills/qa-httpx-writer/SKILL.md

@@ -1,138 +0,0 @@
----
-name: qa-httpx-writer
-description: Generate httpx/requests API tests for Python with async support, session management, and schema validation using pytest.
-output_dir: tests/api
-dependencies:
-  recommended:
-    - qa-api-contract-curator
----
-
-# QA httpx Writer
-
-## Purpose
-
-Write Python API tests using httpx (or requests) from test case specifications and API contracts. Transform structured test cases (from qa-testcase-from-docs, qa-manual-test-designer) and OpenAPI contracts (from qa-api-contract-curator) into executable pytest API tests with async support, session management, response schema validation, and authentication handling.
-
-## Trigger Phrases
-
-- "Write httpx tests for [API/endpoint]"
-- "Generate Python API tests from OpenAPI contract"
-- "Create httpx API tests for [resource]"
-- "Add httpx tests with Pydantic validation"
-- "API tests with httpx.AsyncClient"
-- "Python API tests from test cases"
-- "httpx tests with auth and retry logic"
-- "requests API tests for [endpoint]"
-
-## Key Features
-
-| Feature | Description |
-| ------- | ----------- |
-| **Async support** | `httpx.AsyncClient` for async tests; `httpx.Client` for sync |
-| **Session management** | Connection pooling, cookie persistence, header reuse |
-| **Response validation** | Pydantic models, JSON Schema for contract compliance |
-| **Authentication** | Bearer token, API key, OAuth2, Basic Auth, cookies |
-| **Retry logic** | Configurable retries for transient failures |
-| **Context managers** | `with httpx.Client()` / `async with httpx.AsyncClient()` |
-
-## Workflow
-
-1. **Read test cases + API contract** — From qa-testcase-from-docs, qa-manual-test-designer, or qa-api-contract-curator (OpenAPI)
-2. **Generate pytest API test files** — Produce `test_{resource}_api.py` with test functions per endpoint
-3. **Add fixtures** — `conftest.py` with `base_url`, client fixtures (sync/async)
-4. **Validate responses** — Status codes, headers, JSON body; Pydantic/JSON Schema validation
-
-## Context7 MCP
-
-Use **Context7 MCP** for httpx documentation when:
-- API signatures or async/sync usage are uncertain
-- Transport options, timeout, or retry configuration need verification
-- Response streaming or file upload APIs require clarification
-
-## Key Patterns
-
-| Pattern | Usage |
-| ------- | ----- |
-| `httpx.Client()` | Sync client; use as context manager |
-| `httpx.AsyncClient()` | Async client; use with `async with` |
-| `response.status_code` | Assert HTTP status |
-| `response.json()` | Parse JSON body |
-| `response.headers` | Access response headers |
-| `client.get(url)` / `client.post(url)` | HTTP methods |
-| `client.get(url, headers=...)` | Custom headers (auth, etc.) |
-| Pydantic validation | `Model.model_validate(response.json())` |
-| pytest fixtures | `base_url`, `client`, `async_client` in conftest |
-
-See `references/patterns.md` for CRUD, auth, file upload, streaming, async.
-
-## Test Structure
-
-- **conftest.py** — `base_url`, `client` (sync), `async_client` (async) fixtures
-- **test_{resource}_api.py** — One file per resource/endpoint group
-- **describe/it** equivalent — `class TestUsersAPI:` with `def test_*` methods
-
-## Auth Patterns
-
-| Type | Usage |
-| ---- | ----- |
-| **Bearer token** | `headers={"Authorization": f"Bearer {token}"}` |
-| **API key** | `headers={"X-API-Key": api_key}` or `params={"api_key": key}` |
-| **OAuth2** | `httpx.OAuth2Client` or manual token in headers |
-| **Basic Auth** | `auth=httpx.BasicAuth(user, password)` |
-| **Cookies** | Session cookies via `client.cookies` or `headers={"Cookie": ...}` |
-
-## File Naming
-
-- `test_{resource}_api.py` — e.g., `test_users_api.py`, `test_products_api.py`
-- Place in `tests/` or `tests/api/` per project convention
-
-## Scope
-
-**Can do (autonomous):**
-- Generate httpx/requests API tests from test cases and OpenAPI contracts
-- Add conftest.py with base_url, client fixtures (sync/async)
-- Use Pydantic or JSON Schema for response validation
-- Implement auth patterns (Bearer, API key, Basic, cookies)
-- Add retry logic, timeout configuration
-- Call qa-api-contract-curator for contract when needed
-- Use Context7 MCP for httpx docs
-
-**Cannot do (requires confirmation):**
-- Change production API implementation
-- Add dependencies not in requirements.txt/pyproject.toml
-- Override project test config without approval
-
-**Will not do (out of scope):**
-- Execute tests (user runs `pytest`)
-- Write E2E browser tests (use qa-playwright-ts-writer)
-- Modify CI/CD pipelines
-
-## References
-
-- `references/patterns.md` — CRUD, auth, file upload, streaming, async
-- `references/assertions.md` — Status codes, JSON body, headers, Pydantic/JSON Schema validation
-- `references/config.md` — conftest.py, fixtures, environment config, base URL
-- `references/best-practices.md` — Async vs sync, session reuse, schema validation, test isolation
-
-## Quality Checklist
-
-- [ ] Tests match test case steps and expected results
-- [ ] Each endpoint has success and error scenarios (validation, 401, 404)
-- [ ] Auth setup is correct and isolated per test
-- [ ] No hardcoded secrets; use env vars or fixtures
-- [ ] Response assertions are specific (status, body shape, headers)
-- [ ] File naming follows `test_{resource}_api.py`
-- [ ] Client fixtures use context managers; proper teardown
-- [ ] Schema validation used where contract specifies response shape
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-| ------- | ------------ | --- |
-| Connection refused | Wrong base_url or server not running | Verify `base_url` in conftest; ensure API is up |
-| Tests pass individually, fail together | Shared client state or connection pool | Use function-scoped client fixture; avoid session reuse across tests |
-| `response.json()` fails | Non-JSON response (204, HTML error) | Check `response.status_code`; use `response.text` for non-JSON |
-| Async tests fail | Missing pytest-asyncio | Add `@pytest.mark.asyncio`; install pytest-asyncio; set `asyncio_mode = "auto"` |
-| Auth not working | Token expired or wrong header | Check `Authorization` format; ensure token in scope |
-| Pydantic validation error | Response shape differs from model | Align model with API contract; use `model_validate` with `strict=False` if needed |
-| Timeout errors | Slow API or network | Increase `timeout` in client; add retry for transient failures |

package/skills/qa-httpx-writer/references/assertions.md

@@ -1,195 +0,0 @@
-# httpx Response Validation
-
-## Status Codes
-
-```python
-response = client.get(f"{base_url}/users")
-assert response.status_code == 200
-
-response = client.post(f"{base_url}/users", json={...})
-assert response.status_code == 201
-
-response = client.delete(f"{base_url}/users/1")
-assert response.status_code == 204
-
-response = client.get(f"{base_url}/users/99999")
-assert response.status_code == 404
-
-response = client.get(f"{base_url}/users")  # No auth
-assert response.status_code == 401
-
-response = client.post(f"{base_url}/users", json={"email": "invalid"})
-assert response.status_code == 400
-```
-
-| Code | Typical Use |
-| ---- | ----------- |
-| 200 | OK — GET, PUT, PATCH success |
-| 201 | Created — POST success |
-| 204 | No Content — DELETE success |
-| 400 | Bad Request — validation error |
-| 401 | Unauthorized — missing/invalid auth |
-| 403 | Forbidden — insufficient permissions |
-| 404 | Not Found — resource missing |
-| 409 | Conflict — duplicate, constraint violation |
-| 422 | Unprocessable Entity — semantic validation |
-| 500 | Internal Server Error |
-
-## JSON Body Assertions
-
-### Basic Checks
-
-```python
-data = response.json()
-assert "users" in data
-assert isinstance(data["users"], list)
-assert len(data["users"]) > 0
-```
-
-### Partial Match (Dynamic Fields)
-
-```python
-# Use dict subset for id, createdAt, etc.
-user = response.json()
-assert user["email"] == "test@example.com"
-assert "id" in user
-assert isinstance(user["id"], int)
-```
-
-### Nested Structure
-
-```python
-data = response.json()
-assert "data" in data
-assert "items" in data["data"]
-assert all("id" in item for item in data["data"]["items"])
-```
-
-## Header Assertions
-
-```python
-assert "application/json" in response.headers.get("content-type", "")
-assert "x-request-id" in response.headers
-assert response.headers["cache-control"] == "no-cache"
-```
-
-## Schema Validation with Pydantic
-
-### Define Model
-
-```python
-from pydantic import BaseModel
-
-class UserResponse(BaseModel):
-    id: int
-    email: str
-    name: str | None = None
-```
-
-### Validate Response
-
-```python
-def test_user_response_schema(client, base_url, auth_headers):
-    response = client.get(f"{base_url}/users/1", headers=auth_headers)
-    assert response.status_code == 200
-    user = UserResponse.model_validate(response.json())
-    assert user.id == 1
-    assert "@" in user.email
-```
-
-### List Response
-
-```python
-class UserListResponse(BaseModel):
-    users: list[UserResponse]
-    total: int
-
-def test_user_list_schema(client, base_url, auth_headers):
-    response = client.get(f"{base_url}/users", headers=auth_headers)
-    assert response.status_code == 200
-    data = UserListResponse.model_validate(response.json())
-    assert isinstance(data.users, list)
-    assert data.total >= 0
-```
-
-### ValidationError Handling
-
-```python
-from pydantic import ValidationError
-
-def test_invalid_response_raises(client, base_url):
-    response = client.get(f"{base_url}/broken")
-    assert response.status_code == 200
-    with pytest.raises(ValidationError):
-        UserResponse.model_validate(response.json())
-```
-
-## JSON Schema Validation
-
-```python
-import jsonschema
-
-USER_SCHEMA = {
-    "type": "object",
-    "required": ["id", "email"],
-    "properties": {
-        "id": {"type": "integer"},
-        "email": {"type": "string", "format": "email"},
-        "name": {"type": "string"},
-    },
-}
-
-def test_user_json_schema(client, base_url, auth_headers):
-    response = client.get(f"{base_url}/users/1", headers=auth_headers)
-    assert response.status_code == 200
-    jsonschema.validate(response.json(), USER_SCHEMA)
-```
-
-## Content-Type Check
-
-```python
-def test_json_response(client, base_url):
-    response = client.get(f"{base_url}/users")
-    assert response.status_code == 200
-    content_type = response.headers.get("content-type", "")
-    assert "application/json" in content_type
-    # Only then parse JSON
-    data = response.json()
-```
-
-## Empty Response (204)
-
-```python
-def test_delete_returns_empty(client, base_url, auth_headers):
-    response = client.delete(f"{base_url}/users/1", headers=auth_headers)
-    assert response.status_code == 204
-    assert response.content == b""
-    # Do not call response.json() on 204
-```
-
-## Error Response Structure
-
-```python
-def test_validation_error_structure(client, base_url):
-    response = client.post(f"{base_url}/users", json={})
-    assert response.status_code == 400
-    data = response.json()
-    assert "errors" in data or "message" in data
-    if "errors" in data:
-        assert isinstance(data["errors"], list)
-```
-
-## Parametrized Assertions
-
-```python
-@pytest.mark.parametrize("status,expected", [
-    (200, True),
-    (201, True),
-    (400, False),
-    (404, False),
-])
-def test_status_codes(client, base_url, status, expected):
-    # Adjust endpoint to trigger each status
-    response = client.get(f"{base_url}/users")
-    assert (response.status_code == status) == expected
-```