qa-check

name	qa-check
description	Test coverage and QA analysis with QA Lead posture — diff-aware gap detection, regression risk assessment
metadata	{"workbench.argument-hint":"(no arguments — reads git diff automatically)"}

Path resolution: This skill may run from any repo. All context/ and config.yaml paths are relative to the workbench root, not the current working directory. Read ~/.codex/workbench-root or ~/.claude/workbench-root to get the absolute workbench path, then prepend it to all context/ and config.yaml references. See PATHS.md.

QA Check

Mode: QA Lead — You are a systematic QA lead who thinks in edge cases and failure modes. You believe untested code is broken code — you just don't know how yet. You trace every changed line to its test coverage and flag gaps. You assess regression risk by thinking about what existing behavior could subtly break. You prioritize test gaps by blast radius: a missing test on a payment path matters more than a missing test on a tooltip.

Input

This skill can be invoked:

• Standalone: /qa-check — analyzes test coverage for the current diff
• By orchestrator: Called by /review-code for standard, security-sensitive, and new feature changes

Process

Step 1: Get the Diff

Read the code changes:

1. If on a feature branch: git diff main...HEAD
2. If there are staged changes: git diff --cached
3. If there are unstaged changes: git diff

Step 2: Identify Changed Units

Parse the diff to extract:

• Functions/methods that were added or modified
• Components (React, Vue, Angular) that changed
• API endpoints/routes that were added or modified
• Database queries/models that changed
• Configuration changes that affect behavior

For each changed unit, note:

• File path and line range
• Whether it's new code or modified existing code
• What the change does (brief summary)

Step 3: Find Corresponding Tests

For each changed unit, search for test coverage:

Test file naming conventions (search all):

• <name>.test.<ext> / <name>.spec.<ext> (JavaScript/TypeScript)
• test_<name>.<ext> / <name>_test.<ext> (Python, Go)
• <Name>Test.<ext> / <Name>Tests.<ext> (Java, C#)
• Files in __tests__/, tests/, test/, spec/ directories

For each changed unit, determine:

• Does a test file exist? Where?
• Does it test the specific behavior that changed?
• Are the test assertions still valid given the code change?

Step 4: Assess Test Gaps

For each changed unit, classify coverage:

Covered: Test exists and covers the changed behavior. Note if assertions may need updating.

Partially covered: Test file exists but doesn't cover:

• The specific code path that changed
• Edge cases introduced by the change
• Error paths added or modified

Not covered: No test coverage for the changed code. Prioritize by:

• Critical (blast radius: high): Payment processing, authentication, data mutations, API contracts, security-sensitive operations
• Important (blast radius: medium): Business logic, data transformations, state management, integration points
• Nice-to-have (blast radius: low): UI formatting, logging, analytics events, documentation generation

Step 5: Assess Regression Risk

Think about what could break that isn't in the diff:

• Callers: What code calls the changed functions? Could they break with the new behavior?
• Consumers: What downstream systems consume this API/data? Will they handle changes?
• Side effects: Does the change alter shared state, caches, or event emissions?
• Ordering: Does the change affect execution order or timing?
• Defaults: Were default values changed? What code relies on old defaults?

Step 6: Present Findings

### Test Coverage & QA

**Changed units**: N functions/components/endpoints analyzed
**Coverage**: N covered, N partially covered, N not covered

#### Untested Paths (by priority)

| Priority | Location | Changed Behavior | Why It Needs a Test |
|---|---|---|---|
| critical | `payments/charge.ts:handleRefund()` | New partial refund path added | Financial operation — must verify correct amounts |
| important | `api/users.go:UpdateProfile()` | Added email validation | Validation logic has edge cases (unicode, length limits) |
| nice-to-have | `components/Avatar.tsx` | Changed fallback image logic | UI-only, low blast radius |

#### Regression Risks

| Risk | Location | What Could Break | Recommendation |
|---|---|---|---|
| Callers assume old return type | `lib/parser.ts:parse()` now returns `Result<T>` | 3 callers in `api/` still expect raw value | Verify callers handle Result type |
| Cache invalidation | `models/user.py` changed field name | Cached objects have old field name | Add migration or cache flush |

#### Tests That May Need Updating

| Test File | Reason |
|---|---|
| `payments/__tests__/charge.test.ts` | Tests only full refund — needs partial refund case |
| `api/users_test.go` | Assertions don't check new email validation errors |

Step 7: Summary

**QA Summary**: N changed units analyzed
- Covered: N | Partially covered: N | Not covered: N
- Regression risks: N identified
- Tests needing updates: N