qa-toolkit

When an API test fails, act as a senior SQA analyst — triage whether it is a real product bug, and if so draft a review-ready bug in a rigorous house format for the user's tracker. Use whenever an API test (contract / endpoint / workflow) fails and the user wants a bug drafted, when the user pastes a failed test's output, an assertion error, a schema-validation error, or a non-2xx response and asks to log or write it up, or says "draft a bug for this failure", "the contract test failed, write it up", "turn this red run into a bug". Draft-and-review only — it classifies and drafts, it never auto-files. To actually create the work item, hand the drafted fields to testcase-to-tracker or file directly. Failure-side sibling of api-test-cases (which authors the cases).

Act as a senior SQA analyst doing API testing and author API test cases in a rigorous, behavior-driven house style at three levels — Contract (response/request shape against a schema), Endpoints (happy path plus the full negative matrix per endpoint), and Workflows (chained end-to-end across calls). Use whenever the user asks for API test cases, contract/schema tests, endpoint coverage, request/response verification, negative-path coverage, or API workflow/chaining tests — e.g. "write API tests for POST /orders", "what should I test on this endpoint?", "cover this endpoint's error cases", "chain these calls into an end-to-end case", "turn this OpenAPI spec into test cases". API sibling of the UI-focused ui-test-cases skill; use ui-test-cases for click-by-click UI and this one for anything request/response. Authors cases only — to file them as work items hand off to testcase-to-tracker; to draft a bug from a failed API test use api-failure-to-bug.

Author test cases from a ticket in a rigorous senior-SQA house style and file them as Test Case work items in the user's issue tracker (Azure DevOps, Jira, or any other), then link each back to the source ticket. Use whenever the user wants to write, draft, generate, or create test cases for a ticket, story, defect, or bug AND get them into their tracker — or mentions a work item ID together with testing, a Test Plan/Suite, test steps, expected/actual results, or QA verification. Trigger even on a bare "write tests for

Review a user story, feature description, or acceptance criteria as a senior SQA analyst and write click-by-click UI test cases in a rigorous, behavior-driven house style — every step atomic, every step with an explicit expected result. Use whenever the user pastes a story, ticket, AC block, feature spec, or flow description and asks for test cases, test scenarios, test coverage, or QA review — even a bare "write tests for this", "what should I test?", "break this story into test cases", or "give me QA coverage for this AC". Also trigger when the user shares a numbered list of acceptance criteria, a bug description, or a Gherkin-style scenario and wants them turned into step-by-step test cases with explicit expected results. Authors cases only; to file them as work items hand off to testcase-to-tracker.