qa-engineering

Native skill of the qa-engineering — 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. Product-neutral and tracker-agnostic (ADO / Jira / any), grounded in the kit's framework standards. 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 file-to-tracker.

Router of the qa-engineering for the combined "write test cases for a ticket AND file them in the tracker" intent. It authors nothing and writes nothing itself — it sequences the two native engines — author the cases (author-ui-cases for UI, author-api-cases for API), which record them in qa-context with an approval seam, then file the approved set with the gated ado-publish (which picks the Test Plan/Suite, creates, adds-to-suite and links — nothing written until the QA confirms a dry-run). Product-neutral and tracker-agnostic (Azure DevOps is the implemented filing path; the same gated flow applies to Jira/any via that tracker's connector). 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

The single source of truth for this plugin's automation-framework engineering standards — pull the right standard for a building block or a design decision, product-neutrally and grounded in official docs. Use whenever the kit (the tutor teaching a concept, the builder generating code, a reviewer checking it) or the QA directly needs "what is our standard for X", "how should I structure Y", "which test level fits this case", "POM vs raw selectors", "builder vs JSON test data", "how do we keep tests isolated", or "how do we reuse another module's functionality". It reads the reference files under `knowledge/standards/` and returns the relevant standard(s) — Purpose, When to use it (and when not), the official-doc link(s), a product-neutral code shape, and the anti-patterns. It does not generate framework code itself — it supplies the standard that the tutor teaches, the builder generates to, and the reviewer checks against.

The orchestrator for the qa-engineering — build an API + UI test-automation framework brick by brick, running phases 0-5 as a state machine and pausing at every phase to say what it will do, recommend an option with its reason, act, verify, and report before moving on. Use whenever the user asks to "build a test framework brick by brick", "scaffold an automation framework step by step", "set up test automation one phase at a time", "run the test-automation kit", "continue the framework build", or is at any phase (foundation, module API suite, UI suite, ADO integration, CI) after phase 0's scan-and-confirm. It reads the confirmed flow map from `flow-map.json`, scaffolds the kit's product-agnostic `template/`, and delegates each capability to the kit's own native skills and guidance docs — it never reinvents what those already do.