/qa-knowledge

name: qa-knowledge
description: "To run QA engineering — requirements/gap analysis, scenario & spec design, test implementation, failure triage — over the QA knowledge base."

<qa_knowledge>

<role>

QA-engineering skill. Runs the QA flow -- code analysis, requirements synthesis, gap analysis, scenario/spec design, QA test implementation, failure triage -- over the QA knowledge base (failure taxonomies, catalogs, artifact skeletons) it owns. Emits into the provided artifact contract; never invents its shape or path.

</role>

<when_to_use_skill>

Use for QA-engineering work on backend-API or UI/E2E tests: synthesizing collected sources into requirements, analyzing gaps/contradictions, designing test scenarios / specs / TMS cases, implementing QA tests (UI / API / selectors) from a plan or approved specs, triaging execution failures, or recovering test-automation architecture / API contracts. Also supplies the QA conventions and artifact skeletons these tasks emit. Plain unit/integration test writing is skill `testing`, not this flow. TestRail/Jira/Confluence are canonical examples, adapt to the current case.

</when_to_use_skill>

<dependencies>

• **MUST USE SKILL `reverse-engineering`** for the `code_analysis` mode (test-automation architecture analysis, API-contract extraction).
• USE SKILL `coding` for repo conventions; `debugging` for failing tests; `sensitive-data` for redaction (canonical authority).
• USE SKILL `qa-structure` for QA paths / identifiers / state at point of use.

</dependencies>

<core_concepts>

• Load only what the current task needs; artifact skeletons are assets, conventions/catalogs are references -- READ SKILL FILE at point of use (see `<resources>`).
• Per-value honesty: every concrete value traces to a loaded source, a user clarification, or an explicit `[ASSUMED: ...]` / `gap: ...` marker -- no confident fabrication.
• Coverage is total: every input requirement / case / failure maps to ≥1 emitted item OR an explicit excluded/gap entry -- no silent drops.
• Redaction: scan every emitted artifact and redact credentials/tokens/PII/credentialed-URLs before writing → USE SKILL `sensitive-data`.
• Invocation: an owning phase supplies bindings (paths, IDs, workflow-state path) and deferred decisions. Standalone (no phase) -- ask the user for each and surface outputs to them; never write an assumed workflow-state path. "Ask the phase" in a reference = ask the user; never stall on a decision that cannot arrive.

</core_concepts>

<mode_selection>

Pick exactly one mode by deliverable (multi-phase → run the earliest, stop; the next phase re-invokes); read its reference via `<resources>`. No clean match → name the closest mode and confirm, never silently pick. (Plain unit/integration tests are skill `testing`, not a mode here.)

• code → test-arch map / API contract → **code_analysis** (analysis, no tests; via prereq skill `reverse-engineering`)
• collected sources → one requirements doc → **synthesis** (redact before quoting)
• find gaps/contradictions, no fixing → **gap_analysis** (analysis-only: surface each finding and STOP)
• design test **cases/specs** incl. TMS, **not runnable** → **scenario_design**
• write **runnable** QA tests (UI / API / selectors) from a plan/specs → **implementation_modes**
• categorize run-report failures, no fixing → **test_execution_triage** (read-only)
• propose fixes for failing QA tests + gain explicit approval to apply → **correction** (HITL-gated: present → approve → apply; via `coding` / `debugging`)

</mode_selection>

<resources>

Router -- READ SKILL FILE for the one your current step needs (point-of-use, never all at once):

| When you need to… | Command | |---|---| | present a correction for approval (API-AQA **or** UI-AQA) (`<correction>` mode) | READ SKILL FILE `assets/proposed-change-template.md` | | run the explicit-approval gate for a correction or spec/plan approval (`<correction>` mode) | READ SKILL FILE `assets/approval-gate.md` | | emit the QA api-analysis artifact | READ SKILL FILE `assets/api-analysis-template.md` | | emit QA test specs (Given-When-Then `ATC-NNN`) | READ SKILL FILE `assets/test-spec-template.md` | | record the API-AQA test-implementation | READ SKILL FILE `assets/api-aqa-test-impl-record.md` | | emit the API-AQA execution report | READ SKILL FILE `assets/failure-report-template.md` | | record QA gap-analysis findings (G/C/A) | READ SKILL FILE `assets/gap-finding-templates.md` | | build the UI-AQA test plan | READ SKILL FILE `assets/ui-aqa-plan-template.md` | | emit the UI-AQA code-analysis report | READ SKILL FILE `assets/code-analysis-report-template.md` | | run UI-AQA clarification (gap entry / questions / typed assertions) | READ SKILL FILE `assets/ui-aqa-clarification-templates.md` | | record the UI-AQA test-implementation | READ SKILL FILE `assets/ui-aqa-test-impl-record.md` | | emit the UI-AQA failure analysis | READ SKILL FILE `assets/failure-report-template.md` | | send the page-source capture message to the user | READ SKILL FILE `assets/page-source-capture-instructions.md` | | classify an API-AQA backend-API failure | READ SKILL FILE `references/api-aqa-failure-taxonomy.md` | | classify an UI-AQA UI/E2E failure | READ SKILL FILE `references/ui-aqa-failure-taxonomy.md` | | synthesize collected sources into a requirements document (`<synthesis>` mode) | READ SKILL FILE `references/synthesis-catalogs.md` | | run QA gap-analysis detection (`<gap_analysis>` mode) | READ SKILL FILE `references/gap-analysis-catalogs.md` | | design Given-When-Then API specs -- taxonomy + ATC template (`<scenario_design>` mode) | READ SKILL FILE `references/gwt-spec.md` | | format test cases for the configured TMS (scenario_design vendor binding) | READ SKILL FILE `references/<vendor>-format.md` (`<vendor>` from project config; TestRail shipped → `testrail-format.md`) | | export a case set to the configured TMS (vendor binding + destructive-write gate) | READ SKILL FILE `references/<vendor>-export.md` (`