qa-skills 3.0.0 → 3.1.0

package/skills/qa-test-reviewer/SKILL.md

@@ -1,142 +0,0 @@
----
-name: qa-test-reviewer
-description: Code review for test files analyzing structure, assertions, coverage, anti-patterns, and providing a code-smell catalog with before/after improvement examples.
-output_dir: reports/reviews
----
-
-# QA Test Reviewer
-
-## Purpose
-
-Perform code review on test files to assess quality, identify anti-patterns, and recommend improvements. Analyzes test structure, assertion quality, coverage alignment, naming conventions, and mocking correctness. Produces a structured review report with severity ratings and suggested fixes.
-
-## Trigger Phrases
-
-- "Review my test code" / "Code review for tests"
-- "Analyze test quality" / "Test code quality review"
-- "Find test anti-patterns" / "Test code smells"
-- "Review [test file] for best practices"
-- "Improve test assertions" / "Fix test structure"
-- "Test coverage alignment check"
-- "DRY vs DAMP in tests"
-
-## Review Criteria
-
-| Criterion | What to Check |
-|-----------|---------------|
-| **Test structure** | describe/it nesting, setup/teardown placement, logical grouping |
-| **Assertion quality** | Specific vs vague assertions; one logical assertion per test |
-| **Coverage alignment** | Test ↔ requirement traceability; tests map to intended behavior |
-| **Anti-patterns** | Hardcoded data, shared state, sleep waits, implementation coupling |
-| **Naming conventions** | Descriptive test names; consistent style (should/expect format) |
-| **DRY vs DAMP** | Shared setup where appropriate; readable tests over excessive abstraction |
-| **Mocking correctness** | Mocks verify behavior; no over-mocking; correct setup/teardown |
-
-See `references/anti-patterns.md` for the full catalog with before/after examples.
-
-## Code Smell Catalog
-
-| Smell | Description | See |
-|-------|-------------|-----|
-| **Magic numbers in tests** | Unexplained literals (timeouts, IDs, counts) | `references/anti-patterns.md` |
-| **Copy-paste test duplication** | Nearly identical tests; should use parametrize/fixtures | `references/anti-patterns.md` |
-| **Assertion-free tests** | Tests that run code but never assert | `references/anti-patterns.md` |
-| **Over-mocking** | Mocking everything; tests verify mocks, not behavior | `references/anti-patterns.md` |
-| **Test logic (if/for in tests)** | Conditional logic inside tests; tests should be deterministic | `references/anti-patterns.md` |
-| **Ignored tests without explanation** | skip/xfail/todo with no reason | `references/anti-patterns.md` |
-| **Hardcoded URLs/selectors** | Brittle strings; should use constants or config | `references/anti-patterns.md` |
-
-Each smell includes before/after examples in `references/anti-patterns.md`.
-
-## Output Format
-
-### Review Report Template
-
-```markdown
-# Test Review Report: [file/module name]
-
-## Summary
-- **Files reviewed:** [count]
-- **Issues found:** [count] (Critical: X, High: Y, Medium: Z, Low: W)
-- **Overall assessment:** Pass / Needs improvement / Fail
-
-## Issues
-
-### [Severity] [Issue title]
-**Location:** [file:line]
-**Smell:** [from catalog]
-**Description:** [what's wrong]
-**Suggested fix:**
-[before/after code or instructions]
-
-## Recommendations
-1. [Priority action]
-2. [Secondary action]
-
-## References
-- Anti-patterns: references/anti-patterns.md
-- Checklist: references/review-checklist.md
-```
-
-### Severity Levels
-
-| Level | When to use |
-|-------|-------------|
-| **Critical** | Tests are broken, misleading, or will cause false confidence |
-| **High** | Significant maintainability or reliability issues |
-| **Medium** | Best-practice violations; improves quality |
-| **Low** | Style or minor improvements |
-
-## Workflow
-
-1. **Receive test files** — User provides path(s) or content
-2. **Apply review checklist** — Use `references/review-checklist.md` systematically
-3. **Identify smells** — Map findings to `references/anti-patterns.md` catalog
-4. **Assign severity** — Critical/High/Medium/Low per impact
-5. **Suggest fixes** — Provide before/after examples where applicable
-6. **Produce report** — Structured output per template above
-
-## Scope
-
-**Can do (autonomous):**
-- Review test files for structure, assertions, anti-patterns
-- Produce review report with severity and suggested fixes
-- Reference anti-patterns catalog and review checklist
-- Suggest refactors with before/after examples
-
-**Cannot do (requires confirmation):**
-- Apply fixes directly to test code (review only; user applies)
-- Change test framework or migrate tests
-- Override organizational coding standards
-
-**Will not do (out of scope):**
-- Modify production/application code
-- Execute tests or generate coverage (consume existing reports)
-- Implement fixes; this skill reviews and recommends only
-
-## References
-
-| Topic | File |
-|-------|------|
-| Anti-patterns catalog with before/after examples | `references/anti-patterns.md` |
-| Comprehensive test review checklist | `references/review-checklist.md` |
-
-## Quality Checklist
-
-- [ ] All review criteria from checklist applied
-- [ ] Issues mapped to code smell catalog where applicable
-- [ ] Severity assigned per impact (Critical/High/Medium/Low)
-- [ ] Suggested fixes include before/after when helpful
-- [ ] Report follows template format
-- [ ] No hardcoded secrets in examples
-- [ ] Traceability preserved (test case IDs, requirement links)
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-|---------|--------------|-----|
-| Report too verbose | Every minor issue listed | Focus on High/Critical; group Low by category |
-| Before/after unclear | Example too abstract | Use concrete code from reviewed file |
-| Checklist incomplete | Missing framework-specific checks | See review-checklist.md for Jest/pytest/Playwright sections |
-| Severity inconsistent | Subjective judgment | Use severity table; Critical = broken/misleading |
-| User wants fixes applied | Skill is review-only | Clarify scope; offer to generate patch as separate step |

