AgenTeX

Ask the project's Knowledge Base a natural-language question via the KB Ask API and show the answer with its sources. Usage: /ask-kb <question>, or /ask-kb <project>: <question> to target a specific project.

Design test cases for Azure DevOps User Stories — analyze ACs into test conditions, create titled test cases with steps in ADO, and link them Tested By to the story. Pass one or more story IDs.

Estimate QA effort for Azure DevOps User Stories and create [Testing] tasks on them (5 per story), one story at a time with confirmation. Pass story IDs to target specific stories; defaults to the current sprint's stories.

Execute tests against a target, optionally from a named suite folder (e.g. suite3/). Sequential (human-in-the-loop) by default; say "parallel" for an autonomous run.

Initialize AgenTeX in the current project — scaffold a sample test suite, the executions output folder, a keys-only .env file, and CLAUDE.md guidance.

Executes a single QA test specification in an isolated playwright-cli browser session and returns a defect report. Dispatched by the browser-testing orchestrator (one subagent per test file / session). Never modifies application code.

Execute user-defined API calls during test runs, from the project's integration/ catalog. Use whenever a test step needs an HTTP call: verify via API that a UI action persisted, check an endpoint's response, or seed test data through a service. Triggers on spec steps starting with "api:", or requests like "verify via API", "call the endpoint", "check the response". The agent executes ONLY requests the user has defined in integration/*_api.json — it never composes its own HTTP requests.

Ask a project's knowledge base a natural-language question during a test run, via the KB Ask API, and read the answer as advisory context. Triggers on spec steps starting with "kb:", or requests like "ask the KB", "what does the knowledge base say", "how does <flow> work". Explicit only — the agent never calls the KB on its own initiative. Answers inform testing/navigation but are NEVER used as PASS/FAIL evidence.

Interact with Azure resources from a QA/test run via the Azure CLI (`az`) — login/auth, discovery, and reading App Service, Storage, Key Vault, and AKS resources. Use whenever a task needs to reach Azure (verify a deployment, tail app logs, read a blob/secret, get AKS credentials) or when `az` is not installed. Read the reference before the first `az` command.

Test a web application by driving a real browser through playwright-cli. Use whenever the user wants to test a website / web app for defects — happy paths, edge cases, and negative cases — either sequentially (human-in-the-loop, the default) or in parallel (autonomous). Produces per-scenario screenshots and logs plus a consolidated defect report. Read this before starting any browser testing run.

After a completed test/regression run where one or more defects were found, file them as Azure DevOps Bugs via the Azure CLI (az devops / az boards), following a configurable bug template. Product/team-agnostic — org, project, area path, template, assignees, and test plan are all placeholders resolved from config, never hardcoded. Human-in-the-loop at every board-changing step: template selection, parent User Story, related test case / suite, severity + priority (recommended from the run's findings, with alternatives to choose), and screenshot validation — all rolled into ONE consolidated confirmation before any write. Uses az CLI for every lookup, validation, and write; never touches the board beyond what the user explicitly confirms.