Qa Knowledge

<qa_knowledge>

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.

<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>

• 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.

<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