package/skills/qa-test-reviewer/references/anti-patterns.md

@@ -1,268 +0,0 @@
-# Test Anti-Patterns Catalog
-
-Before/after examples for common test code smells. Use this catalog when reviewing tests.
-
----
-
-## 1. Magic Numbers in Tests
-
-**Smell:** Unexplained literals (timeouts, IDs, counts) make tests brittle and hard to understand.
-
-### Before
-
-```typescript
-it('loads user data', async () => {
-  await page.waitForSelector('.user-card', { timeout: 5000 });
-  expect(await page.$$('.user-item')).toHaveLength(10);
-});
-```
-
-```python
-def test_pagination():
-    response = client.get('/users?page=1&per_page=25')
-    assert len(response.json()['items']) == 25
-```
-
-### After
-
-```typescript
-const USER_LOAD_TIMEOUT_MS = 5000;
-const EXPECTED_DEFAULT_PAGE_SIZE = 10;
-
-it('loads user data', async () => {
-  await page.waitForSelector('.user-card', { timeout: USER_LOAD_TIMEOUT_MS });
-  expect(await page.$$('.user-item')).toHaveLength(EXPECTED_DEFAULT_PAGE_SIZE);
-});
-```
-
-```python
-DEFAULT_PAGE_SIZE = 25
-
-def test_pagination():
-    response = client.get(f'/users?page=1&per_page={DEFAULT_PAGE_SIZE}')
-    assert len(response.json()['items']) == DEFAULT_PAGE_SIZE
-```
-
----
-
-## 2. Copy-Paste Test Duplication
-
-**Smell:** Nearly identical tests; should use parametrize or shared fixtures.
-
-### Before
-
-```typescript
-it('validates email format for gmail', () => {
-  expect(validateEmail('user@gmail.com')).toBe(true);
-});
-it('validates email format for outlook', () => {
-  expect(validateEmail('user@outlook.com')).toBe(true);
-});
-it('validates email format for yahoo', () => {
-  expect(validateEmail('user@yahoo.com')).toBe(true);
-});
-```
-
-```python
-def test_email_gmail():
-    assert validate_email('user@gmail.com') is True
-
-def test_email_outlook():
-    assert validate_email('user@outlook.com') is True
-
-def test_email_yahoo():
-    assert validate_email('user@yahoo.com') is True
-```
-
-### After
-
-```typescript
-const validEmails = ['user@gmail.com', 'user@outlook.com', 'user@yahoo.com'];
-validEmails.forEach((email) => {
-  it(`validates email format: ${email}`, () => {
-    expect(validateEmail(email)).toBe(true);
-  });
-});
-// Or use test.each in Jest/Vitest
-```
-
-```python
-@pytest.mark.parametrize('email', ['user@gmail.com', 'user@outlook.com', 'user@yahoo.com'])
-def test_valid_email_formats(email):
-    assert validate_email(email) is True
-```
-
----
-
-## 3. Assertion-Free Tests
-
-**Smell:** Tests that run code but never assert; they pass even when behavior is wrong.
-
-### Before
-
-```typescript
-it('saves user to database', async () => {
-  await userService.create({ name: 'Alice', email: 'alice@test.com' });
-});
-```
-
-```python
-def test_create_user():
-    user_service.create(name='Alice', email='alice@test.com')
-```
-
-### After
-
-```typescript
-it('saves user to database', async () => {
-  const user = await userService.create({ name: 'Alice', email: 'alice@test.com' });
-  expect(user.id).toBeDefined();
-  expect(user.name).toBe('Alice');
-  const saved = await db.users.findById(user.id);
-  expect(saved).toEqual(user);
-});
-```
-
-```python
-def test_create_user():
-    user = user_service.create(name='Alice', email='alice@test.com')
-    assert user.id is not None
-    assert user.name == 'Alice'
-    saved = db.users.find_by_id(user.id)
-    assert saved == user
-```
-
----
-
-## 4. Over-Mocking
-
-**Smell:** Mocking everything; tests verify mocks, not real behavior.
-
-### Before
-
-```typescript
-it('fetches user', async () => {
-  const mockFetch = jest.fn().mockResolvedValue({ id: 1, name: 'Alice' });
-  (global as any).fetch = mockFetch;
-  const user = await userService.getUser(1);
-  expect(mockFetch).toHaveBeenCalledWith('/api/users/1');
-  expect(user.name).toBe('Alice'); // from mock, not real logic
-});
-```
-
-### After
-
-```typescript
-it('fetches user from API', async () => {
-  const mockResponse = { id: 1, name: 'Alice' };
-  server.use(http.get('/api/users/:id', () => HttpResponse.json(mockResponse)));
-  const user = await userService.getUser(1);
-  expect(user.name).toBe('Alice');
-  expect(user.id).toBe(1);
-});
-// Or: test integration with real API in integration suite; mock only external deps
-```
-
----
-
-## 5. Test Logic (if/for in Tests)
-
-**Smell:** Conditional logic inside tests; tests should be deterministic and simple.
-
-### Before
-
-```typescript
-it('handles multiple users', () => {
-  const users = getUsers();
-  for (const u of users) {
-    if (u.role === 'admin') {
-      expect(u.permissions).toContain('delete');
-    } else {
-      expect(u.permissions).not.toContain('delete');
-    }
-  }
-});
-```
-
-### After
-
-```typescript
-it('admin users have delete permission', () => {
-  const admin = getUsers().find(u => u.role === 'admin');
-  expect(admin?.permissions).toContain('delete');
-});
-it('non-admin users lack delete permission', () => {
-  const regular = getUsers().find(u => u.role !== 'admin');
-  expect(regular?.permissions).not.toContain('delete');
-});
-```
-
----
-
-## 6. Ignored Tests Without Explanation
-
-**Smell:** skip/xfail/todo with no reason; tests get forgotten.
-
-### Before
-
-```typescript
-it.skip('flaky test', () => { /* ... */ });
-it.todo('something');
-```
-
-```python
-@pytest.mark.skip
-def test_something():
-    pass
-```
-
-### After
-
-```typescript
-it.skip('flaky: API returns 500 intermittently; ticket QA-123', () => { /* ... */ });
-it.todo('add test for bulk delete when API is ready');
-```
-
-```python
-@pytest.mark.skip(reason='Flaky: API returns 500 intermittently; ticket QA-123')
-def test_something():
-    pass
-```
-
----
-
-## 7. Hardcoded URLs/Selectors
-
-**Smell:** Brittle strings; should use constants or config.
-
-### Before
-
-```typescript
-await page.goto('https://staging.example.com/login');
-await page.click('#root > div > form > button[type="submit"]');
-```
-
-```python
-driver.get('https://staging.example.com/login')
-driver.find_element(By.CSS_SELECTOR, '#root > div > form > button[type="submit"]').click()
-```
-
-### After
-
-```typescript
-const BASE_URL = process.env.TEST_BASE_URL || 'https://staging.example.com';
-const SELECTORS = {
-  loginSubmit: 'button[type="submit"]',
-  // or use data-testid: '[data-testid="login-submit"]'
-};
-await page.goto(`${BASE_URL}/login`);
-await page.click(SELECTORS.loginSubmit);
-```
-
-```python
-BASE_URL = os.environ.get('TEST_BASE_URL', 'https://staging.example.com')
-LOGIN_SUBMIT = '[data-testid="login-submit"]'
-
-driver.get(f'{BASE_URL}/login')
-driver.find_element(By.CSS_SELECTOR, LOGIN_SUBMIT).click()
-```

