Agent skill · operations · borghei
test-scenarios
Generate test scenario coverage from a feature spec — happy paths, edge cases, error handling, accessibility, security, and performance — with a coverage analyzer that flags gaps. Use to define what to test before QA writes the test plan.
Why this skill is useful
Generates detailed test scenarios and coverage analysis that the AI wouldn't reliably create on its own.
What it needs
About 5k tokens when loaded. Last updated 2026-07-21. 462 stars on the source repository.
What this skill does
Test Scenarios Generate complete scenario coverage from a feature spec before tests are written. Closes the gap between "we built it" and "it survives production." When to use this skill After PRD approval but before engineering implementation During sprint planning to size testing effort During code review to verify test coverage During QA planning to scope test pass During bug-bash prep After a production incident to validate scenario gaps The 7 scenario categories For every feature, generate scenarios across: 1. Happy paths — primary user goals achieved cleanly 2. Edge cases — boundary conditions, unusual inputs 3. Error handling — what users see when things go wrong 4. Empty states — first-use, no data, after-delete 5. Concurrent operations — race conditions, optimistic locking 6. Accessibility — keyboard nav, screen reader, contrast, motion 7. Security + privacy — auth, permissions, PII, injection Plus when applicable: Performance scenarios (load, latency, throughput) Localization (RTL, long-string, currency, date format) Cross-platform (browsers, devices, OS versions) Clarify First Before generating scenarios, confirm these inputs. If any is unknown or vague, ASK — do not assume: [ ] Feature type — form, browse/list, real-time/collab, file upload, payment, or bulk operation (drives the scenario count per category in the coverage rubric) [ ] Risk / sensitivity profile — auth, payment, or PII involved (scales up security and concurrency coverage in the risk-weighted selection) [ ] The spec's inputs, outputs, and side effects — what users provide, expect, and what changes in the system (drives edge cases in Step 3 and error handling in Step 4) Stop rule: ask only the 2-3 that most change the output. If the user says "just draft it," proceed and list your assumptions at the top of the artifact. Workflow Step 1 — Spec read Read the PRD / user story / acceptance criteria. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills borghei/test-scenarios