qa-skills 3.0.0

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

@@ -0,0 +1,130 @@
+# 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

@@ -0,0 +1,188 @@
+# 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

@@ -0,0 +1,138 @@
+---
+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

@@ -0,0 +1,195 @@
+# 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
+```