package/skills/qa-test-reviewer/references/review-checklist.md

@@ -1,93 +0,0 @@
-# Test Review Checklist
-
-Use this checklist systematically when reviewing test files.
-
----
-
-## 1. Test Structure
-
-- [ ] **describe/it nesting** — Logical grouping; max 3–4 levels deep
-- [ ] **Setup/teardown** — beforeEach/afterEach or fixtures in correct scope
-- [ ] **Test isolation** — Each test independent; no shared mutable state
-- [ ] **Arrange-Act-Assert** — Clear three-phase structure
-- [ ] **One logical assertion per test** — Single behavior under test
-
-### Framework-Specific
-
-| Framework | Structure |
-|-----------|-----------|
-| Jest/Vitest | describe → it; beforeEach/afterEach |
-| pytest | class or module; fixtures with scope |
-| Playwright | test() with test.describe; fixtures |
-| Cypress | describe → it; beforeEach |
-
----
-
-## 2. Assertion Quality
-
-- [ ] **Specific assertions** — `expect(x).toBe(y)` not `expect(!!x).toBe(true)` when possible
-- [ ] **Meaningful failure messages** — Custom message when assertion is unclear
-- [ ] **No assertion-free tests** — Every test asserts something
-- [ ] **Correct matchers** — toEqual vs toBe; toContain vs toHaveLength
-
----
-
-## 3. Coverage Alignment
-
-- [ ] **Requirement traceability** — Test IDs or comments link to requirements
-- [ ] **Behavior-focused** — Tests verify behavior, not implementation
-- [ ] **Edge cases** — Boundaries, empty inputs, error paths covered
-- [ ] **No redundant tests** — Same behavior not tested multiple times
-
----
-
-## 4. Anti-Patterns
-
-- [ ] **No magic numbers** — Constants for timeouts, counts, IDs
-- [ ] **No copy-paste duplication** — Parametrize or fixtures
-- [ ] **No sleep waits** — Explicit waits (waitForSelector, waitForResponse)
-- [ ] **No hardcoded URLs/selectors** — Config or constants
-- [ ] **No shared mutable state** — Each test gets fresh data
-- [ ] **No implementation coupling** — Test public API, not internals
-- [ ] **No test logic** — No if/for/switch inside tests
-- [ ] **No ignored tests without reason** — skip/xfail/todo with explanation
-
----
-
-## 5. Naming Conventions
-
-- [ ] **Descriptive names** — "should display error when email is invalid"
-- [ ] **Consistent style** — should/expect or given-when-then
-- [ ] **No implementation details** — "clicks submit button" vs "calls onSubmit handler"
-
----
-
-## 6. DRY vs DAMP
-
-- [ ] **Shared setup** — Common fixtures for repeated setup
-- [ ] **Readable over abstract** — DAMP when clarity matters
-- [ ] **No over-abstraction** — Test helpers that obscure intent
-
----
-
-## 7. Mocking
-
-- [ ] **Mock only external deps** — APIs, DB, file system
-- [ ] **Verify behavior, not calls** — Prefer outcome over call count when possible
-- [ ] **Correct teardown** — Mocks restored after test
-- [ ] **No over-mocking** — Test real code paths where feasible
-
----
-
-## Severity Mapping
-
-| Finding | Typical Severity |
-|---------|------------------|
-| Assertion-free test | Critical |
-| Shared mutable state | Critical |
-| sleep() in test | High |
-| Magic numbers everywhere | Medium |
-| Copy-paste duplication | Medium |
-| Hardcoded URL | Medium |
-| skip without reason | Low |
-| Naming style inconsistency | Low |

