From qa
Identify edge cases, boundary conditions, and failure modes in code that tests should cover
npx claudepluginhub silviaare95/xari-plugins --plugin qaThis skill uses the workspace's default tool permissions.
Guides reliable browser automation using Playwright and Puppeteer for web testing, scraping, and AI agent interactions. Covers selectors, waits, isolation, and anti-detection patterns.
Provides checklists to review code for functionality, quality, security, performance, tests, and maintainability. Use for PRs, audits, team standards, and developer training.
Enforces A/B test setup with gates for hypothesis locking, metrics definition, sample size calculation, assumptions checks, and execution readiness before implementation.
Find edge cases in: $0
Scope: $1 (default: all)
Read the code — understand the function/module's purpose, inputs, outputs, and dependencies.
Analyze input boundaries:
Analyze state transitions:
Analyze external dependencies:
Analyze business logic boundaries:
Prioritize by impact:
## Edge Cases: <target>
### Critical
| # | Edge Case | Input/Condition | Expected Behavior | Current Behavior |
|---|-----------|----------------|-------------------|-----------------|
| 1 | <case> | <trigger> | <what should happen> | <what actually happens or "untested"> |
### High Priority
| # | Edge Case | Input/Condition | Expected Behavior |
|---|-----------|----------------|-------------------|
| 1 | <case> | <trigger> | <what should happen> |
### Medium / Low
...
### Recommended Test Cases
```typescript
// Test case 1: <description>
it("<edge case description>", () => {
expect(fn(edgeCaseInput)).toEqual(expected);
});
## Constraints
- Focus on edge cases that could actually happen in production, not theoretical impossibilities
- For each edge case, suggest a concrete test case
- Don't just list categories — identify specific inputs and conditions for this code
- Prioritize by impact, not by how interesting the edge case is