package/skills/qa-test-strategy/SKILL.md

@@ -1,133 +0,0 @@
----
-name: qa-test-strategy
-description: Generate comprehensive test strategy documents covering scope, approach, testing types, environments, risk assessment, entry/exit criteria, and resource planning.
-output_dir: docs/plans
-dependencies:
-  recommended:
-    - qa-diagram-generator
-    - qa-risk-analyzer
----
-
-# QA Test Strategy
-
-## Purpose
-
-Create comprehensive test strategy and test plan documents that define the overall approach to testing for a project or release. Aligns with ISO/IEC/IEEE 29119-3 and provides a strategic blueprint for all testing activities.
-
-## Trigger Phrases
-
-- "Create a test strategy for..."
-- "Generate test strategy document"
-- "Define testing approach for project"
-- "Test plan with risk assessment"
-- "Comprehensive QA strategy"
-
-## Output Sections
-
-Every test strategy document includes:
-
-| Section | Content |
-| ------- | ------- |
-| **Test Scope & Objectives** | In-scope/out-of-scope, measurable goals, success criteria |
-| **Testing Types Breakdown & Rationale** | Unit, integration, E2E, performance, security, accessibility, etc. — with rationale for each |
-| **Environment Requirements** | Dev, staging, prod parity, data, tooling |
-| **Risk Assessment Matrix** | Technical, business, process risks with probability/impact and mitigations |
-| **Entry/Exit Criteria** | Conditions to start and complete testing at each level |
-| **Resource & Timeline Estimation** | Roles, effort, schedule, dependencies |
-| **Defect Management Process** | Triage, severity, workflow, escalation |
-| **Definition of Done/Ready** | DoD for stories; DoR for sprint readiness |
-| **Test Data Strategy** | Sources, masking, refresh, synthetic data |
-| **CI/CD Integration Strategy** | Pipeline gates, automation triggers, reporting |
-
-## Testing Pyramid Guidance
-
-Apply the testing pyramid principle for balanced coverage:
-
-| Layer | Ratio (typical) | Focus |
-| ----- | ----------------- | ----- |
-| **Unit** | 70% | Fast, isolated, high volume |
-| **Integration** | 20% | Component interactions, APIs |
-| **E2E** | 10% | Critical user journeys, smoke |
-
-Reference `references/testing-types.md` for detailed type descriptions and when to apply each.
-
-## Risk-Based Test Prioritization
-
-1. **Identify risks** — Technical, business, process (see `references/risk-matrix.md`)
-2. **Score** — Probability × Impact = Risk score
-3. **Prioritize** — High-risk areas get more coverage and earlier testing
-4. **Mitigate** — Allocate exploratory, security, performance tests to high-risk zones
-
-## Integration with Other Skills
-
-| Need | Skill | Usage |
-| ---- | ----- | ----- |
-| Gantt charts, timelines | qa-diagram-generator | `references/gantt.md` for schedule visualization |
-| Mind maps, flowcharts | qa-diagram-generator | `references/mindmap.md`, `references/flowchart.md` for scope/process |
-| Detailed sub-plans | qa-plan-creator | Test plan, sprint plan, regression plan, performance plan |
-| NFR analysis | qa-nfr-analyst | Performance, security, usability requirements |
-
-## Workflow
-
-1. **Input:** Project context (scope, tech stack, timeline, constraints)
-2. **Scope:** Define in/out boundaries and objectives
-3. **Types:** Select testing types from `references/testing-types.md` with rationale
-4. **Pyramid:** Apply unit > integration > E2E ratios
-5. **Risk:** Populate risk matrix from `references/risk-matrix.md`
-6. **Criteria:** Apply entry/exit from `references/entry-exit-criteria.md`
-7. **Visuals:** Call qa-diagram-generator for Gantt, mind maps, flowcharts
-8. **Sub-plans:** Call qa-plan-creator for detailed test/sprint/regression plans
-9. **Output:** Complete test strategy document
-
-## Scope
-
-**Can do (autonomous):**
-- Generate full test strategy documents from project context
-- Populate all 10 output sections
-- Apply testing pyramid ratios and risk-based prioritization
-- Call qa-diagram-generator for Gantt, mind maps, flowcharts
-- Call qa-plan-creator for detailed sub-plans
-- Reference testing-types, risk-matrix, entry-exit-criteria
-
-**Cannot do (requires confirmation):**
-- Change project scope or release dates set by stakeholders
-- Override organizational test policy or standards
-- Assign resources without approval
-
-**Will not do (out of scope):**
-- Execute tests or automation
-- Modify production code or environments
-- Approve strategy (approval is stakeholder responsibility)
-
-## Quality Checklist
-
-- [ ] All 10 output sections present and populated
-- [ ] Test scope clearly defines in/out boundaries
-- [ ] Testing types include rationale (why each type)
-- [ ] Pyramid ratios applied (unit > integration > E2E)
-- [ ] Risk matrix populated with mitigations
-- [ ] Entry/exit criteria are testable and level-specific
-- [ ] Resource/timeline estimates are realistic
-- [ ] Diagrams generated for schedule/scope (Gantt, mind map)
-- [ ] References to qa-diagram-generator and qa-plan-creator correct
-- [ ] No hardcoded secrets
-
-## Troubleshooting
-
-| Symptom | Likely Cause | Fix |
-| ------- | ------------ | --- |
-| Strategy too generic | Insufficient context | Ask for scope, tech stack, timeline, team size |
-| Missing diagrams | qa-diagram-generator not invoked | Explicitly call for Gantt, mind map, flowchart |
-| Wrong testing types | Project type unclear | Clarify web/mobile/API/embedded; use testing-types reference |
-| Risk matrix empty | No risk input | Prompt for known risks; use risk-matrix template |
-| Entry/exit vague | Subjective language | Use entry-exit-criteria reference; make criteria measurable |
-| Pyramid inverted | E2E-heavy approach | Recommend rebalancing; explain pyramid rationale |
-| Duplicate content | Overlap with qa-plan-creator | Strategy = high-level; plan = detailed; delegate sub-plans |
-
-## Reference Files
-
-| Topic | Reference |
-| ----- | --------- |
-| Testing types | `references/testing-types.md` |
-| Risk assessment | `references/risk-matrix.md` |
-| Entry/exit criteria | `references/entry-exit-criteria.md` |